01-05 MPLS TE Configuration

S5700 and S6720 Series Ethernet Switches
Configuration Guide - MPLS 5 MPLS TE Configuration
5 MPLS TE Configuration
About This Chapter
This chapter describes how to configure MPLS TE tunnels that transmit MPLS L2VPN (VLL
and VPLS) services and MPLS L3VPN services and provide high security and guarantees
reliable QoS for VPN services.
5.1 Overview of MPLS TE

5.2 Understanding MPLS TE
5.3 MPLS TE Application on an IP MAN
5.4 Summary of MPLS TE Configuration Tasks
5.5 Licensing Requirements and Limitations for MPLS TE
5.6 Default Settings for MPLS TE
5.7 Configuring a Static MPLS TE Tunnel
5.8 Configuring a Dynamic MPLS TE Tunnel
5.9 Importing Traffic to an MPLS TE Tunnel
5.10 Adjusting RSVP-TE Signaling Parameters
5.11 Adjusting the Path of a CR-LSP
5.12 Adjusting the Establishment of an MPLS TE Tunnel
5.13 Configuring CR-LSP Backup
5.14 Configuring Manual TE FRR
5.15 Configuring Auto TE FRR
5.16 Configuring Association Between TE FRR and CR-LSP Backup
5.17 Configuring a Tunnel Protection Group
5.18 Configuring Dynamic BFD for RSVP
5.19 Configuring Static BFD for CR-LSPs
Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 271

5.20 Configuring Dynamic BFD for CR-LSPs

5.21 Configuring Static BFD for TE Tunnels
5.22 Configuring RSVP GR
5.23 Maintaining MPLS TE
5.24 Configuration Examples for MPLS TE
5.25 References for MPLS TE
5.1 Overview of MPLS TE

Definition
Multiprotocol Label Switching Traffic Engineering (MPLS TE) establishes constraint-based
routed label switched paths (CR-LSPs) and directs traffic to them. In this way, network traffic
is transmitted over specified paths.
Purpose
On a traditional IP network, nodes select the shortest path as the route to a destination
regardless of other factors such as bandwidth. This routing mechanism may cause congestion
on the shortest path and waste resources on other available paths, as shown in Figure 5-1.
Figure 5-1 Traditional routing mechanism
Switch_7 Switch_3
Path 1
80M
Switch_4
Path 2
Switch_2
40M
Switch_1
Switch_5 Switch_6
On the network shown in Figure 5-1, each link has a bandwidth of 100 Mbit/s and the same
metric. Switch_1 sends traffic to Switch_4 at 40 Mbit/s, and Switch_7 sends traffic to
Switch_4 at 80 Mbit/s. If the network runs an interior gateway protocol (IGP) that uses the
shortest path mechanism, both the two shortest paths (Path 1 and Path 2) pass through the link
Switch_2->Switch_3->Switch_4. As a result, the link Switch_2->Switch_3->Switch_4 is
overloaded, whereas the link Switch_2->Switch_5->Switch_6->Switch_4 is idle.
Traffic engineering can prevent congestion caused by uneven resource allocation by allocating
some traffic to idle links.
The following TE mechanisms have been available before MPLS TE came into use:

l IP TE: This mechanism adjusts path metrics to control traffic transmission paths. It
prevents congestion on some links but may cause congestion on other links. In addition,
path metrics are difficult to adjust on a complex network because any change on a link
affects multiple routes.
l Asynchronous Transfer Mode (ATM) TE: All IGPs select routes based only on
connections and cannot distribute traffic based on bandwidth and the traffic attributes of
links. The IP over ATM overlay model can overcome this defect by setting up virtual
links to transmit some traffic, which helps ensure proper traffic distribution and good
QoS control. However, ATM TE causes high extra costs and low scalability on the
network.
What is needed is a scalable and simple solution to deploy TE on a large backbone network.
MPLS TE is an ideal solution. As an overlay model, MPLS can set up a virtual topology over
a physical topology and map traffic to the virtual topology.
On the network shown in Figure 5-1, MPLS TE can establish an 80 Mbit/s LSP over Path 1
and a 40 Mbit/s LSP over Path 2. Traffic is then distributed to the two LSPs, preventing
congestion on a single path.
Figure 5-2 MPLS TE
Switch_7 Switch_3 Path 1
Switch_4
Switch_2
Switch_1
Switch_5 Path 2 Switch_6
Benefits
MPLS TE fully uses network resources and provides bandwidth and QoS guarantee without
the need to upgrade hardware. This significantly reduces network deployment costs. MPLS
TE is easy to deploy and maintain because it is implemented based on MPLS. In addition,
MPLS TE provides various reliability mechanisms to ensure network and device reliability.
5.2 Understanding MPLS TE

5.2.1 Basic Concepts of MPLS TE
Before starting MPLS TE configuration, you need to understand the following concepts:
l LSP
l MPLS TE Tunnel
l Link Attributes
l Tunnel Attributes

LSP
On a label switched path (LSP), traffic forwarding is determined by the labels added to
packets by the ingress node of the LSP. An LSP can be considered as a tunnel because traffic
is transparently transmitted on intermediate nodes along the LSP.
MPLS TE Tunnel
MPLS TE usually associates multiple LSPs with a virtual tunnel interface to form an MPLS
TE tunnel. An MPLS TE tunnel involves the following terms:
l Tunnel interface: a point-to-point virtual interface used to encapsulate packets. Similar to
a loopback interface, a tunnel interface is a logical interface.
l Tunnel ID: a decimal number that uniquely identifies an MPLS TE tunnel to facilitate
tunnel planning and management.
l LSP ID: a decimal number that uniquely identifies an LSP to facilitate LSP planning and
management.
Figure 5-3 illustrates the preceding terms. Two LSPs are available on the network. The path
LSRA->LSRB->LSRC->LSRD->LSRE is the primary LSP with an LSP ID of 2. The path
LSRA->LSRF->LSRG->LSRH->LSRE is the backup LSP with an LSP ID of 1024. The two
LSPs form an MPLS TE tunnel with a tunnel ID of 100, and the tunnel interface is Tunnel1.
Figure 5-3 MPLS TE tunnel and LSP
Primary LSP
LSRB LSRC LSRD
MPLS TE Tunnel
LSRE
LSRA
LSRF LSRG LSRH

Backup LSP
MPLS TE Tunnel:
Tunnel Interface = Tunnel 1
Tunnel ID = 100
Primary LSP ID = 2
Backup LSP ID = 1024
Link Attributes
MPLS TE link attributes identify the bandwidth usage, route cost, and link reliability on a
physical link. The link attributes include:
l Total link bandwidth
Bandwidth of a physical link.
l Maximum reservable bandwidth
Maximum bandwidth that a link can reserve for an MPLS TE tunnel. The maximum
reservable bandwidth must be lower than or equal to the total link bandwidth.

l TE metric
Cost of a TE link. TE metrics are used to control MPLS TE path calculation, making
path calculation more independent of IGP routing. By default, IGP metrics are used as
TE metrics.
l SRLG
Shared risk link group (SRLG), a group of links that share a physical resource, such as
an optical fiber. Links in an SRLG have the same risk. If one link fails, other links in the
SRLG also fail.
The SRLG attribute is used in CR-LSP hot standby and TE fast reroute (FRR) to
enhance TE tunnel reliability. For details about SRLG, see SRLG.
l Link administrative group
A 32-bit vector that identifies link attributes, also called a link color. Each bit can be set
to 0 or 1 by the network administrator. A link administrative group identifies an attribute,
such as the link bandwidth or performance. A link administrative group can also be used
for link management. For example, it can identify that an MPLS TE tunnel passes
through a link or that a link is transmitting multicast services. The administrative group
attribute must be used with the affinity attribute to control path selection.
Tunnel Attributes
An MPLS TE tunnel is composed of several constraint-based routed label switched paths
(CR-LSPs). The constraints for LSP setup are tunnel attributes.
Different from a common LSP (LDP LSP for example), a CR-LSP is set up based on
constraints in addition to routing information, including bandwidth constraints and path
constraints.
l Bandwidth constraints
Bandwidth constraint is mainly the tunnel bandwidth.
l Path constraints
Path constraints include explicit path, priority and preemption, route pinning, affinity
attribute, and hop limit.
Constraint-based routing (CR) is a mechanism to create and manage these constraints, which
are described in the following:
l Tunnel bandwidth
The bandwidth of a tunnel must be planned according to requirements of the services to
be transmitted over the tunnel. The planned bandwidth is reserved on the links along the
tunnel to provide bandwidth guarantee.
l Explicit path
An explicit path is a CR-LSP manually set up by specifying the nodes to pass or avoid.
Explicit paths are classified into the following types:
– Strict explicit path
On a strict explicit path, all the nodes are manually specified and two consecutive
hops must be directly connected. A strict explicit path precisely controls the path of
an LSP.

Figure 5-4 Strict explicit path

LSRA LSRB LSRD LSRF
Explicit path
LSRB Strict
LSRC Strict
LSRE Strict LSRC LSRE
LSRD Strict
Strict explicit path
As shown in Figure 5-4, LSRA is the ingress node, and LSRF is the egress node.
An LSP from LSRA to LSRF is set up over a strict explicit path. LSRB Strict
indicates that this LSP must pass through LSRB, which is directly connected to
LSRA. LSRC Strict indicates that this LSP must pass through LSRC, which is
directly connected to LSRB. The rest may be deduced by analogy. In this way, the
path that the LSP passes through is precisely controlled.
– Loose explicit path
A loose explicit path passes through the specified nodes but allows intermediate
nodes between the specified nodes.
Figure 5-5 Loose explicit path
LSRA LSRB LSRD LSRF
Explicit path
LSRD Loose
LSRC LSRE
Loose explicit path
As shown in Figure 5-5, an LSP is set up over a loose explicit path from LSRA to
LSRF. LSRD Loose indicates that this LSP must pass through LSRD, but LSRD
may not be directly connected to LSRA.
l Priority and preemption
Priority and preemption determine resources allocated to MPLS TE tunnels based on the
importance of services to be transmitted on the tunnels.
Setup priorities and holding priorities of tunnels determine whether a new tunnel can
preempt the resources of existing tunnels. If the setup priority of a new CR-LSP is higher
than the holding priority of an existing CR-LSP, the new CR-LSP can occupy resources
of the existing CR-LSP. The priority value ranges from 0 to 7, among which the value 0
indicates the highest priority, and the value 7 indicates the lowest priority. The setup
priority of a tunnel must be lower than or equal to the holding priority of the tunnel.

If no path can provide the required bandwidth for a new CR-LSP, an existing CR-LSP is
torn down and its bandwidth is assigned to the new CR-LSP. This is the preemption
process. The following preemption modes are supported:
– Hard preemption: A high-priority CR-LSP can directly preempt resources assigned
to a low-priority CR-LSP. As a result, some traffic is dropped on the low-priority
CR-LSP.
– Soft preemption: The make-before-break mechanism applies to resource
preemption. A high-priority CR-LSP preempts bandwidth assigned to a lower-
priority CR-LSP only after traffic over the low-priority CR-LSP switches to a new
CR-LSP.
The priority and preemption attributes determine resource preemption among tunnels. If
multiple CR-LSPs need to be set up, CR-LSPs with higher setup priorities can be set up
by preempting resources. If resources (such as bandwidth) are insufficient, a CR-LSP
with a higher setup priority can preempt resources of an established CR-LSP with a
lower holding priority.
As shown in Figure 5-6, links on the network have different bandwidth values but the
same metric value. There are two TE tunnels on the network:
– Tunnel 1: established over Path 1. Its bandwidth is 100 Mbit/s, and its setup and
holding priority values are 0.
– Tunnel 2: established over Path 2. Its bandwidth is 100 Mbit/s, and its setup and
holding priority values are 7.
Figure 5-6 Before a link failure occurs

LSRA LSRF
Tunnel 1
1G 100M
Path1 LSRB
1G
100M 1G
Tunnel 2
Path2
100M 100M
LSRC LSRD LSRE
Path of Tunnel 1
Path of Tunnel 2
When the link between LSRB and LSRE fails, LSRA calculates a new path, Path 3
(LSRA->LSRB->LSRF->LSRE), for Tunnel 1. The bandwidth of the link between
LSRB and LSRF is insufficient for tunnels Tunnel 1 and Tunnel 2. As a result,
preemption is triggered, as shown in Figure 5-7.

Figure 5-7 After preemption is triggered
LSRA LSRF
Tunnel 1
Preemption
1G occurs
Path3 LSRB
100M
1G
100M 1G
Tunnel 2
Path2
100M 100M
LSRC Path4 LSRD LSRE
New path of Tunnel 1
Old path of Tunnel 2
New path of Tunnel 2
Link failure
A new path is set up for Tunnel 1 as follows:

a. After MPLS TE path calculation is complete, Path messages are transmitted along
the path LSRA->LSRB->LSRF->LSRE, and Resv messages are transmitted along
the path LSRE->LSRF->LSRB->LSRA.
b. When a Resv message is sent from LSRF to LSRB, LSRB needs to reserve
bandwidth for the new path but finds that bandwidth is insufficient. Then
preemption occurs. LSRB processes the low-priority path differently in hard and
soft preemption modes:
n In hard preemption mode: Tunnel 1 has a higher priority than Tunnel 2, so
LSRB tears down Path 2 of Tunnel 2. In addition, LSRB sends a PathTear
message to request LSRF to delete the path information, and sends a ResvTear
to request LSRC to delete the reservation state. If traffic is being transmitted
on Tunnel 2, some traffic is dropped.
n In soft preemption mode: LSRB sends a ResvTear message to LSRC. A new
path, Path 4, is set up while Path 2 is not torn down. After traffic on Path 2 is
switched to Path 4, LSRB and LSRC tear down Path 2 on Tunnel 2.
l Path locking
Changes in the network topology or some tunnel attributes may require a CR-LSP to be
reestablished. Reestablishing a CR-LSP may cause the following problems:
– The new CR-LSP is set up along a different path than the original one, making
network maintenance inconvenient.
– Some traffic is dropped when traffic is switched from the original CR-LSP to the
new one.
Path locking can prevent a CR-LSP from changing its path when routes change. This
feature ensures continuity of service traffic and improves service reliability.
l Affinity attribute

The affinity attribute is a 32-bit vector that specifies the links required for a TE tunnel.
This attribute is configured on the ingress node of a tunnel and must be used with the
link administrative group attribute.
After the affinity attribute is configured for a tunnel, a label switching router (LSR)
compares the affinity attribute with the administrative group attribute of a link to
determine whether to select or avoid the link during MPLS TE path calculation. A 32-bit
mask identifies the bits to be compared in the affinity and administrative group
attributes. An LSR performs an AND operation on the affinity and administrative group
attributes with the mask and compares the results of the AND operations. If the two
results are the same, the LSR selects the link. If the two results are different, the LSR
avoids the link. The rules for comparing the affinity and administrative group attributes
are as follows:
– Among the bits mapping the 1 bits in the mask, at least one administrative group bit
and the corresponding affinity bit must be 1. The administrative group bits
corresponding to the 0 bits in the affinity attribute must also be 0.
For example, if the affinity attribute is 0x0000FFFF of a tunnel and the mask is
0xFFFFFFFF, the administrative group attribute of an available link must have all
0s in its leftmost 16 bits and at least one 1 bit in its rightmost 16 bits. Therefore,
links with the administrative group values in the range of 0x00000001 to
0x0000FFFF can be selected for the tunnel.
– An LSR does not check the administrative group bits mapping 0 bits in the mask.
For example, if the affinity attribute of a tunnel is 0xFFFFFFFF and the mask is
0xFFFF0000, the administrative group attribute of an available link must have at
least one 1 bit in its leftmost 16 bits. The rightmost 16 bits of the administrative
group attribute can be 0 or 1. Therefore, links with the administrative group values
in the range of 0x00010000 to 0xFFFFFFFF can be selected for the tunnel.
NOTE
Devices from different vendors may follow different rules to compare the administrative group and
affinity attributes. When using devices from different vendors on your network, understand their
implementations and ensure that they can interoperate with one another.
A network administrator can use the administrative group and affinity attributes to
control path selection for tunnels.
l Hop limit
Hop limit is a condition for path selection during CR-LSP setup. Similar to the
administrative group and affinity attributes, hop limit controls the number of hops
allowed on a CR-LSP.
5.2.2 Implementation
Figure 5-8 illustrates the MPLS TE framework.

Figure 5-8 MPLS TE framework
Upstream Downstream
Local nodes
nodes nodes
IGP route LSP route

selection selection
Path Path
establishment establishment
Signaling
LSDB TEDB
protocol
Information Information
advertisement advertisement
IS-IS/OSPF routing
Incoming Outgoing
packets packets
Traffic forwarding
Protocol packet exchanging

Data packet forwarding
Internal information
processsing
MPLS TE is implemented based on four functions:

l IGP-based information advertisement for TE information collection
l Path calculation using the collected information
l Path setup through signaling packet exchange between upstream and downstream nodes
l Traffic forwarding over an established MPLS TE tunnel
Table 5-1 describes the four functions.
Table 5-1 Functions for MPLS TE implementation
N Function Description
o.
1 Informatio Collects network load information in addition to routing information.

n MPLS TE extends an IGP to advertise TE information, including the
advertisem maximum link bandwidth, maximum reservable bandwidth, reserved
ent bandwidth, and link colors.
Every node collects TE information about all links in a local area and
generates a traffic engineering database (TEDB).
2 Path Uses the Constrained Shortest Path First (CSPF) algorithm and data in
calculation the TEDB to calculate a path that satisfies specific constraints. CSPF
evolves from the Shortest Path First (SPF) algorithm. It excludes nodes
and links that do not satisfy specific constraints and uses the SPF
algorithm to calculate a path.

N Function Description
o.
3 Path setup Sets up a static or dynamic CR-LSP.

l Static CR-LSP
Forwarding and resource information is manually configured for a
CR-LSP without the need of a signaling protocol or path
calculation. Setting up a static CR-LSP consumes few resources
because no MPLS control packets are exchanged between the two
ends of the CR-LSP. Static CR-LSPs cannot be adjusted
dynamically; therefore, static CR-LSP setup applies only to small
networks with simple topologies.
l Dynamic CR-LSP
Nodes on a network use the Resource Reservation Protocol (RSVP)
TE signaling protocol to set up CR-LSP tunnels. RSVP-TE
messages carry constraints for a CR-LSP, such as the bandwidth,
explicit path, and affinity attribute.
There is no need to manually configure each hop along a dynamic
CR-LSP. Dynamic CR-LSP setup applies to large-scale networks.
RSVP authentication can be used to enhance security and
reliability of CR-LSPs.
4 Traffic Directs traffic to an MPLS TE tunnel and forwards traffic over the
forwardin MPLS TE tunnel. The first three functions set up an MPLS TE tunnel,
g and the traffic forwarding function directs traffic arriving at a node to
the MPLS-TE tunnel.
NOTE
l A static CR-LSP is manually established and does not require information advertisement or path
calculation.
l A dynamic CR-LSP is set up using a signaling protocol and involves all the four functions listed in
the table.
To deploy MPLS TE on a network, you must configure link and tunnel attributes. Then MPLS
TE sets up tunnels automatically. After a tunnel is set up, traffic is directed to the tunnel for
forwarding.
5.2.3 Information Advertisement

MPLS TE uses a routing protocol to advertise information about resources allocated to
network nodes. Each node on an MPLS TE network, especially the ingress node, determines
the path of a tunnel according to the advertised information.
What Information Is Advertised

The following information is advertised on an MPLS TE network:
l Link information: includes interface IP addresses, link types, and link metrics, which are
collected by an IGP.

l Bandwidth information: includes the maximum link bandwidth, maximum reservable

bandwidth, and available bandwidth corresponding to each link priority.
l TE metric: indicates the metric value of a link. By default, IGP metric is used as TE
metric.
l Link administrative group: indicates the color of a link.
l Affinity attribute: indicates the link colors required for a TE tunnel.
l Shared risk link group (SRLG): is a constraint for path calculation, which prevents the
backup path of a tunnel from being set up on links with the same risk level as the
primary path.
How Information Is Advertised

TE information is advertised using extensions of link-state routing protocols: OSPF TE and
IS-IS TE. The Open Shortest Path First (OSPF) and Intermediate System to Intermediate
System (IS-IS) protocols collect TE information on a node and flood the collected
information to other nodes on the MPLS TE network.
OSPF TE
OSPF is a link state routing protocol that supports flexible extensions. It defines link-state
advertisements (LSAs) of Type-1 to Type-5 and Type-7 to carry inter-area, intra-area, and
autonomous system (AS) external routing information. Formats of these LSAs do not meet
the requirements of MPLS TE; therefore, two extended LSAs, Opaque LSA and TE LSA, are
defined to implement MPLS TE.
l Opaque LSA
Opaque LSAs include Type-9, Type-10, and Type-11 LSAs. Type-9 LSAs can only be
flooded to the local network connected to an interface, and Type-10 LSAs can only be
flooded to the local area. Type-11 LSAs are similar to Type-5 LSAs and can be flooded
to the local AS except stub areas and not-so-stubby areas (NSSAs).
An Opaque LSA has the same header format as the other types of LSAs, except that the
four-byte Link State ID field is divided into an Opaque Type field and an Opaque ID
field, as shown in Figure 5-9.
Figure 5-9 Opaque LSA format
The Opaque Type field is the leftmost byte that identifies the application type of an
Opaque LSA. The Opaque ID field is the rightmost three bytes that differentiate LSAs of
the same type. Therefore, each type of Opaque LSA has 255 applications, and each
application has 16777216 different LSAs within a flooding scope.
For example, OSPF Graceful Restart LSAs are Type-9 LSAs with the Opaque Type of 3,
and TE LSAs are Type-10 LSAs with the Opaque Type of 1.

The Opaque Information field contains the content to be advertised by an LSA. The
information format is defined by the specific application. The commonly used format is
the extensible Type/Length/Value (TLV) structure.
Figure 5-10 TLV structure
– Type: indicates the type of information carried in the TLV.

– Length: indicates the number of bytes in the Value field.
– Value: indicates information carried in the TLV. This field can be another TLV (sub-
TLV).
l TE LSA
TE LSAs are Type-10 LSAs applied to TE. The Opaque Type of TE LSAs is 1.
Therefore, TE LSAs have a link state ID of 1.x.x.x and are flooded within an area.
Figure 5-11 shows the TE LSA structure.

Figure 5-11 TE LSA structure
TE LSAs carry information in TLVs. Two types of TLVs are defined for TE LSAs:
– TLV Type 1
It is a Router Address TLV that uniquely identifies an MPLS node. A Router
Address TLV plays the same role as a router ID in the Constrained Shortest Path
First (CSPF) algorithm.

– TLV Type 2
It is a Link TLV that carries attributes of an MPLS TE capable link. Table 5-2 lists
the sub-TLVs that can be carried in a Link TLV.
Table 5-2 Sub-TLVs in a Link TLV

Sub-TLV Description
Type 1: Link Type (with a 1-byte Carries a link type.

Value field) l 1: point-to-point link
l 2: multi-access link
The Value field of this sub-TLV is followed
by a 3-byte padding field.
Type 2: Link ID (with a 4-byte Value Carries a link identifier in IP address format.
field) l For a point-to-point link, this sub-TLV
indicates the OSPF router ID of a
neighbor.
l For a multi-access link, this sub-TLV
indicates the interface IP address of the
designated router (DR).
Type 3: Local IP Address (with a Carries one or more local interface IP

4N-byte Value field) addresses. Each IP address occupies 4 bytes.
Type 4: Remote IP Address (with a Carries one or more remote interface IP

4N-byte Value field) addresses. Each IP address occupies 4 bytes.
l For a point-to-point link, this sub-TLV is
filled with a remote IP address.
l For a multi-access link, this sub-TLV is
filled with 0.0.0.0 or is not carried in the
TLV.
Type 5: Traffic Engineering Metric Carries the TE metric configured on a TE link.

(with a 4-byte Value field) The data format is ULONG.
Type 6: Maximum Bandwidth (with Carries the maximum bandwidth of a link.

a 4-byte Value field) The value is a 4-byte floating point number.
Type 7: Maximum Reservable Carries the maximum reservable bandwidth of

Bandwidth (with a 4-byte Value a link. The value is a 4-byte floating point
field) number.
Type 8: Unreserved Bandwidth (with Carries reservable bandwidth values for the
a 32-byte Value field) eight priorities of a link. The bandwidth for
each priority is a 4-byte floating point number.
Type 9: Administrative Group (with Carries the administrative group attribute of a

a 4-byte Value field) link.
If an OSPF-capable link that has established an OSPF neighbor relationship is identified

as an MPLS TE link, OSPF TE generates a TE LSA carrying information about the

MPLS TE link and advertises the TE LSA to the local area. If other nodes in the local
area support TE extensions, these nodes establish a topology of TE links. Each node that
advertises TE LSAs must have a unique router address.
Type-10 Opaque LSAs are advertised within an OSPF, so CSPF calculation is performed
on an area basis. To calculate an LSP spanning multiple areas, CSPF calculation must be
performed in each area.
IS-IS TE
IS-IS is a link state routing protocol and supports TE extensions to advertise TE information.
IS-IS TE defines two new TLV types:
l Type 135: Wide Metric

IS-IS has two metrics:
– Narrow metric: 6 bits
– Wide metric: 32 bits. Wide Metric TLVs are only used to transmit TE information
and cannot be used for route calculation.
A Narrow Metric TLV supports only 64 vector values and cannot meet traffic
engineering requirements on large-scale networks. Wide Metric TLVs are more suitable
for TE information advertisement.
To allow for the transition from Narrow Metric to Wide Metric, IS-IS TE defines the
following vector values:
– Compatible: allows a device to send and receive packets with narrow and wide
metrics.
– Wide Compatible: allows a device to receive packets with narrow and wide metrics
but to send only packets with wide metrics.
l Type 22: IS Reachability TLV
Figure 5-12 shows the format of an IS Reachability TLV.
Figure 5-12 IS Reachability TLV format

0 15 23 31
System ID and pseudonode number (7 octets)

Link metric
( 3 octets )
Link metric (continued) sub-TLV length (1 octet)
sub-TLVs (0-244 octets)
An IS Reachability TLV consists of the following:

– System ID and pseudo node ID
– Default link metric
– Length of sub-TLVs
– Variable-length sub-TLVs
Table 5-3 describes sub-TLVs in an IS Reachability TLV.

Table 5-3 Sub-TLVs in an IS Reachability TLV
Sub-TLV Description
Type 3: Administrative group (with a 4-byte Indicates the administrative

Value field) attribute of a link. The 32 bits in
the attribute represent 32
administrative groups.
Type 6: IPv4 interface address (with a 4N-byte Carries one or more local interface
Value field) IP addresses. Each IP address
occupies 4 bytes.
Type 8: IPv4 neighbor address (with a 4N-byte Indicates one or more remote
Value field) interface IP addresses. Each IP
address occupies 4 bytes.
l For a point-to-point link, this
sub-TLV is filled with a remote
IP address.
l For a multi-access link, this
sub-TLV is filled with 0.0.0.0.
Type 9: Maximum link bandwidth (with a 4-byte Carries the maximum bandwidth
Value field) of a link.
Type 10: Reservable link bandwidth (with a 4- Carries the maximum reservable
byte Value field) bandwidth of a link.
Type 11: Unreserved bandwidth (with a 32-byte Carries reservable bandwidth for
Value field) eight priorities of a link.
Type 18: TE Default metric (with a 3-byte Value Carries the TE metric configured
field) on a TE link.
When Information Is Advertised

To maintain a uniform traffic engineering database (TEDB) in an area, OSPF TE and IS-IS
TE must flood the area with link information. Besides configuration of a new MPLS TE
tunnel, the following conditions can trigger TE information flooding:
l The IGP TE flooding interval expires. (The flooding interval is configurable.)

l A link is activated or fails.
l An LSP cannot be set up because of insufficient bandwidth. In this case, the local node
immediately floods the current available link bandwidth in the area.
l Link attributes, such as the administrative group and affinity attributes, change.
l The link bandwidth changes.
When the available bandwidth of an MPLS interface changes, the local node updates
TEDB and floods the updated link information. If a node needs to reserve bandwidth for
a large number of tunnels to be set up, the system frequently updates the TEDB and
triggers flooding. For example, if 100 tunnels with 1 Mbit/s bandwidth need to be set up
on a 100 Mbit/s link, the system needs to flood link information 100 times.

MPLS TE uses a bandwidth flooding mechanism to reduce the frequency of TEDB

updating and flooding. When either of the following conditions is met, an IGP floods
link information and updates the TEDB:
– The ratio between bandwidth reserved for an MPLS TE tunnel on a link and
available link bandwidth in the TEDB is larger than or equal to the configured
threshold.
– The ratio between bandwidth released from an MPLS TE tunnel and available link
bandwidth in the TEDB is larger than or equal to the configured threshold.
Assume that available bandwidth of a link is 100 Mbit/s. If 100 MPLS TE tunnels with 1
Mbit/s bandwidth need to be set up on the link and the flooding threshold is 10%, the
ratios between reserved bandwidth and available bandwidth and the flooding process are
shown in Figure 5-13.
The system does not flood bandwidth information when creating tunnels 1 to 9. When
tunnel 10 is created, the system floods the 10 Mbit/s bandwidth occupied by the 10
tunnels. The available bandwidth is now 90 Mbit/s. Similarly, the system does not flood
bandwidth information when creating tunnels 11 to 18, and it does not flood bandwidth
information until tunnel 19 is created. The other flooding processes can be deducted by
analogy.
Figure 5-13 Ratios between reserved bandwidth and available bandwidth
10% 10%
9% 8.9%
8% 7.8%
7% 6.7%
6% 5.6%
5%
4.4%
4%
3.3% 3.8%
3%
2% 2.2% 2.5%
1% 1.1% 1.3%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22......
Original available First flooding Second flooding

bandwidth 100 Mbit/s available bandwidth available bandwidth
90 Mbit/s 81 Mbit/s
Information Advertisement Result

After an OSPF TE or IS-IS TE flooding process is complete, all nodes in the local area
generate the same TEDB.
Nodes on an MPLS TE network need to advertise resource information. Each device collects
link information in the local area, such as constraints and bandwidth usage, and generates a
database of link attributes and topology attributes. This database is the TEDB.

A device calculates the optimal path to another node in the local area according to information
in the TEDB. MPLS TE then uses this path to set up a CR-LSP.
The TEDB is independent of the link state database (LSDB) of an IGP. Both the two
databases are generated through IGP-based flooding, but they record different information
and provide different functions. The TEDB stores TE information in addition to all
information available in the LSDB. The LSDB is used to calculate the shortest path, whereas
the TEDB is used to calculate the best LSP for an MPLS TE tunnel.
5.2.4 Path Calculation

MPLS TE uses the Constrained Shortest Path First (CSPF) algorithm to calculate the optimal
path to a node. CSPF was developed based on shortest path first (SPF).
Elements for CSPF Calculation

CSPF calculation depends on the following factors:
l Constraints for LSP setup, including the LSP bandwidth, explicit path, setup/holding
priority, and affinity attribute, all of which are configured on the ingress node
l Traffic engineering database (TEDB)
NOTE
A TEDB can be generated only when OSPF TE or IS-IS TE is configured. On an IGP TE-incapable
network, CR-LSPs are established based on IGP routes, but not calculated using CSPF.
CSPF Calculation Process

To find the shortest path to the destination, CSPF excludes the links whose attributes do not
meet LSP setup constraints in the TEDB and then calculates the metrics of other paths using
the SPF algorithm.
NOTE
If both OSPF TE and IS-IS TE are deployed, CSPF uses the OSPF TEDB to calculate a CR-LSP. If a
CR-LSP is calculated using the OSPF TEDB, CSPF does not use the IS-IS TEDB. If no CR-LSP is
calculated using the OSPF TEDB, CSPF uses the IS-IS TEDB to calculate a CR-LSP.
Whether OSPF TEDB or IS-IS TEDB is used first in the CSPF calculation is determined by the
administrator.
If there are multiple shortest paths with the same metric, CSPF uses a tie-breaking policy to
select one of them. The following tie-breaking policies are available:
l Most-fill: selects the link with the highest proportion of used bandwidth to the maximum
reservable bandwidth. This policy uses the full bandwidth of a link.
l Least-fill: selects the link with the lowest proportion of used bandwidth to the maximum
reservable bandwidth. This policy uses consistent bandwidth resources on links.
l Random: selects a random path among equal-metric paths. This policy sets LSPs
consistently over links, regardless of bandwidth distribution.
When several links have the same proportion of used bandwidth to the maximum reservable
bandwidth, CSPF selects the link discovered first, irrespective of most-fill or least-fill.
Figure 5-14 shows an example of CSPF calculation. Figure 5-14 shows the color and
bandwidth of some links. The other links are black and have a bandwidth of 100 Mbit/s. A
path to LSRE needs to be set up on the network and must pass through LSRH, with a

bandwidth of 80 Mbit/s and an affinity attribute of black. According to the constraints, CSPF
excludes the blue links, 50 Mbit/s links, and links not connected to LSRH.
Figure 5-14 Excluding links
LSRB LSRC LSRD

50
50
Bl
Bl
ue
ue
ue
Bl
LSRA LSRE
50
LSRF LSRG LSRH
MPLS TE Tunnel 1:
Destination = LSRE
Bandwidth = 80Mbit/s
Affinity Property = Black
LSRH Loose
LSRC LSRD
Calculated topology
LSRA LSRE
LSRF LSRG LSRH
After excluding unqualified links, CSPF uses the SPF algorithm to calculate the path. Figure
5-15 shows the calculation result.
Figure 5-15 CSPF calculation result
LSRD
LSRA LSRE
LSRF LSRG LSRH
Differences Between CSPF and SPF

CSPF is specific to MPLS TE path calculation and differs from SPF in the following aspects:

l CSPF only calculates the shortest path from an ingress node to an egress node, while
SPF calculates the shortest path from a node to all the other nodes on a network.
l CSPF uses path constraints such as link bandwidth, link attributes, and affinity attributes
as metrics, while SPF simply uses link costs as metrics.
l CSPF does not support load balancing and uses tie-breaking policies to determine a path
if multiple paths have the same metric.
5.2.5 CS-LSP Setup
5.2.5.1 Overview of CR-LSP Setup
CR-LSP Setup Modes

A CR-LSP can be statically or dynamically set up.
A static CR-LSP is set up depending on manual configuration. This section describes how
dynamic CR-LSPs are set up through RSVP-TE.
Overview of RSVP-TE
The Resource Reservation Protocol (RSVP) is designed for the integrated services model, and
reserves resources for nodes along a path. This bandwidth reservation capability makes
RSVP-TE a suitable signaling protocol for establishing MPLS TE paths.
RSVP-TE provides the following extensions based on RSVP to support MPLS TE

implementation:
l RSVP-TE adds Label Request objects to Path messages to request labels and adds Label
objects to Resv messages to allocate labels.
l An extended RSVP message can carry path constraints in addition to label binding
information.
l The extended objects carry MPLS TE bandwidth constraints to implement resource
reservation.
RSVP Message Types

RSVP defines the following types of messages:
l Path message: is sent downstream by the sender and saves path information on the nodes
it passes through.
l Resv message: is sent upstream by the receiver to respond to the Path message and to
request resource reservation.
l PathErr message: is sent by an RSVP node to its upstream node if an error occurs while
this node is processing a Path message.
l ResvErr message: is sent by an RSVP node to its downstream node if an error occurs
while this node is processing a Resv message.
l PathTear message: is sent to delete path information and functions in the opposite way to
a Path message.
l ResvTear message: is sent to delete the resource reservation state and functions in the
opposite way to a Resv message.

l ResvConf message: is sent downstream from the sender hop by hop to confirm a
resource reservation request. This message is sent only when the Resv message contains
the RESV_CONFIRM object.
l Srefresh message: is used to update the RSVP state.
RSVP-TE Implementation
Table 5-4 describes RSVP-TE implementation.
Table 5-4 RSVP-TE implementation

Function Description
5.2.5.2 Setup of A CR-LSP is set up according to the CSPF calculation result or an

Dynamic CR-LSPs explicit path. CR-LSP setup is triggered on the ingress node.
5.2.5.3 Maintenance l Path Status Maintenance

of Dynamic CR- After a CR-LSP is set up, RSVP-TE still sends RSVP messages
LSPs to maintain the path state on each node.
l Error Signaling
RSVP nodes send error messages to notify upstream and
downstream nodes that faults have occurred during path
establishment or maintenance.
l Path Teardown
A CR-LSP is torn down, and labels and bandwidth on each
node are released. The ingress node initiates teardown requests.
5.2.5.2 Setup of Dynamic CR-LSPs

To establish a dynamic CR-LSP from an ingress node to an egress node, the ingress node
sends Path messages to the egress node and the egress node sends Resv messages back to the
ingress node. Path messages are sent to create Resource Reservation Protocol (RSVP)
sessions and associate the path status. Every node that receives a path message creates a path
state block (PSB). A Resv message carries resource reservation information. Every node that
receives a Resv message creates a reservation state block (RSB) and allocates a label.
Figure 5-16 shows how RSVP-TE sets up a CR-LSP.
Figure 5-16 CR-SLP setup through RSVP-TE

1 Path 2 Path 3 Path
if1 if0 if1 if0 if1 if0
Resv 6 Resv 5 Resv 4

PE1 P1 P2 PE2
1. PE1 uses CSPF to calculate a path from PE1 to PE2, on which the IP address of every
hop is specified. PE1 generates an explicit route object (ERO) with the IP address of
each hop and adds the ERO in a Path message. PE1 then creates a PSB and sends the
Path message to P1 according to information in the ERO. Table 5-5 describes objects
carried in the Path message.

Table 5-5 Path message on PE1

Object Value
SESSION Source: PE1-if1; Destination: PE2-if0
RSVP_HOP PE1-if1
EXPLICIT_ROUTE P1-if0; P2-if0; PE2-if0
LABEL LABEL_REQUEST
2. After P1 receives the Path message, it parses the message and creates a PSB according to
information in the message. Then P1 updates the message and sends it to P2 according to
the ERO. Table 5-6 describes objects in the Path message.
– The RSVP_HOP object specifies the IP address of the outbound interface through
which a Path message is sent. Therefore, PE1 sets the RSVP_HOP object to the IP
address of the outbound interface toward P1, and P1 sets the RSVP_HOP field to
the IP address of the outbound interface toward P2.
– P1 deletes the local LSR ID and IP addresses of the inbound and outbound
interfaces from the ERO field in the Path message.
Table 5-6 Path message on P1

Object Value
RSVP_HOP P1-if1
EXPLICIT_ROUTE P2-if0; PE2-if0
LABEL LABEL_REQUEST
3. After receiving the Path message, P2 creates a PSB according to information in the
message, updates the message, and then sends it to PE2 according to the ERO field.
Table 5-7 describes objects in the Path message.
Table 5-7 Path message on P2

Object Value
RSVP_HOP P2-if1
EXPLICIT_ROUTE PE2-if0
LABEL LABEL_REQUEST
4. After PE2 receives the Path message, PE2 knows that it is the egress of the CR-LSP to
be set up according to the Destination field in the Session object. PE2 then allocates a
label and reserves bandwidth, and generates a Resv message based on the local PSB. The
Resv message carries the label allocated by PE2 and is sent to P2.

PE2 uses the address carried in the RSVP_HOP field of the received Path message as the
destination IP address of the Resv message. The Resv message does not carry the ERO
field because it is forwarded along the reverse path. Table 5-8 describes objects in the
Resv message.
NOTE
If a Resv message carries the RESV_CONFIRM object, the receiver needs to send a ResvConf
message to the sender to confirm the resource reservation request.
Table 5-8 Resv message on PE2

Object Value
RSVP_HOP PE2-if0
LABEL 3
RECORD_ROUTE PE2-if0
5. When P2 receives the Resv message, P2 creates an RSB according to information in the
message, allocates a new label, updates the message, and then sends it to P1. Table 5-9
describes objects in the Resv message.
Table 5-9 Resv message on P2

Object Value
RSVP_HOP P2-if0
LABEL 17
RECORD_ROUTE P2-if0; PE2-if0
6. After receiving the Resv message, P1 creates an RSB according to information in the
message, updates the message, and then sends it to PE1. Table 5-10 describes objects in
the Resv message.
PE1 obtains the label allocated by P1 from the received Resv message. Resources are
successfully reserved and a CR-LSP is set up.
Table 5-10 Resv message on P1

Object Value
RSVP_HOP P1-if0
LABEL 18
RECORD_ROUTE P1-if0; P2-if0; PE2-if0

5.2.5.3 Maintenance of Dynamic CR-LSPs
Path Status Maintenance

Soft State
The Resource Reservation Protocol (RSVP) is a soft-state protocol. RSVP-TE periodically
updates RSVP messages to maintain the resource reservation states on nodes.
Resource reservation states include the path state and the reservation state. RSVP nodes along
an established CR-LSP periodically send Path and Resv messages (collectively called RSVP
Refresh messages) to maintain the path and reservation states. RSVP Refresh messages are
used to synchronize path state block (PSB) and reservation state block (RSB) between RSVP
nodes. If an RSVP node does not receive any Refresh message within a specified period, it
deletes the path or reservation state.
RSVP Refresh
RSVP sends its messages as IP datagrams, which cannot ensure a reliable delivery. After a
CR-LSP is set up, the soft state mechanism synchronizes the PSB and RSB between RSVP
neighbors. Each node periodically sends RSVP Refresh messages to its upstream and
downstream nodes.
Refresh messages carry information that has already been advertised. The Time Value field in
Refresh messages specifies the refresh interval.
If a node does not receive any Refresh message about a certain state block after the specified
refreshing intervals elapses, it deletes the state.
A node can send Path and Resv messages to its neighbors in any sequence.
RSVP Srefresh
In addition to state synchronization, RSVP Refresh messages can also be used to detect
reachability between RSVP neighbors and maintain RSVP neighbor relationships. Because
Path and Resv messages are large, sending many RSVP Refresh messages to establish a large
number of CR-LSPs consumes excess network resources. RSVP Summary Refresh (Srefresh)
can address this problem.
RSVP Srefresh is implemented based on extended objects and the following mechanisms:
l Message_ID extension and retransmission
The Message_ID extension defined in RFC 2961 extends objects carried in RSVP
messages. Among the objects, the Message_ID and Message_ID_ACK objects
acknowledge received RSVP messages to ensure reliable RSVP message delivery.
The Message_ID object can also provide the RSVP retransmission mechanism. A node
resets the retransmission timer (Rf seconds) after sending an RSVP message carrying the
Message_ID object. If the node receives no ACK message within Rf seconds, the node
retransmits an RSVP message after (1 + Delta) x Rf seconds. The Delta value depends
on rate at which the sender increases the retransmission interval. The node keeps
retransmitting the message until it receives an ACK message or the retransmission count
reaches the threshold (retransmission multiplier).
l Srefresh messages transmission
Srefresh messages can be sent instead of standard Path or Resv messages to update
RSVP states. These messages reduce the amount of information that must be transmitted
and processed for maintaining RSVP states. When Srefresh messages are sent to update
the RSVP states, standard Refresh messages are suppressed.

Each Srefresh message carries a Message_ID object, which contains multiple message
IDs to identify the Path and Resv states to update. Srefresh implementation depends on
the Message_ID extension. Srefresh messages can only update the states that have been
advertised in Path and Resv messages containing Message_ID objects.
When a node receives a Srefresh message, the node compares the Message_ID in the
message with that saved in the local PSB or RSB. If the two Message_IDs match, the
node updates the local state block, just like it receives a standard Path or Resv message.
If they do not match, the node sends a Srefresh NACK message to the sender. Later, the
node updates the Message_ID and the state block based on the received Path or Resv
message.
A Message_ID object contains a message identifier. When a CR-LSP changes, the
message identifier increases. A node compares the message identifier in the received
Path message with the message identifier saved in the local state block. If they are the
same, the node does not update the state block. If the received message identifier is
larger than the local message identifier, the node updates the state block.
Error Signaling
RSVP-TE uses the following messages to advertise CR-LSP errors:
l PathErr message: is sent by an RSVP node to its upstream node if an error occurs while
this node is processing a Path message. The message is forwarded upstream by
intermediate nodes and finally reaches the ingress node.
l ResvErr message: is sent by an RSVP node to its downstream node if an error occurs
while this node is processing a Resv message. The message is forwarded downstream by
intermediate nodes and finally reaches the egress node.
Path Teardown
After the ingress node receives a PathErr message or an instruction to delete a CR-LSP, it
immediately sends a PathTear message downstream. After receiving this message, the
downstream nodes tear down the CR-LSP and reply with a ResvTear message.
The functions of PathTear and ResvTear messages are as follows:
l PathTear message: is sent to delete path information and functions in the opposite way to
a Path message.
l ResvTear message: is sent to delete the resource reservation state and functions in the
opposite way to a Resv message.
5.2.5.4 RSVP-TE Messages

Nodes on an MPLS TE network send RSVP-TE messages to exchange information.
RSVP Message Format

Each type of RSVP messages contains a common header, followed by multiple objects with
variable lengths and types. Figure 5-17 shows the format of RSVP messages.

Figure 5-17 RSVP message format

Format of RSVP messages
0 4 8 16 31
Version Flags Message Type RSVP Checksum
Send_TTL Reserved RSVP Length
Objects (Variable)
Format of Objects
0 16 24 31
Length Class_Number C-Type
Object Content (Variable)
Table 5-11 describes each field in an RSVP message.
Table 5-11 Fields an RSVP message
Field Length Description
Version 4 bits Indicates the RSVP version number. Currently, the value is
1.
Flags 4 bits Indicates the message flag. Generally, the value is 0. RFC
2961 extends this field to identify whether Summary
Refresh (Srefresh) is supported. If Srefresh is supported,
the value of the Flags field is 0x01.
Message 8 bits Indicates RSVP messages type. For example, the value 1
Type indicates a Path message, and the value 2 indicates a Resv
message.
RSVP 16 bits Indicates the RSVP checksum. The value 0 indicates that
Checksum the checksum of messages is not checked during
transmission.
Send_TTL 8 bits Indicates the TTL of an RSVP message. When a node

receives an RSVP message, it compares the Send_TTL and
the TTL in the IP header to calculate the number of hops
that the message has passed in a non-RSVP area.
Reserved 8 bits Indicates that the field is reserved.
RSVP 16 bits Indicates the total length of an RSVP message, in bytes.

Length
Objects Variable Indicates the objects in an RSVP message. Each RSVP

message contains multiple objects. The carried objects vary
in different types of messages.
Length 16 bits Indicates the total length of an object, in bytes. The value
must be a multiple of 4, and the smallest value is 4.

Field Length Description
Class_Numb 8 bits Identifies an object class. Each object class has a name,
er such as SESSION, SENDER_TEMPLATE, or
TIME_VALUE.
C-Type 8 bits Indicates an object type. Class-Number and C-Type

together identify an object.
Object Variable Indicates the content of an object.

Content
NOTE
For details of each type of RSVP message, see RFC3209 and RFC 2205.
Path Message
RSVP-TE uses Path messages to create RSVP sessions and to maintain path states. A Path
message is sent from the ingress node to the egress node. A path state block (PSB) is created
on each node the Path message passes.
The source IP address of a Path message is the LSR ID of the ingress node and the destination
IP address is the LSR ID of the egress node.
Table 5-12 lists some of the objects carried in a Path message.
Table 5-12 Objects in a Path message

Object Class_Num C-Type Object Content
ber
SESSION 1 1 Carries RSVP session information, such

as the destination address, tunnel ID,
and extend tunnel ID.
RSVP_HOP 3 1 Carries the IP address and index of the

outbound interface on the previous hop
that sends the Path message.
TIME_VALU 5 1 Carries the refresh interval.

E
SENDER_TE 11 1 Carries the sender IP address and LSP

MPLATE ID.
SENDER_TS 12 2 Specifies the traffic characteristics of a

PEC data flow.
LABEL_REQ 19 1 Indicates that label binding is requested

UEST for the path. This object is carried only
in Path messages.


ber
ADSPEC 13 2 Collects QoS parameters of a path, such

as estimated path bandwidth, minimal
path delay, and path MTU.
EXPLICIT_R 20 1 Specifies the path through which an LSP

OUTE passes. The path can be a strict or loose
explicit path. Path messages are then
forwarded along the specified Explicit
Route Object (ERO). Path message
transmission is not restricted by IGP
shortest path.
RECORD_R 21 1 Lists the label switching routers (LSRs)

OUTE that the Path message passes. The
Record Route Object (RRO) can be used
to collect path information and discover
routing loops. It can also be copied to
the next Path message to implement
Route pinning.
SESSION_AT 207 l 1: Specifies the setup priority, holding

TRIBUTE LSP_TUN priority, reservation style, affinity, and
NEL_RA other attributes.
l 7: LSP
Tunnel
Resv Message
After receiving a Path message, the egress node returns a Resv message. The Resv message
carries resource reservation information and is sent hop-by-hop to the ingress node. Each
intermediate node creates and maintains a reservation state block (RSB) and allocates a label.
When the Resv message reaches the ingress node, an LSP is set up successfully.
Table 5-13 describes objects in a Resv message.
Table 5-13 Objects in a Resv message

ber
INTEGRITY 4 1 Carries the authentication key of the

RSVP message.
SESSION 1 1 Carries RSVP session information, such

as the destination address, tunnel ID,
and extend tunnel ID.


ber
RSVP_HOP 3 1 Carries the IP address and the index of

the outbound interface that sends the
Resv message.
TIME_VALU 5 1 Carries the refresh interval. The default

E value is 30s.
STYLE 8 1 Carries the resource reservation style,

which is specified on the ingress node.
FLOW_SPEC 9 l 1: Specifies QoS characteristics of a data

Reserved flow.
(obsolete)
flowspec
object
l 2: Inv-serv
flowspec
object
FILTER_SPE 10 1 Carries the sender IP address and LSP

C ID.
RECORD_R 21 1 Collects the inbound interface IP

OUTE address, LSR-ID, and outbound
interface IP address of each node along
the path.
LABEL 16 1 Carries the assigned label.
RESV_CONF 15 1 Indicates a confirmation of the resource

IRM reservation request. This object carries
the IP address of the node that requests
resource reservation confirmation.
Reservation Styles
A reservation style is the method that an RSVP node uses to reserve resources after receiving
a resource reservation request from the upstream node. The following reservation styles are
supported:
l Fixed Filter (FF) style: creates an exclusive reservation for each sender. A sender does
not share its resource reservation with other senders, and each CR-LSP on a link has a
separate resource reservation.
l Shared Explicit (SE) style: creates a single reservation for a series of selected upstream
senders. CR-LSPs on a link share the same resource reservation.

5.2.6 Traffic Forwarding

Directing Traffic to an MPLS TE Tunnel
A CR-LSP of an MPLS TE tunnel can be established through information advertisement, path
calculation, and path setup. Unlike an LDP LSP, a CR-LSP cannot automatically direct traffic
to the MPLS TE tunnel. The following methods can be used to direct traffic to the CR-LSP:
l Static Route: applies to networks with simple or stable network topologies.
l Tunnel Policy: applies to scenarios where TE VPN services are transmitted over TE
tunnels.
l Auto Route: applies to networks with complex or variable network topologies.
Static Route
The simplest method to direct traffic to an MPLS TE tunnel is to configure a static route and
specify a TE tunnel interface as the outbound interface.
Tunnel Policy
By default, VPN traffic is forwarded over LSP tunnels but not MPLS TE tunnels. Either of
the following tunnel policies can be used to direct VPN traffic to MPLS TE tunnels:
l Select-seq policy: selects a TE tunnel to transmit VPN traffic on the public network by
configuring an appropriate tunnel selection sequence.
l Tunnel binding policy: binds a TE tunnel to a destination address to provide QoS
guarantee.
Auto Route
The auto route feature allows a TE tunnel to participate in IGP route calculations as a logical
link. The tunnel interface is used as the outbound interface of the route. The tunnel is
considered a point-to-point (P2P) link with a specified metric. Two auto route types are
available:
l IGP shortcut: An LSP tunnel is not advertised to neighbor nodes, so it will not be used
by other nodes.
l Forwarding adjacency: An LSP tunnel is advertised to neighboring nodes, so it can be
used by these nodes.
Forwarding adjacency allows tunnel information to be advertised based on IGP neighbor
relationships.
To use the forwarding adjacency feature, nodes on both ends of a tunnel must be located
in the same area.
The following example shows the differences between IGP shortcut and forwarding
adjacency.

Figure 5-18 IGP shortcut and forwarding adjacency
Switch_8
Switch_3 Switch_4
10
5
10 10 Switch_5
TE
MPL Metric=1
10 S TE 0
Switch_2 Tunn
el1 10
10
10
Switch_1
Switch_6 Switch_7
Node Mode Destination Nexthop Cost

Switch_2 Switch_4 25
Switch_5
IGP Shortcut
Switch_2 Tunnel1 10
Switch_7
Switch_1 Tunnel1 20
Switch_5
Forwarding Switch_1 Switch_7 30
Adjacency Switch_2 Tunnel1 10
Switch_7
Switch_1 Tunnel1 20
In Figure 5-18, Switch_7 sets up an MPLS TE tunnel to Switch_2 over the path Switch_7 ->
Switch_6 -> Switch_2. The TE metrics of the links are shown in the figure. On Switch_5 and
Switch_7, routes to Switch_2 and Switch_1 differ depending on the auto route configuration:
l If auto route is not configured, Switch_5 uses Switch_4 as the next hop, and Switch_7
uses Switch_6 as the next hop.
l If auto route is used:
– When Tunnel1 is advertised using IGP shortcut, Switch_5 uses Switch_4 as the
next hop, and Switch_7 uses Tunnel1 as the next hop. Because Tunnel1 is not
advertised to Switch_5, only Switch_7 selects Tunnel1 using the IGP.
– When Tunnel1 is advertised using forwarding adjacency, Switch_5 uses Switch_7
as the next hop, and Switch_7 uses Tunnel1 as the next hop. Because Tunnel1 is
advertised to Switch_5 and Switch_7, both the two nodes select Tunnel1 using the
IGP.
5.2.7 Tunnel Reoptimization

The MPLS TE tunnel reoptimization function enables the ingress node to automatically
optimize the path of an MPLS TE tunnel when topology information is updated. This function
ensures that an MPLS TE tunnel always uses the optimal path.

Background
MPLS TE tunnels are used to optimize traffic distribution on a network. An MPLS TE tunnel
is configured using the initial bandwidth required for services and initial network topology.
The network topology often changes, so the ingress node may not use the optimal path to
forward MPLS packets, causing a waste of network resources. MPLS TE tunnels need to be
optimized after being established.
Implementation
A specific event that occurs on the ingress node can trigger optimization of a CR-LSP. The
optimization enables the CR-LSP to be reestablished over the optimal path with the smallest
metric.
NOTE
l The FF reservation style and tunnel reoptimization cannot be configured together.

l Reoptimization cannot be performed for a CR-LSP that is established over an explicit path.
Reoptimization is implemented in either of the following modes:

l Automatic mode
When the configured reoptimization interval expires, the ingress node uses the
Constrained Shortest Path First (CSPF) algorithm to calculate a new path. If the
calculated path has a smaller metric than the existing path, a CR-LSP is set up over the
new path. After the CR-LSP is successfully set up, the ingress node instructs the
forwarding plane to switch traffic to the new CR-LSP and to tear down the original CR-
LSP. After the original CR-LSP is torn down, reoptimization is complete. If the CR-LSP
fails to be set up, traffic is still forwarded along the existing CR-LSP.
l Manual mode
An administrator can run a reoptimization command to trigger reoptimization.
The Make-Before-Break mechanism is used to ensure nonstop service transmission during

reoptimization. Traffic must switch to a new CR-LSP before the original CR-LSP is torn
down.
5.2.8 MPLS TE Security

RSVP authentication verifies digest messages carried in RSVP messages to defend against
attacks initiated by modified or forged messages. Authentication enhancements can also be
used to prevent replay attacks and packet mis-sequencing. RSVP authentication and its
enhancements improve MPLS TE network security.
Background
RSVP uses raw IP to transmit packets. Raw IP has no security mechanism and is prone to
attacks. RSVP authentication verifies packets using keys to prevent attacks. When the local
RSVP router receives a packet with a sequence number smaller than the local maximum
sequence number, the neighbor relationship is terminated.
Key authentication cannot prevent replay attacks or neighbor relationship termination

resulting from RSVP message mis-sequencing. The RSVP authentication enhancements are
used to address these problems. RSVP authentication enhancements add authentication
lifetime, handshake, and message window mechanisms to enhance RSVP security. The

enhancements also improve RSVP's capability to verify neighbor relationships in a harsh

network environment, such as a congested network.
Concepts
l Raw IP: Similar to User Datagram Protocol (UDP), raw IP is unreliable because it has no
control mechanism to determine whether raw IP datagrams reach their destinations.
l Spoofing attack: An unauthorized router establishes a neighbor relationship with a local
router or sends pseudo RSVP messages to attack the local router. (For example,
requesting the local router to reserve a lot of bandwidth.)
l Replay attack: A remote RSVP router continuously sends packets with sequence
numbers smaller than the maximum sequence number on a local RSVP router. Then the
local router terminates the RSVP neighbor relationship with the remote RSVP router and
the established CR-LSP is torn down.
Implementation
l Key authentication
RSVP authentication protects RSVP nodes from spoofing attacks by verifying keys in
packets exchanged between neighboring nodes. The same key must be configured on
two neighboring nodes before they perform RSVP authentication. A local node uses the
configured key and the Keyed-Hashing for Message Authentication Message Digest 5
(HMAC-MD5) algorithm to calculate a digest for a message, adds this digest as an
integrity object into the message, and then sends the message to the remote node. After
the remote node receives the message, it uses the same key and algorithm to calculate a
digest and checks whether the local digest is the same as the received one. If they match,
the remote node accepts the message. If they do not match, the remote node discards the
message.
l Authentication lifetime
The authentication lifetime specifies the period during which the RSVP neighbor
relationship is retained and provides the following functions:
– Controls the lifetime of an RSVP neighbor relationship when no CR-LSP exists
between the RSVP neighbors. The RSVP neighbor relationship is retained until the
RSVP authentication lifetime expires. The RSVP-TE authentication lifetime does
not affect the status of existing CR-LSPs.
– Prevents continuous RSVP authentication. For example, after RSVP authentication
is enabled between RTA and RTB, RTA continuously sends tampered RSVP
messages with an incorrect key to RTB. As a result, RTB continuously discards the
messages. The authentication relationship between neighbors, however, cannot be
terminated. The authentication lifetime can prevent this situation. When neighbors
receive valid RSVP messages within the lifetime, the RSVP authentication lifetime
is reset. Otherwise, the authentication relationship is deleted after the authentication
lifetime expires.
l Handshake mechanism
The handshake mechanism maintains the RSVP authentication status. After neighboring
nodes authenticate each other, they exchange handshake packets. If they accept the
packets, they record a successful handshake. If a local node receives a packet with a
sequence number smaller than the local maximum sequence number, the local node
processes the packet as follows:
– Discards the packet if it shows that the handshake mechanism is not enabled on the
remote node.

– Discards the packet if it shows that the handshake mechanism is enabled on the
remote node and the local node has a record about a successful handshake. If the
local node does not have a record of a successful handshake with the remote node,
this packet becomes the first to arrive at the local node and the local node starts a
handshake process.
l Message window
A message window saves the received RSVP messages. If the window size is 1, the
system saves only the largest sequence number. If the window size is set to a value
greater than 1, the system saves the specified number of largest sequence numbers. For
example, the window size is set to 10, and the largest sequence number of received
RSVP messages is 80. The sequence numbers from 71 to 80 can be saved if there is no
packet mis-sequencing. If packet mis-sequencing occurs, the local node sequences the
messages and records the 10 largest sequence numbers.
When the window size is not 1, the local RSVP node considers the RSVP message
received from the neighboring node as a valid message in either of the following
situations:
– The sequence number in the received RSVP message is larger than the maximum
sequence number in the window.
– The RSVP message carries an original sequence number that is larger than the
minimum sequence number in the window but is not saved in the window.
The local RSVP node then adds the sequence number of the received RSVP message to
the window and processes the RSVP message. If the sequence number is larger than the
maximum sequence number in the window, the local RSVP node deletes the minimum
sequence number in the window. If the sequence number is smaller than the minimum
sequence number in the window or already exists in the window, the local RSVP node
discards the RSVP message.
NOTE
By default, the window size is 1. The handshake mechanism works when the window size is 1. If the
window size is not 1, the handshake mechanism is affected. When the local RSVP node receives an
RSVP message with a sequence number smaller than the local maximum sequence number, either of the
following situations occurs:
l If the sequence number of the received RSVP message is larger than the minimum sequence
number in the window and is not saved in the window, the local RSVP node correctly processes
the RSVP message.
l If the sequence number already exists in the window, the local RSVP node discards the RSVP
message.
l If the sequence number is smaller than the minimum sequence number in the window, RSVP
determines whether both ends are enabled with the handshake mechanism. If either one is not
enabled with the handshake mechanism, the system discards the RSVP message. If both ends are
enabled with the handshake mechanism, the local and remote ends start the handshake process
again and discard the RSVP message.
For example, the window size is 10, and the window stores sequence numbers 71, 75, and 80. If the
local RSVP node receives an RSVP message with sequence number 72, it adds the sequence number to
the window and correctly processes the RSVP message. If the local RSVP node receives an RSVP
message with sequence number 75, it directly discards the RSVP message. If the local RSVP node
receives an RSVP message with sequence number 70, RSVP determines whether both ends are enabled
with the handshake mechanism. The local and remote ends start the handshake process again only when
they are both enabled with the handshake mechanism.
RSVP Key Management Modes

RSVP keys can be managed in either of the following modes:

l MD5 key
An MD5 key is entered in either cipher text or plain text. The MD5 algorithm has the
following characteristics:
– Each protocol is configured with a separate key and cannot share a key with another
protocol.
– An interface or a node is assigned only one key. To change the key, you must delete
the original key and configure a new one.
l Keychain key
Keychain is an enhanced encryption algorithm. It allows you to define a group of
passwords to form a password string, and to specify encryption and decryption
algorithms and a validity period for each password. When the system sends or receives a
packet, the system selects a valid password. Within the validity period of the password,
the system uses the encryption algorithm configured for the password to encrypt the
packet before sending it out, or the system uses the decryption algorithm configured for
the password to decrypt the packet after receiving it. In addition, the system uses a new
password after the previous one expires, minimizing the risks of password cracking.
Keychain has the following characteristics:
– A keychain authentication password and the encryption and decryption algorithms
must be configured. The password validity period can also be configured.
– Keychain settings can be shared by protocols and managed uniformly.
Keychain can be used on an RSVP interface or node and supports only HMAC-MD5.
MD5 key cannot ensure key. You are advised to use Keychain key.
RSVP Authentication Modes

RSVP defines the following authentication modes:
l Neighbor-oriented authentication
You can configure authentication information, such as authentication keys, based on
different neighbor addresses. RSVP then authenticates each neighbor separately.
A neighbor address can be either of the following:
– IP address of an interface on an RSVP neighboring node
– LSR ID of an RSVP neighboring node
l Interface-oriented authentication
Authentication is configured on interfaces, and RSVP authenticates messages based on
inbound interfaces.
Neighbor-oriented authentication takes precedence over interface-oriented authentication. A

node discards messages if neighbor-oriented authentication fails, and performs interface-
oriented authentication only if neighbor-oriented authentication is not enabled.
5.2.9 MPLS TE Reliability

5.2.9.1 Overview of MPLS TE Reliability

MPLS TE reliability technologies are necessary for the following reasons:
l If attributes of a working MPLS TE tunnel, such as bandwidth, are modified, a new path
is set up for the tunnel using modified attributes, and service traffic is switched to the
new path. Reliability technologies are required to prevent or minimize packet loss in the
process.
l If a node or link on a working MPLS TE tunnel fails, reliability technologies are required
to set up a backup CR-LSP and switch traffic to the backup CR-LSP, while minimizing
packet loss in this process.
l When a node on a working MPLS TE tunnel encounters a control plane failure but its
forwarding plane is still working properly, reliability technologies are required to ensure
nonstop traffic forwarding during fault recovery on the control plane.
MPLS TE provides multiple reliability technologies to ensure high reliability of key services
transmitted over MPLS TE tunnels. Table 5-14 describes these reliability technologies.
Table 5-14 MPLS TE reliability technologies

Reliability Description Function
Technology
Tunnel attribute Ensures reliable traffic transmission when a l Make-Before-Break

update CR-LSP is set up because of attribute
reliability updates.
Fault detection Rapidly detects MPLS TE network faults l RSVP Hello

and triggers protection switching. l BFD for MPLS TE
Traffic Network-level reliability: provides end-to- l CR-LSP Backup

protection end path protection and local protection. l TE FRR
l SRLG
l TE Tunnel
Protection Group
Device-level reliability: ensures that nonstop l RSVP GR

forwarding when the control plane fails on a
node.
5.2.9.2 Make-Before-Break
The make-before-break mechanism prevents traffic loss during a traffic switchover between
two CR-LSPs. This mechanism improves MPLS TE tunnel reliability.
Background
Any change in link or tunnel attributes causes a CR-LSP to be reestablished using new
attributes. Traffic is then switched from the previous CR-LSP to the new CR-LSP. If a traffic
switchover is triggered before the new CR-LSP is set up, some traffic is lost. The make-
before-break mechanism prevents traffic loss.

Implementation
The make-before-break mechanism sets up a new CR-LSP and switches traffic to it before the
original CR-LSP is torn down. This mechanism helps minimize data loss and reduces
bandwidth consumption. Make-before-break is implemented using the shared explicit (SE)
resource reservation style.
The new CR-LSP may compete with the original CR-LSP for bandwidth on some shared
links. The new CR-LSP cannot be established if it fails the competition. The make-before-
break mechanism allows the system to reserve bandwidth used by the original CR-LSP for the
new one, without calculating the reserved bandwidth on shared links. Additional bandwidth is
required if links on the new path do not overlap the links on the original path.
Figure 5-19 Make-before-break mechanism

Path1
Switch_1 Switch_2 Switch_3 Switch_4
Path2
Switch_5
In Figure 5-19, the maximum reservable bandwidth on each link is 60 Mbit/s. A CR-LSP has
been set up along Path 1 (Switch_1 -> Switch_2 -> Switch_3 -> Switch_4) with the
bandwidth of 40 Mbit/s.
A new CR-LSP needs to be set up along Path 2 (Switch_1 -> Switch_5 -> Switch_3 ->
Switch_4) to forward data through the lightly loaded Switch_5. The available bandwidth of
the link Switch_3 -> Switch_4 is only 20 Mbit/s, not enough for the new path. The make-
before-break mechanism can be used in this situation to allow the new CR-LSP to use the
bandwidth of the link between Switch_3 and Switch_4 reserved for the original CR-LSP.
After the new CR-LSP is established, traffic switches to the new CR-LSP, and the original
CR-LSP is torn down.
The make-before-break mechanism can also be used to increase tunnel bandwidth. If the
reservable bandwidth of a shared link increases to the required value, a new CR-LSP can be
established.
On the network shown in Figure 5-19, the maximum reservable bandwidth on each link is 60
Mbit/s. A CR-LSP has been set up along Path 1 with the bandwidth of 30 Mbit/s.
A new CR-LSP needs to be set up along Path 2 to forward data through the lightly loaded
Switch_5, and the path bandwidth needs to increase to 40 Mbit/s. The available bandwidth of
the link Switch_3 -> Switch_4 is only 30 Mbit/s. The make-before-break mechanism can be
used in this situation. This mechanism allows the new CR-LSP to use the bandwidth of the
link between Switch_3 and Switch_4 reserved for the original CR-LSP, and reserves an
additional bandwidth of 10 Mbit/s for the new path. After the new CR-LSP is set up, traffic is
switched to the new CR-LSP, and the original CR-LSP is torn down.

Switching and Deletion Delays

If a node is busy but its upstream or downstream node is idle, a CR-LSP may be torn down
before a new CR-LSP is established, causing a temporary traffic interruption.
The make-before-break mechanism uses switching and deletion delay timers to prevent
temporary traffic interruption. When the two timers are configured, the system switches traffic
to a new CR-LSP after the switching delay time, and then deletes the original CR-LSP after
the deletion delay time.
5.2.9.3 RSVP Hello

RSVP Hello mechanism is used to rapidly detect reachability between RSVP nodes and
trigger path protection provided by TE FRR. In addition, a node can use the RSVP Hello
mechanism to detect whether a neighboring node is in Restart state so it can help the
neighboring node in implementing RSVP GR.
Background
RSVP Refresh messages can synchronize PSB and RSB between nodes, monitor reachability
between RSVP neighbors, and maintain RSVP neighbor relationships.
This soft state mechanism detects neighbor relationships using Path and Resv messages. The
detection speed is low and a link failure cannot promptly trigger a service traffic switchover.
RSVP Hello is introduced to solve this problem.
Implementation
RSVP Hello is implemented as follows:
1. Hello handshake
Figure 5-20 Hello handshake mechanism
Hello Repuest
LSRA Hello ACK LSRB
As shown in Figure 5-20, LSRA and LSRB are directly connected.

– When RSVP Hello is enabled on the interface of LSRA, LSRA sends a Hello
Request message to LSRB.
– If LSRB is enabled with RSVP Hello, LSRB replies to LSRA with a Hello ACK
message after receiving the Hello Request message.
– After LSRA receives the Hello ACK message from LSRB, LSRA determines that
the neighbor LSRB is reachable.
2. Neighbor loss detection
After a successful Hello handshake, LSRA and LSRB exchange Hello messages. If
LSRA receives no Hello ACK message from LSRB after sending three consecutive
Hello Request messages to LSRB, LSRA considers the neighbor LSRB lost. TE FRR is
triggered and LSRA restarts an RSVP Hello handshake.

3. Neighbor restart detection

After LSRA detects the loss of the neighbor LSRB (they are both RSVP GR capable),
LSRA waits for the Hello Request message carrying a GR extension from LSRB. After
receiving this message, LSRA helps LSRB restore RSVP state information and sends a
Hello ACK message to LSRB. LSRB receives the Hello ACK message from LSRA and
knows that LSRA is helping it implement GR. LSRA and LSRB exchange Hello
messages to maintain the restored GR status.
NOTE
When LSRA and LSRB are located on the same CR-LSP:

l If GR is disabled but TE FRR is enabled on LSRA, LSRA switches traffic to the bypass CR-LSP
to ensure uninterrupted traffic transmission when detecting loss of the neighbor LSRB.
l If GR is enabled on LSRA, LSRA preferentially uses RSVP GR to ensure uninterrupted traffic
transmission on the forwarding plane upon a control plane failure.
Usage Scenario
RSVP Hello applies to scenarios with TE FRR or RSVP GR enabled.
5.2.9.4 CR-LSP Backup

CR-LSP backup provides end-to-end protection for an MPLS TE tunnel. If the ingress node
detects a failure of the primary CR-LSP, it switches traffic to a backup CR-LSP. After the
primary CR-LSP recovers, traffic switches back to the primary CR-LSP.
Concepts
CR-LSP backup functions include hot standby, ordinary backup, and the best-effort path:
l Hot standby: A hot-standby CR-LSP is set up immediately after the primary CR-LSP is
set up. When the primary CR-LSP fails, traffic switches to the hot-standby CR-LSP.
l Ordinary backup: An ordinary backup CR-LSP can be set up only after a primary CR-
LSP fails. The ordinary backup CR-LSP takes over traffic when the primary CR-LSP
fails.
l Best-effort path: If both the primary and backup CR-LSPs fail, a best-effort path is set up
and takes over traffic.
In Figure 5-21, the primary CR-LSP is set up over the path PE1 -> P1 -> P2 -> PE2, and
the backup CR-LSP is set up over the path PE1 -> P3 -> PE2. When both CR-LSPs fail,
PE1 sets up a best-effort path PE1 -> P4 -> PE2 to take over traffic.

Figure 5-21 Best-effort path
P3
Backup CR-LSP
PE1 P1 Primary P2 PE2

CR-LSP
Best-effort
path
P4
NOTE
A best-effort path has no bandwidth reserved for traffic, but has an affinity and a hop limit
configured to control the nodes it passes.
Implementation
The process of CR-LSP backup is as follows:
1. CR-LSP backup deployment
Determine the paths, bandwidth values, and deployment modes. Table 5-15 lists CR-
LSP backup deployment items.
Table 5-15 CR-LSP backup deployment
It Hot Standby Ordinary Backup Best-Effort

e Path
m
Pa Determine whether the paths of The path of an ordinary A best-effort

th primary and hot-standby CR- CR-LSP can partially path is
LSPs partially overlap. A hot- overlap the path of the automatically
standby CR-LSP can be primary CR-LSP, no calculated by
established over an explicit path. matter whether the the ingress
A hot-standby CR-LSP supports ordinary CR-LSP is set node.
the following attributes: up along an explicit or A best-effort
implicit path. path supports
l Explicit path
An ordinary backup CR- the following
l Affinity attribute LSP supports the attributes:
l Hop limit following attributes: l Affinity
l Path overlapping l Explicit path attribute
l Affinity attribute l Hop limit
l Hop limit

It Hot Standby Ordinary Backup Best-Effort

e Path
m
Ba A hot-standby CR-LSP has the An ordinary backup CR- A best-effort

nd same bandwidth as a primary CR- LSP has the same path is only a
wi LSP by default. Dynamic bandwidth as a primary protection path
dt bandwidth protection can CR-LSP. that does not
h ensure that a hot-standby CR-LSP have reserved
does not use additional bandwidth bandwidth.
when it is not transmitting traffic.
De Can be established without Can be established Can be

pl attribute templates. without attribute established
oy templates. without
m attribute
en templates.
t
m Can be established using attribute Can be established using Automatically
od templates. attribute templates. established and
e does not
support
attribute
templates.
Co l If a hot-standby CR-LSP is l If an ordinary CR- -

nfi established without an LSP is established
gu attribute template, the hot- without an attribute
rat standby CR-LSP can be used template, the ordinary
io together with a best-effort CR-LSP can only be
n path to protect the primary used alone to protect
co CR-LSP. the primary CR-LSP.
m l If a hot-standby CR-LSP is l If an ordinary CR-
bi established using an attribute LSP is established
na template, the hot-standby CR- using an attribute
tio LSP can be used together with template, the ordinary
n an ordinary backup CR-LSP backup CR-LSP can
and a best-effort path to be used together with
protect the primary CR-LSP. a hot-standby backup
CR-LSP and a best-
effort path to protect
the primary CR-LSP.

Table 5-16 CR-LSP backup modes
Backup Advantage Shortcoming

Mode Description
Hot standby A hot-standby CR-LSP is A rapid traffic If dynamic

set up over a separate path switchover can be bandwidth
immediately after a primary performed. adjustment is
CR-LSP is set up. disabled,
additional
bandwidth needs
to be reserved for
a hot-standby
CR-LSP.
Ordinary The system attempts to set No additional Ordinary backup

backup up an ordinary backup CR- bandwidth is performs a traffic
LSP if a primary CR-LSP needed. switchover
fails. slower than hot
standby.
Best-effort The system establishes a Establishing a Some quality of

path best-effort path over an best-effort path is service (QoS)
available path if both the easy and a few requirements
primary and backup CR- constraints are cannot be met.
LSPs fail. needed.
2. Backup CR-LSP setup

Multiple CR-LSP backup methods may be supported for a tunnel. The ingress node uses
these methods in turn until a CR-LSP is successfully established.
The rules for establishing a backup CR-LSP are as follows:
a. If new tunnel configuration is committed or a tunnel goes Down, the ingress node
attempts to establish a hot-standby CR-LSP, an ordinary backup CR-LSP, and a
best-effort path in turn, until a CR-LSP is successfully established.
b. A maximum of three CR-LSP attribute templates can be configured for hot-standby
CR-LSPs or ordinary backup CR-LSPs. These templates are prioritized. The ingress
node tries these templates in descending order of priority until a CR-LSP is
successfully established.
c. If the status of a CR-LSP established using a lower-priority attribute template
changes, the ingress node attempts to establish a CR-LSP using a higher-priority
attribute template. The make-before-break mechanism ensures nonstop traffic
forwarding when a new CR-LSP is being established.
d. If a stable CR-LSP has been established using any of the attribute templates, you
can lock the used attribute template. After the attribute template is locked, the
ingress node will not use a higher-priority attribute template to establish a CR-LSP.
This locking function prevents unnecessary traffic switchovers and lowers system
costs.
Currently, switches support the following backup modes and you can choose one as
required.
– Hot standby (manually configured)

– Hot standby (manually configured) and best-effort path

– Hot standby (configured using a TE attribute template)
– Hot standby (configured using a TE attribute template) and ordinary backup
(configured using a TE attribute template)
– Hot standby (configured using a TE attribute template) and best-effort path
– Hot standby (configured using a TE attribute template), ordinary backup
(configured using a TE attribute template), and best-effort path
– Ordinary backup (manually configured)
– Ordinary backup (configured using a TE attribute template)
– Ordinary backup (configured using a TE attribute template) and best-effort path
– Best-effort path
3. Backup CR-LSP attribute modification
If attributes of a backup CR-LSP are modified, the ingress node uses the make-before-
break mechanism to reestablish the backup CR-LSP with the updated attributes. After
that backup CR-LSP has been successfully reestablished, traffic on the original backup
CR-LSP (if it is transmitting traffic) switches to this new backup CR-LSP, and then the
original backup CR-LSP is torn down.
4. Fault detection
CR-LSP backup supports the following fault detection functions:
– Default error signaling mechanism of RSVP-TE: The fault detection speed is
relatively slow.
– Bidirectional forwarding detection (BFD) for CR-LSP: This function is
recommended because it implements fast fault detection.
5. Traffic switchover
After the primary CR-LSP fails, the ingress node attempts to switch traffic from the
primary CR-LSP to a hot-standby CR-LSP. If the hot-standby CR-LSP is unavailable,
the ingress node attempts to switch traffic to an ordinary backup CR-LSP. If the ordinary
backup CR-LSP is unavailable, the ingress attempts to switch traffic to a best-effort path.
6. Traffic switchback
Traffic switches back to a path based on priorities of the available CR-LSPs. Traffic will
first switch to the primary CR-LSP. If the primary CR-LSP is unavailable, traffic will
switch to the hot-standby CR-LSP. The ordinary CR-LSP has the lowest priority.
Dynamic Bandwidth Protection for Hot-standby CR-LSPs

Hot-standby CR-LSPs support dynamic bandwidth protection. The dynamic bandwidth
protection function allows a hot-standby CR-LSP to obtain bandwidth resources only after the
hot-standby CR-LSP takes over traffic from a faulty primary CR-LSP. This function improves
bandwidth efficiency and reduces network costs.
Dynamic bandwidth protection ensures that the hot-standby CR-LSP does not use bandwidth
when the primary CR-LSP is transmitting traffic. The dynamic bandwidth protection process
is as follows:
1. If the primary CR-LSP fails, traffic immediately switches to the hot-standby CR-LSP
with 0 bit/s bandwidth. The ingress node uses the make-before-break mechanism to
establish a hot-standby CR-LSP.

2. After the new hot-standby CR-LSP has been successfully established, the ingress node
switches traffic to this CR-LSP and tears down the hot-standby CR-LSP with 0 bit/s
bandwidth.
3. After the primary CR-LSP recovers, traffic switches back to the primary CR-LSP. The
hot-standby CR-LSP then releases the bandwidth, and the ingress node establishes
another hot-standby CR-LSP with 0 bit/s bandwidth.
Path Overlapping for a Hot-standby CR-LSP

The path overlapping function can be configured for hot-standby CR-LSPs. This function
allows a hot-standby CR-LSP to use some links of a primary CR-LSP. After the hot-standby
CR-LSP is established, it can protect traffic on the primary CR-LSP.
5.2.9.5 TE FRR
Traffic engineering fast reroute (TE FRR) provides link protection and node protection for
MPLS TE tunnels. If a link or node fails, TE FRR rapidly switches traffic to a backup path,
minimizing traffic loss.
Background
A link or node failure triggers a primary/backup CR-LSP switchover. The switchover is not
completed until the IGP routes of the backup path converge, CSPF calculates a new path, and
a new CR-LSP is established. Traffic is lost during this process.
TE FRR technology can prevent traffic loss during a primary/backup CR-LSP switchover.
After a link or node fails, TE FRR establishes a CR-LSP that bypasses the faulty link or node.
The bypass CR-LSP can then rapidly take over traffic to minimize loss. At the same time, the
ingress node reestablishes a primary CR-LSP.
Concepts
Figure 5-22 Local protection
PLR Primary CR-LSP MP
LSRA LSRB LSRC LSRD
Bypass CR-LSP
LSRE
Table 5-17 explains the components shown in Figure 5-22.

Table 5-17 TE FRR concepts

Concept Description
Primary CR-LSP Protected CR-LSP.
Bypass CR-LSP CR-LSP protecting the primary CR-LSP. A bypass CR-LSP is

usually in idle state and does not forward service traffics. If the
bypass CR-LSP is required to forward service data, it must be
assigned sufficient bandwidth.
PLR Point of local repair, ingress node of a bypass CR-LSP. The PLR
can be the ingress node but not the egress node of the primary CR-
LSP.
MP Merge point, egress node of a bypass CR-LSP. It must be on the

path of the primary CR-LSP but cannot be the ingress node of the
primary CR-LSP.
Table 5-18 describes TE FRR protection functions.
Table 5-18 TE FRR protection functions

Cla Type Description
ssif
ied
by
Prot Link In Figure 5-23 below, the primary CR-LSP passes through the direct
ecte protectio link between the PLR (LSRB) and MP (LSRC). Bypass LSP 1 can
d n protect this link, which is called link protection.
obje
ct Node In Figure 5-23 below, the primary CR-LSP passes through LSRC
protectio between the PLR (LSRB) and MP (LSRD). Bypass LSP 2 can protect
n LSRC, which is called node protection.
Ban Bandwid A bypass CR-LSP is assigned bandwidth higher than or equal to the
dwi th primary CR-LSP bandwidth, so that the bypass CR-LSP protects the
dth protectio path and bandwidth of the primary CR-LSP.
n
Non- A bypass CR-LSP has no bandwidth and protects only the path of the
bandwidt primary CR-LSP.
h
protectio
n
Imp Manual A bypass CR-LSP is manually configured and bound to a primary CR-
lem protectio LSP.
enta n
tion

Cla Type Description

ssif
ied
by
Auto An auto FRR-enabled node automatically establishes a bypass CR-LSP.

protectio The node binds the bypass CR-LSP to a primary CR-LSP if the node
n receives an FRR protection request and the FRR topology requirements
are met.
Figure 5-23 TE FRR link and node protection
PLR MP MP
LSRB LSRC LSRD
Primary CR-LSP
LSRA LSRE
LSRF LSRG LSRH

Bypass LSP 1 Bypass LSP 2
Link protection Node protection
Link Fault
Node Fault
NOTE
A bypass CR-LSP supports the combination of protection modes. For example, manual protection, node
protection, and bandwidth protection can be implemented together on a bypass CR-LSP.
Implementation
TE FRR is implemented as follows:
1. Setup of a primary CR-LSP
A primary CR-LSP is set up in the same way as a common CR-LSP except that the
ingress node adds flags into the SESSION_ATTRIBUTE object in a Path message. For
example, the local protection desired flag indicates that the primary CR-LSP requires a
bypass CR-LSP, and the bandwidth protection desired flag indicates that the primary CR-
LSP requires bandwidth protection.
2. Binding between a bypass CR-LSP and the primary CR-LSP
FRR TE searches for a suitable bypass CR-LSP for the primary CR-LSP. A bypass CR-
LSP can be bound to a primary CR-LSP only if the primary CR-LSP has a local
protection desired flag. The binding process is completed before a CR-LSP switchover.
Before binding a bypass CR-LSP to a primary CR-LSP, the PLR must obtain the
following from the Record Route Object (RRO) in the received Resv message: the

outbound interface of the bypass CR-LSP, the next hop label forwarding entry (NHLFE),
the label switching router (LSR) ID of the MP, the label allocated by the MP, and the
protection type.
The PLR on the primary CR-LSP already knows its next hop (NHOP) and next NHOP
(NNHOP). If the egress LSR ID of the bypass CR-LSP is the same as the NHOP LSR
ID, the bypass CR-LSP provides link protection. If the egress LSR ID of the bypass CR-
LSP is the same as the NNHOP LSR ID, the bypass CR-LSP provides node protection.
In Figure 5-24, bypass LSP 1 protects the link between LSRB and LSRC, and bypass
LSP 2 protects the node between LSRB and LSRD.
Figure 5-24 Binding between bypass and primary CR-LSPs
PLR NHOP NNHOP

LSRB LSRC LSRD
Primary CR-LSP
LSRA LSRE
LSRF LSRG LSRH

Bypass CR-LSP 1 Bypass CR-LSP 2
Link protection Node protection
Link Fault
Node Fault
If multiple bypass CR-LSPs are established, the PLR checks whether the bypass CR-LSP
protect bandwidth, their implementations, and protected objects in sequence. Bypass CR-
LSPs providing bandwidth protection are preferred over those that do not provide
bandwidth protection. Manual bypass CR-LSPs are preferred over auto bypass CR-LSPs.
Bypass CR-LSPs providing node protection are preferred over those providing link
protection. Figure 5-24 shows two bypass CR-LSPs. If both the bypass CR-LSPs
provide bandwidth protection and are manually configured, bypass LSP 2 is bound to the
primary CR-LSP. (Bypass LSP 2 provides node protection, and bypass LSP 1 provides
link protection.) If bypass LSP 1 provides bandwidth protection but bypass LSP 2 does
not, bypass LSP 1 is bound to the primary CR-LSP.
After the binding is complete, the primary CR-LSP's NHLFE records the bypass CR-
LSP's NHLFE index and an inner label that the MP allocates to the upstream node on the
primary CR-LSP. This label is used to forward traffic during a primary/backup CR-LSP
switchover.
3. Fault detection
– Link protection uses a link layer protocol to detect and report faults. The speed of
fault detection at the link layer depends on the link type.
– Node protection uses a link layer protocol to detect link faults. If no fault occurs on
a link, RSVP Hello or BFD for RSVP is used to detect faults on the protected
node.
As soon as a link or node fault is detected, an FRR switchover is triggered.

NOTE
l In node protection, only the link between the protected node and the PLR is protected. The
PLR cannot detect faults on the link between the protected node and the MP.
l Link fault detection, BFD, and RSVP Hello mechanisms detect a failure at descending speeds.
4. Switchover
When the primary CR-LSP fails, service traffic and RSVP messages are switched to the
bypass CR-LSP, and the switchover event is advertised to the upstream nodes. Upon
receiving a data packet, the PLR pushes an inner label and an outer label into the packet.
The inner label is allocated by the MP to the upstream node on the primary CR-LSP, and
the outer label is allocated by the next hop on the bypass CR-LSP to the PLR. The
penultimate hop of the bypass CR-LSP pops the outer label and forwards the packet with
only the inner label to the MP. The MP forwards the packet to the next hop along the
primary CR-LSP according to the inner label.
Figure 5-25 shows nodes on the primary and bypass CR-LSPs, labels allocated to the
nodes, and behaviors that the nodes perform. The bypass CR-LSP provides node
protection. If LSRC or the link between LSRB and LSRC fails, the PLR (LSRB) swaps
the inner label 1024 to 1022, pushes the outer label 34 into a packet, and forwards the
packet to the next hop along the bypass CR-LSP. The lower part of Figure 5-25 shows
the packet forwarding process after a TE FRR switchover.

Figure 5-25 Packet forwarding before and after a TE FRR switchover
Packet forwarding
before a TE FRR
switchover
Bypass CR-LSP
Primary CR-LSP
PLR MP
LSRA LSRB LSRC LSRD LSRE

1024 1025 1022 IP
IP IP IP
Swap Swap Pop
35 36
Swap 1022 Swap 1022 Pop 36
IP IP
Packet forwarding
after a TE FRR
switchover 34
1022 1022
IP IP
PLR MP
1024 IP
LSRA IP LSRB LSRC LSRD LSRE
Swap 1024→1022
Push 34
label assigned for the
primary CR-LSP
label assigned for the
bypass CR-LSP
Link fault
Node fault
5. Switchback
After a TE FRR switchover is complete, the ingress node of the primary CR-LSP
reestablishes the primary CR-LSP using the make-before-break mechanism. Service
traffic and RSVP messages are switched back to the primary CR-LSP after the primary
CR-LSP is successfully reestablished. The reestablished primary CR-LSP is called a
modified CR-LSP. The make-before-break mechanism allows the original primary CR-
LSP to be torn down only after the modified CR-LSP is set up successfully.
NOTE
FRR does not take effect if multiple nodes fail simultaneously. After data is switched from the primary
CR-LSP to the bypass CR-LSP, the bypass CR-LSP must remain Up to ensure data forwarding. If the
bypass CR-LSP fails, the protected data cannot be forwarded using MPLS, and the FRR function fails.
Even if the bypass CR-LSP is reestablished, it cannot forward data. Data forwarding will be restored
only after the primary CR-LSP restores or is reestablished.

Other Functions
l N:1 protection
TE FRR supports N:1 protection mode, in which a bypass CR-LSP protects multiple
primary CR-LSPs.
Cooperation Between CR-LSP Backup and TE FRR

1. Combination of CR-LSP backup and TE FRR
– CR-LSP ordinary backup and TE FRR: TE FRR can rapidly detect a link failure
and switch traffic to the bypass CR-LSP. When both primary and bypass CR-LSPs
fail, a backup CR-LSP is established to take over traffic.
– CR-LSP hot standby and TE FRR: TE FRR can rapidly detect a link failure and
switch traffic to the bypass CR-LSP. Link failure information is then sent to the
tunnel ingress node through a signaling protocol and traffic is switched to a backup
CR-LSP.
2. Association between CR-LSP backup and TE FRR
After TE FRR local protection and backup CR-LSP end-to-end protection are deployed,
the system supports associated protection of bypass and backup CR-LSPs. After
association between CR-LSP backup and TE FRR is enabled:
– If CR-LSP ordinary backup is enabled, the following situations occur:
When the protected link or node fails, TE FRR switches traffic to the bypass CR-
LSP and attempts to restore the primary CR-LSP and to set up a backup CR-LSP.
After the backup CR-LSP is set up successfully but the primary CR-LSP has not
restored, traffic is switched to the backup CR-LSP.
After the primary CR-LSP restores successfully, traffic is switched back to the
primary CR-LSP, regardless of whether traffic is transmitted along the bypass or
backup CR-LSP.
If the backup CR-LSP fails to be set up and the primary CR-LSP is not restored,
traffic is transmitted along the bypass CR-LSP.
– If CR-LSP hot standby is enabled, the following situations occur:
When the protected link or node fails and the backup CR-LSP is Up, traffic is
switched to the bypass CR-LSP and then immediately to the backup CR-LSP. At the
same time, the ingress node attempts to restore the primary CR-LSP.
If the backup CR-LSP is Down, traffic is switched in the same manner as in
ordinary backup mode.
In CR-LSP hot standby mode, the ingress node attempts to set up a backup CR-LSP
while the primary CR-LSP is Up. After the backup CR-LSP is created successfully, more
bandwidth is occupied. In CR-LSP ordinary backup mode, the ingress node starts to set
up a backup CR-LSP only when the primary CR-LSP is in FRR-in-use state. No more
bandwidth is occupied when the primary CR-LSP is working properly. Therefore,
association between CR-LSP ordinary backup and TE FRR is recommended.
5.2.9.6 SRLG
Shared risk link group (SRLG) is a constraint to calculating a backup or a bypass CR-LSP on
a network with CR-LSP hot standby or TE FRR configured. SRLG prevents bypass and
primary CR-LSPs from being set up on links with the same risk level, which enhances TE
tunnel reliability.

Background
A network administrator often uses CR-LSP hot standby or TE FRR technology to ensure
MPLS TE tunnel reliability. However, CR-LSP hot standby or TE FRR may fail in real-world
application.
Figure 5-26 SRLG diagram

Path1
PE1 P1 P2 PE2
Path2
Logical topology
P3
SRLG
PE1 P1 P2 PE2
NE1
Physical topology
Optical transport
device
P3
Shared link
In Figure 5-26, Path 1 is the primary CR-LSP and Path 2 is the bypass CR-LSP. The link
between P1 and P2 requires TE FRR protection.
Core nodes P1, P2, and P3 on the backbone network are connected by a transport network
device. In Figure 5-26, the top diagram is an abstract version of the actual topology below.
NE1 is a transport network device. During network construction and deployment, two core
nodes may share links on the transport network. For example, the yellow links in Figure 5-26
are shared by P1, P2, and P3. A shared link failure affects primary and bypass CR-LSPs and
makes FRR protection invalid. To enable TE FRR to protect the CR-LSP, bypass and primary
CR-LSPs must be set up over links of different risk levels. SRLG technology can be deployed
to meet this requirement.
However, an SRLG is a set of links that share the same risks. If one of the links fails, other
links in the group may fail as well. Therefore, protection fails even if other links in the group
function as the hot standby or bypass CR-LSP for the failed link.
Implementation
SRLG is a link attribute, expressed by a numeric value. Links with the same SRLG value
belong to a single SRLG.

The SRLG value is advertised to the entire MPLS TE domain using IGP TE. Nodes in a
domain can then obtain SRLG values of all the links in the domain. The SRLG value is used
in CSPF calculations together with other constraints such as bandwidth.
MPLS TE SRLG works in either of the following modes:
l Strict mode: The SRLG value is a mandatory constraint when CSPF calculates paths for
hot standby and bypass CR-LSPs.
l Preferred mode: The SRLG value is an optional constraint when CSPF calculates paths
for hot standby and bypass CR-LSPs. If CSPF fails to calculate a path based on the
SRLG value, CSPF excludes the SRLG value when recalculating the path.
Usage Scenario
SRLG applies to networks with CR-LSP hot standby or TE FRR configured.
Benefits
SRLG constrains the path calculation for hot standby and bypass CR-LSPs, which avoids
primary and bypass CR-LSPs with the same risk level.
5.2.9.7 TE Tunnel Protection Group

A tunnel protection group provides end-to end protection for MPLS TE tunnels. If a working
tunnel in a protection group fails, traffic is switched to a protection tunnel.
Concepts
Tunnel protection group concepts are as follows:
l Working tunnel: protected tunnel.
l Protection tunnel: tunnel that protects the working tunnel.
l Protection switchover: If a working tunnel in a protection group fails, traffic is rapidly
switched to a protection tunnel, enhancing network reliability.
Figure 5-27 Tunnel protection group
Working tunnel-1
LSRA LSRB
Protection tunnel-3
Data flow when the primary

tunnel is normal
Data flow when the primary
tunnel fails
Working tunnel-1 fails
As shown in Figure 5-27, on LSRA, tunnel-3 is specified as the protection tunnel for working
tunnel-1. When a failure of tunnel-1 is detected, the ingress node switches traffic to protection

tunnel-3. After tunnel-1 is restored, the system determines whether to switch traffic back to
the working tunnel according to the configured switchback policy.
Implementation
A tunnel protection group uses a configured protection tunnel to protect a working tunnel,
improving tunnel reliability. Configuring working and protection tunnels over separate links is
recommended.
Table 5-19 describes the process of implementing a tunnel protection group.
Table 5-19 Tunnel protection group implementation
Step Description
Tunnel The process of setting up working and protection tunnels is the same as that of
setup setting up a common tunnel. The working and protection tunnels must have
the same ingress and egress nodes. Protection tunnel attributes, however, can
differ from working tunnel attributes. To better protect the working tunnel,
configure working and protection tunnels over separate links when deploying
a tunnel protection group.
NOTE
l The protection tunnel cannot be protected by any other protection tunnel or enabled
with TE FRR.
l You can configure independent attributes for the protection tunnel, which facilitates
network planning.
Binding After a tunnel protection group is configured for a working tunnel, the
protection tunnel with a specified tunnel ID is bound to the working tunnel.
Fault To implement fast protection switchover, the tunnel protection group detects
detection faults using the BFD for CR-LSP mechanism in addition to MPLS TE's
detection mechanism.
Protection The tunnel protection group supports the following switchover modes:
switchove l Manual switchover: A network administrator runs a command to switch
r traffic.
l Auto switchover: The ingress node automatically switches traffic when
detecting a fault on the working tunnel.
In auto switchover mode, you can set the switchover period.
Switchbac After the working tunnel is restored, the ingress node determines whether to
k switch traffic back to the working tunnel according to the configured
switchback policy.
1:1 and N:1 Protection

A tunnel protection group works in either 1:1 or N:1 mode. The 1:1 mode enables a protection
tunnel to protect only one working tunnel. The N:1 mode enables a protection tunnel to
protect multiple working tunnels.

Figure 5-28 Tunnel protection group in N:1 mode
Working tunnel-1
LSRA Working tunnel-2 LSRB
Protection tunnel-3
Data flow when primary

tunnel is normal
Data flow when primary
tunnel is failed
Differences Between CR-LSP Backup and Tunnel Protection Group

CR-LSP backup and tunnel protection group are both end-to-end protection mechanisms for
MPLS TE tunnels. Table 5-20 lists the differences between the two mechanisms.
Table 5-20 Differences between CR-LSP backup and tunnel protection group
Item CR-LSP Backup Tunnel Protection Group
Protected object Primary and backup CR-LSPs The protection tunnel protects the
are set up in the same tunnel. working tunnel.
The backup CR-LSP protects
the primary CR-LSP.
TE FRR The primary CR-LSP supports The working tunnel supports TE

TE FRR while the backup CR- FRR while the tunnel protection does
LSP does not. not.
LSP attributes The primary and backup CR- Attributes of tunnels in a tunnel
LSPs have the same attributes protection group are independent
(such as bandwidth, setup from each other. For example, a
priority, and holding priority), protection tunnel without bandwidth
except the TE FRR attributes. can protect a working tunnel
requiring bandwidth protection.
Protection Supports 1:1 protection mode. Supports 1:1 and N:1 protection
mode Each primary CR-LSP has a modes. A protection tunnel can
backup CR-LSP. protect multiple working tunnels. If a
working tunnel fails, data is switched
to the shared protection tunnel.
5.2.9.8 BFD for MPLS TE

Bidirectional Forwarding Detection (BFD) can quickly detect faults in an MPLS TE tunnel
and trigger a traffic switchover when a fault is detected, improving network reliability.

Background
In most cases, MPLS TE uses TE FRR, CR-LSP backup, and TE tunnel protection group to
enhance network reliability. These technologies detect faults using the RSVP Hello or RSVP
Srefresh mechanism, but the detection speed is slow. When a Layer 2 device such as a switch
or hub exists between two nodes, the traffic switchover speed is even slower, leading to traffic
loss. BFD uses the fast packet transmission mode to quickly detect faults on MPLS TE
tunnels, so that a service traffic switchover can be triggered quickly to better protect the
MPLS TE service.
Concepts
Based on BFD session setup modes, BFD is classified into the following types:
l Static BFD: Local and remote discriminators of BFD sessions are manually configured.
l Dynamic BFD: Local and remote discriminators of BFD sessions are automatically
allocated by the system.
NOTE
For details about BFD, see BFD Configuration in the S1720, S2700, S5700, and S6720
V200R012(C00&C20) Configuration Guide - Reliability.
Implementation
In MPLS TE, BFD is implemented in the following methods for different detection scenarios:
l BFD for RSVP
BFD for Resource Reservation Protocol (RSVP) detects faults on links between RSVP
nodes in milliseconds. BFD for RSVP applies to TE FRR networking where a Layer 2
device exists between the PLR and its RSVP neighbor along the primary CR-LSP.
l BFD for CR-LSP
BFD for CR-LSP can rapidly detect faults on CR-LSPs and notify the forwarding plane
of the faults to ensure a fast traffic switchover. BFD for CR-LSP is usually used together
with a hot-standby CR-LSP or a tunnel protection group.
l BFD for TE Tunnel
When an MPLS TE tunnel functions as a virtual private network (VPN) tunnel on the
public network, BFD for TE tunnel detects faults in the entire TE tunnel. This triggers
traffic switchovers for VPN applications including VPN FRR and virtual leased line
(VLL) FRR.
BFD for RSVP

When Layer 2 devices exist between neighboring RSVP nodes, the two nodes can detect a
link failure based only on the RSVP Hello mechanism. Several seconds are required to
complete a switchover. This results in the loss of a great deal of data.
BFD for RSVP detects faults in milliseconds on links between RSVP neighboring nodes.
BFD for RSVP applies to the TE FRR networking where Layer 2 devices exist between the
PLR and its RSVP neighbor along the primary CR-LSP, as shown in Figure 5-29.

Figure 5-29 BFD for RSVP

BFD Session BFD Session
BFD Session BFD Session
BFD for RSVP can share BFD sessions with BFD for OSPF, BFD for IS-IS, or BFD for
Border Gateway Protocol (BGP). Therefore, the local node selects the minimum parameter
values among the shared BFD session as the local BFD parameters. The parameters include
the transmit interval, the receive interval, and the local detection multiplier.
BFD for CR-LSP

BFD for CR-LSP can rapidly detect faults on CR-LSPs and notify the forwarding plane of the
faults to ensure a fast traffic switchover. BFD for CR-LSP usually works with a hot-standby
CR-LSP or tunnel protection group.
A BFD session is bound to a CR-LSP. That is, a BFD session is set up between ingress and
egress nodes. A BFD packet is sent by the ingress node and forwarded to the egress node
along a CR-LSP. The egress node then responds to the BFD packet. The BFD session at the
ingress node can rapidly detect the status of the path through which the LSP passes.
Upon detecting a link failure, BFD notifies the forwarding plane of the failure. The
forwarding plane searches for a backup CR-LSP and switches traffic to it. The forwarding
plane then reports fault information to the control plane. If dynamic BFD for CR-LSP is used,
the control plane creates a BFD session for the backup CR-LSP. If static BFD for CR-LSP is
used, a BFD session can be configured for the backup CR-LSP.

Figure 5-30 BFD for CR-LSP before and after a link fault occurs
LSRD
Before a link fault occurs
LSRA LSRB LSRC
LSRD
After a link fault occurs
Primary CR-LSP
Backup CR-LSP
LSRA LSRB LSRC Bfd Session
Link fault
BFD for TE Tunnel

BFD detects faults in the entire TE tunnel and triggers traffic switchovers for VPN
applications such as VPN FRR.
BFD for CR-LSP notifies a TE tunnel of faults and triggers service switchovers between CR-
LSPs in the TE tunnel. Unlike BFD for CR-LSP, BFD for TE tunnel notifies VPN
applications of faults and triggers service switchovers between TE tunnel interfaces.
Differences
Table 5-21 lists differences among BFD for RSVP, BFD for CR-LSP, and BFD for TE tunnel.
Table 5-21 Comparison of BFD for TE technologies

Detection Detection Deployment Usage BFD Session
Technology Object Position Scenario Mode
BFD for RSVP RSVP Two Associating Dynamic

neighboring neighboring with TE FRR
relationship nodes of an
RSVP session

Detection Detection Deployment Usage BFD Session

Technology Object Position Scenario Mode
BFD for CR- CR-LSP Ingress and Associating l Dynamic

LSP egress nodes with a hot- l Static
standby CR-
LSP or tunnel
protection
group
BFD for TE MPLS TE Ingress and Associating Static

Tunnel tunnel egress nodes with VPN FRR
or VLL FRR
5.2.9.9 RSVP GR
RSVP Graceful Restart (GR) ensures uninterrupted traffic transmission on the forwarding
plane when traffic is switched to the control plane upon a node failure.
Background
GR is typically applied to provider edge (PE) routers, especially when users connect to the
backbone network through a single PE router. If an MPLS TE tunnel deployed on such a PE
router for traffic engineering or as a VPN tunnel on the public network, traffic on the tunnel is
interrupted when the PE router fails or undergoes an active/standby switchover for
maintenance (software upgrade, for example). As shown in Figure 5-31, RSVP GR can be
deployed on PE3 to ensure uninterrupted service forwarding when PE3 fails.
Figure 5-31 RSVP GR application
VPNA VPNA
CE1 CE2
PE1 PE2
Backbone
PE3 PE4
CE3 CE4
VPNB VPNB
Concepts
RSVP GR is a fast state recovery mechanism for RSVP-TE. As one of the high-reliability
technologies, RSVP GR is designed based on non-stop forwarding (NSF).

The GR process involves GR restarter and GR helper routers. The GR restarter restarts the
protocol and the GR helper assists in the process.
RSVP GR provides the following types of messages:

l Hello message with GR extensions: is used to detect the neighbor's GR status.
l GR Path message: is sent downstream and carries information about the last Path update.
l Recovery Path message: is sent upstream and carries information about the last received
Path message.
Implementation
RSVP GR detects the GR status of a neighbor using RSVP Hello extensions.
RSVP GR is implemented as follows:
In Figure 5-32, after the GR restarter triggers a GR, it stops sending Hello messages to its
neighbors. If a GR helper does not receive Hello messages for three consecutive intervals, it
considers that the neighbor is performing a GR and retains all forwarding information.
Meanwhile, the GR restarter continue to transmit services and to wait for the GR restarter to
complete the process.
After the GR restarter starts, it receives Hello messages from neighbors and sends Hello
messages in response. Upstream and downstream nodes process Hello messages in different
ways:
l When the upstream GR helper receives a Hello message, it sends a GR Path message
downstream to the GR restarter.
l When the downstream GR helper receives a Hello message, it sends a Recovery Path
message upstream to the GR restarter.
Figure 5-32 RSVP GR implementation
Upstream Downstream
Hello Hello
GR Path Recovery
GR-Helper GR-Restarter Path GR-Helper
When receiving the GR Path message and the Recovery Path message, the GR restarter
reestablishes the path state block (PSB) and reservation state block (RSB) of the CR-LSP
based on the two messages. Information about the CR-LSP on the local control plane is
restored.
If the downstream GR helper cannot send Recovery Path messages, the GR restarter
reestablishes the local PSB and RSB using only GR Path messages.
Usage Scenario
RSVP GR can be deployed to improve device-level reliability for nodes when an MPLS TE
tunnel is set up using RSVP TE.

Benefits
When an active/standby switchover occurs on the control plane, RSVP GR ensures
uninterrupted data transmission, improving device-level reliability.
5.3 MPLS TE Application on an IP MAN

Service Overview
Carriers are converging their service bearer networks. IP/MPLS technology is essential on
these converged networks because the technology allows voice, video, leased line, and data
services to be transmitted on an IP/MPLS backbone network. Depending upon individual
subscribers' requirements, services on a metropolitan area network (MAN) are classified into:
l For individual subscribers: high-speed Internet (HSI), video on demand (VoD), and voice
over IP (VoIP)
l For business and enterprise subscribers: L3VPN services (business VPN) and L2VPN
services (data, video, and voice services)
Table 5-22 lists the requirements of these services.
Table 5-22 Services on an IP MAN

Service QoS Reliability Security Requirements
Requirement Requirements
s
HSI l Bandwidth l End-to-end services: l Services are isolated.

guarantee: Redundant links are l The IP infrastructure
not required deployed to ensure that can effectively defend
l QoS traffic is switched to the against attacks and
guarantee: backup link upon a viruses, ensuring stable
low primary link failure. network operation.
l Voice service: Traffic is
VoD l Bandwidth rapidly switched to the
guarantee: backup link upon a
required primary link failure to
l QoS ensure real-time
guarantee: transmission.
medium
VoIP l Bandwidth
guarantee:
required
l QoS
guarantee:
high

Service QoS Reliability Security Requirements

Requirement Requirements
s
Business l Bandwidth
VPN guarantee:
required
l QoS
guarantee:
medium
Networking Description
Currently, an IP MAN consists of a MAN backbone and a MAN access network, which
deliver services to users. Figure 5-33 and Figure 5-34 show end-to-end service models for
individual and enterprise subscribers.
Figure 5-33 Service model of an individual subscriber
PE-AGG BRAS
HSI
DSLAM
IP/MPLS
MAN
BackBone
VOIP
UPE
PE-AGG SR SoftX
VOD
HSI MPLS TE+VLL/VPLS
VoD/VoIP MPLS TE+VLL/VPLS

Figure 5-34 Service model of an enterprise subscriber
BRAS
UPE
Enterprise IP/MPLS
MAN
service BackBone
SR
MPLS TE
L3VPN or L2VPN MPLS TE Hot-standby
BFD for CR-LSP
Feature Deployment
Enterprise or individual services are core services that have bandwidth, QoS, and reliability
requirements. MPLS TE tunnels are recommended as VPN tunnels on the public network to
meet service requirements. For detailed deployment, see Table 5-23.
Table 5-23 MPLS TE deployment on an IP MAN
Item L3VPN L2VPN
Services Business VPN l HSI

l VoD
l VoIP
VPN tunnel MPLS TE tunnel MPLS TE tunnel

on the public
network
Reliability l Network reliability l Network reliability

– Link protection: provided – Link protection: provided
using TE hot standby and using TE hot standby and
BFD for CR-LSP. BFD for CR-LSP.
– Node protection: provided – Node protection: provided
using VPN FRR and BFD using VLL FRR and BFD for
for TE tunnel. TE tunnel.
l Device reliability: RSVP GR. l Device reliability: RSVP GR.
QoS End-to-end QoS must be configured between a user-end provider edge

(UPE) and a broadband remote access server (BRAS) or service router
(SR) to ensure service quality.
Security RSVP MD5 or keychain is used for authentication.

Key deployment points are as follows: Explicit paths are configured to separately establish
primary and backup CR-LSPs. The two paths do not overlap in important areas.
5.4 Summary of MPLS TE Configuration Tasks

MPLS TE is implemented after an MPLS TE tunnel is created and traffic is imported to the
TE tunnel. To adjust MPLS TE parameters and deploy some security solutions, perform one
or more of the following operations: adjusting RSVP-TE signaling parameters, adjusting the
path of the CR-LSP, adjusting the establishment of MPLS TE tunnels and CR-LSP backup,
configuring MPLS TE FRR, configuring MPLS TE tunnel protection group, configuring BFD
for MPLS TE, and configuring RSVP GR.

Table 5-24 MPLS TE configuration tasks

Configuration Configuration Description
Task
Create an MPLS To transmit L2VPN or L3VPN 5.7 Configuring a Static MPLS

TE tunnel services on the MPLS backbone TE Tunnel
network, and enable a tunnel to 5.8 Configuring a Dynamic
adapt to network topology MPLS TE Tunnel
changes to ensure stable data
transmission, create an MPLS TE
tunnel. MPLS TE tunnels can be
created using the following
methods:
l Static MPLS TE Tunnels:
Static MPLS TE tunnels are
established using labels that
are allocated manually but not
by a signaling protocol to send
control packets. Using static
MPLS TE tunnels is
recommended for a stable
network with low-performance
devices.
Static MPLS TE tunnels have
the highest priorities, which
means that their bandwidth
cannot be preempted. Static
MPLS TE tunnels will not
preempt bandwidth of other
types of LSPs.
l Dynamic MPLS TE Tunnels:
Dynamic MPLS TE tunnels
are established using the
RSVP-TE signaling protocol
that can adjust the path of an
MPLS TE tunnel according to
network changes. There is no
need to manually configure
each hop on a large scale
network.


Task
Configure the An MPLS TE tunnel does not 5.9 Importing Traffic to an

MPLS TE tunnel automatically direct traffic. To MPLS TE Tunnel
to forward data enable traffic to travel along an
traffic MPLS TE tunnel, use one of the
following methods to import the
traffic to the MPLS TE tunnel:
l Use static routes
This is the simplest method for
importing the traffic to an
MPLS TE tunnel.
l Use tunnel policies
In general, VPN traffic is
forwarded through an LSP
tunnel but not an MPLS TE
tunnel. To import VPN traffic
to the MPLS TE tunnel, you
need to configure a tunnel
policy.
l Use the auto route mechanism
A TE tunnel is used as a
logical link for IGP route
calculation. A tunnel interface
is used as an outbound
interface of a route.


Task
Adjust MPLS TE You can adjust MPLS TE 5.10 Adjusting RSVP-TE

parameters parameters as required. The Signaling Parameters
parameters are listed as follows: 5.11 Adjusting the Path of a
l RSVP Signaling Parameters CR-LSP
RSVP signaling parameters 5.12 Adjusting the
include the RSVP reservation Establishment of an MPLS TE
style, reservation Tunnel
confirmation, RSVP timer,
summary refresh, Hello
extension mechanism, and
RSVP authentication. You can
adjust these parameters to
meet customer requirements.
l CR-LSP Selection
CSPF uses the TEDB and
constraints to calculate
appropriate paths and
establishes CR-LSPs through
the signaling protocol. MPLS
TE provides multiple methods
to control CSPF calculation,
adjusting CR-LSP selection.
The methods include:
– Configuring the tie-
breaking of CSPF
– Configuring the metric for
path calculation
– Configuring the CR-LSP
hop limit
– Configuring route pinning
– Configuring administrative
group and affinity property
– Configuring Shared Risk
Link Group (SRLG)
– Configuring the failed link
timer
l Establishment of MPLS TE
Tunnels
During the establishment of an
MPLS TE tunnel, you may
need to perform specified
configurations in practical
applications. MPLS TE
provides multiple methods to
adjust establishment of MPLS


Task
TE tunnels. The methods

include:
– Performing loop detection
– Configuring route record
and label record
– Configuring re-
optimization for CR-LSP
– Configuring the tunnel
reestablishment function
– Configuring the RSVP
signaling delay-trigger
function
– Configuring the tunnel
priority


Task
Configure MPLS MPLS TE provides multiple 5.13 Configuring CR-LSP

TE reliability reliability technologies to ensure Backup
high reliability of key services 5.16 Configuring Association
transmitted over MPLS TE Between TE FRR and CR-LSP
tunnels. The device supports the Backup
following reliability features for
MPLS TE tunnels: 5.14 Configuring Manual TE
FRR
l CR-LSP backup
If a primary CR-LSP fails,
traffic rapidly switches to a 5.17 Configuring a Tunnel
backup CR-LSP, ensuring Protection Group
uninterrupted traffic 5.18 Configuring Dynamic BFD
transmission. for RSVP
l TE FRR 5.19 Configuring Static BFD for
TE FRR is performed in CR-LSPs
manual or automatic mode: 5.20 Configuring Dynamic BFD
– TE Manual FRR for CR-LSPs
It applies to scenarios with 5.21 Configuring Static BFD for
simple network topology. TE Tunnels
– TE Auto FRR 5.22 Configuring RSVP GR
It applies to scenarios with
complicated network
topology.
l Tunnel protection group
The tunnel protection group
provides end-to end protection
for MPLS TE tunnels. If a
working tunnel in a protection
group fails, traffic is switched
to a protection tunnel.
l BFD for RSVP
BFD for RSVP applies to a TE
FRR network, on which Layer
2 devices exist between the
PLR and its RSVP
neighboring nodes over the
primary CR-LSP.
l BFD for CR-LSP
BFD for CR-LSP is used
together with a hot-standby
CR-LSP or a tunnel protection
group.
l BFD for TE tunnel
BFD can monitor MPLS TE
tunnels that are used as public


Task
network tunnels to transmit

VPN traffic.
l RSVP GR
RSVP graceful restart (GR) is
a state recovery mechanism
for dynamic CR-LSPs.
5.5 Licensing Requirements and Limitations for MPLS TE

Involved Network Elements
Other network elements are not required.
License Requirements
MPLS TE is a basic feature of a switch and is not under license control.
Version Requirements
Table 5-25 Products and versions supporting MPLS TE
Produ Product Software Version

ct Model
S2700 S2700SI Not supported
S2700EI Not supported
S2710SI Not supported
S3700 S3700SI, Not supported

S3700EI
S3700HI Not supported
S5700 S5700LI Not supported
S5700S-LI Not supported
S5710-C-LI Not supported
S5710-X-LI Not supported

Produ Product Software Version

ct Model
S5710EI V200R002C00, V200R003C00, V200R005(C00&C02)
S5720EI V200R009C00, V200R010C00, V200R011C00,

V200R011C10, V200R012C00
S5720LI, Not supported

S5720S-LI
S5720SI, Not supported

S5720S-SI
S5720I-SI Not supported
S5700HI V200R002C00, V200R003C00,

V200R005(C00SPC500&C01&C02)
S5710HI V200R003C00, V200R005(C00&C02&C03)
S5720HI V200R007C10, V200R009C00, V200R010C00,

V200R011C00, V200R011C10, V200R012C00
S5730HI V200R012C00
S5730S-EI Not supported
S6700 S6720LI, Not supported

S6720S-LI
S6720SI, Not supported

S6720S-SI
S6700EI V200R005(C00&C01&C02)
S6720EI V200R008C00, V200R009C00, V200R010C00,

V200R011C00, V200R011C10, V200R012C00
S6720S-EI V200R009C00, V200R010C00, V200R011C00,

V200R011C10, V200R012C00
S6720HI V200R012C00
NOTE
For details about software mappings, visit Hardware Query Tool and search for the desired product
model.
For feature support of S1700 series switches, see S1700 Series Enterprise Switches - Specifications.
Feature Limitations
When configuring MPLS TE on the switch, pay attention to the following points:

l In V200R003 and earlier versions, only VLANIF interfaces support MPLS TE. In
V200R005 and later versions, both VLANIF interfaces and Layer 3 Ethernet interfaces
support MPLS TE.
l On the S5720EI switch, if hardware support for MPLS is displayed as NO in the output
of the display device capability command, the switch does not support MPLS. In this
case, you need to pay attention to the following points:
– MPLS cannot be enabled on the S5720EI switch. If the switch has been added to a
stack, MPLS cannot be enabled on the stack.
– The S5720EI switch cannot be added to a stack running MPLS.
When configuring TE FRR on the switch, pay attention to the following points:
l Dynamic TE tunnels using bandwidth reserved in Shared Explicit (SE) style support TE
FRR, but static TE tunnels do not.
l For the S5720EI, S6720EI, and S6720S-EI, if TE FRR is enabled in a scenario where
MPLS TE tunnels transmit VPN services, you must configure PHP when the MP node is
the egress node of the primary CR-LSP.
l In V200R005 and earlier versions, TE FRR can be performed during the RSVP GR
process. This protects traffic on the primary tunnel and speeds up troubleshooting in the
situation where a traffic switchover or a reboot is triggered after a fault occurs on a PLR,
the PLR's upstream node, an MP, or the MP's downstream node, while the outbound
interface of a primary tunnel on the PLR fails. During the RSVP GR process, FRR
switching is triggered if the outbound interface of a primary tunnel on the PLR goes
Down.
When configuring tunnel protection groups on the switch, pay attention to the following
points:
l A tunnel protection group works in either 1:1 or N:1 mode. The 1:1 mode enables a
protection tunnel to protect only one working tunnel. The N:1 mode enables a protection
tunnel to protect multiple working tunnels. In a tunnel protection group, a maximum of
16 primary tunnels can be protected.
l Tunnel-specific attributes in a tunnel protection group are independent from each other.
For example, a protection tunnel with the bandwidth 50 Mbit/s can protect a working
tunnel with the bandwidth 100 Mbit/s.
l Besides configuring a tunnel protection group to protect the working tunnel, you can
configure TE FRR on the working tunnel in the protection group for dual protection to
the working tunnel.
NOTE
A tunnel protection group and TE FRR cannot be configured simultaneously on the ingress node
of a primary tunnel.
l A protection tunnel cannot be protected by other tunnels or be enabled with TE FRR.
When configuring BFD for MPLS TE on the switch, pay attention to the following
points:
l BFD can detect faults in static and dynamic CR-LSPs.
l BFD for LSP can function properly even if the forward and backward forwarding modes
are different. (For example, the forward path is an LSP and the backward path is an IP
link.) The forward path and the backward path must be established over the same link;
otherwise, if a fault occurs, BFD cannot identify the faulty path. Before deploying BFD,
ensure that the forward and backward paths are over the same link so that BFD can
correctly identify the faulty path.

5.6 Default Settings for MPLS TE

Table 5-26 Default settings for MPLS TE
Parameter Default Setting
MPLS TE Disabled
RSVP TE Disabled
Metric type in path selection for tunnels TE
Affinity property of tunnels The values of affinity property and mask are
both 0x0.
Maximum reservable link bandwidth 0
Tunnel priority The values of setup priority and hold

priority are both 7.
Route and label storing Disabled
Route pinning Disabled
Waiting period from a TE tunnel going 0

Down to the network informed of the
change
5.7 Configuring a Static MPLS TE Tunnel

Configuring a static MPLS TE tunnel can implement setup of static CR-LSPs. The
configuration is simple. Labels are allocated manually and control packets do not need to be
exchanged, so static LSPs consume less resources.
Pre-configuration Tasks
Before configuring a static MPLS TE tunnel, complete the following tasks:
l Configure an LSR ID on each LSR.
l Enable basic MPLS functions on each LSR globally and on each interface.
NOTE
After a static CR-LSP is bound to a tunnel interface, the static CR-LSP takes effect without an IP route
configured.
Configuration Procedure
Except that configuring link bandwidth is optional, all the other configurations are mandatory.

5.7.1 Enabling MPLS TE
Context
Perform the following configurations on each node of the MPLS TE tunnel.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run mpls
The MPLS view is displayed.
Step 3 Run mpls te
MPLS TE is enabled on the node globally.
Step 4 Run quit
Return to the system view.
Step 5 Run interface interface-type interface-number
The view of the interface is displayed.
Step 6 (Optional) On an Ethernet interface, run undo portswitch
The interface is switched to Layer 3 mode.
By default, an Ethernet interface works in Layer 2 mode.

NOTE
Only the S5720EI, S5720HI, S5730HI, S6720EI, S6720HI, and S6720S-EI support switching between
Layer 2 and Layer 3 modes.
Step 7 Run mpls
The MPLS is enabled on the interface.
Step 8 Run mpls te
The MPLS TE is enabled on the interface.
----End
5.7.2 Configuring an MPLS TE Tunnel Interface
Context
Before setting up an MPLS TE Tunnel, you must create a tunnel interface and configure other
tunnel attributes on the tunnel interface. An MPLS TE tunnel interface is responsible for
establishing an MPLS TE tunnel and managing packet forwarding on the tunnel.

NOTE
Because the type of the packet forwarded by the MPLS TE tunnel is MPLS, the commands, such as the
ip verify source-address and urpf commands, related to IP packet forwarding configured on this
interface are invalid.
Perform the following configurations on the ingress node of an MPLS TE tunnel.
Procedure
Step 2 Run interface tunnel interface-number
A tunnel interface is created and the tunnel interface view is displayed.
Step 3 To configure the IP address of the tunnel interface, select one of the following commands.
l Run ip address ip-address { mask | mask-length } [ sub ]
The IP address of the tunnel interface is configured.
The secondary IP address of the tunnel interface can be configured only after the primary
IP address is configured.
l Or run ip address unnumbered interface interface-type interface-number
The tunnel interface is configured to borrow an IP address from other interfaces.
An MPLS TE tunnel can be established even if the tunnel interface is assigned no IP address.
The tunnel interface must obtain an IP address before forwarding traffic. An MPLS TE tunnel
is unidirectional and does not need to configure a separate IP address for the tunnel interface.
Generally, a loopback interface is created on the ingress node and a 32-bit address that is the
same as the LSR ID is assigned to the loopback interface. Then the tunnel interface borrows
the IP address of the loopback interface.
Step 4 Run tunnel-protocol mpls te
MPLS TE is configured as a tunnel protocol.
Step 5 Run destination dest-ip-address
The destination address of the tunnel is configured, which is usually the LSR ID of the egress
node.
Different types of tunnels need different destination addresses. When the tunnel protocol is
changed to MPLS TE from other protocols, the configured destination address is deleted
automatically and you need to configure an address again.
Step 6 Run mpls te tunnel-id tunnel-id
The tunnel ID is configured.
Step 7 Run mpls te signal-protocol cr-static
The signal protocol of the tunnel is configured to be static CR-LSP.
Step 8 (Optional) Run mpls te signalled tunnel-name tunnel-name
The tunnel name is specified.
By default, the tunnel interface name such as Tunnel1 is used as the name of the TE tunnel.

Step 9 Run mpls te commit
The current tunnel configuration is committed.
NOTE
If MPLS TE parameters on a tunnel interface are modified, run the mpls te commit command to
activate them.
----End
5.7.3 (Optional) Configuring Link Bandwidth
Context
When a non-Huawei device as the ingress node of an MPLS TE tunnel initiates a request for
setting up a CR-LSP with bandwidth constraints, configure link bandwidth on the connected
Huawei device for negotiation so that the CR-LSP can be set up and network resources are
used efficiently.
NOTE
The configured bandwidth takes effect only during tunnel establishment and protocol negotiation, and
does not limit the bandwidth for traffic forwarding. (S5720HI does not have this restriction.)
Procedure
The MPLS-TE-enabled interface view is displayed.

NOTE
Step 4 Run mpls te bandwidth max-reservable-bandwidth bw-value
The maximum available bandwidth of the link is configured.
By default, the maximum reservable bandwidth of a link is 0 bit/s. The bandwidth allocated to
a static CR-LSP built over a link is certainly higher than 0 bit/s. If the maximum reservable
bandwidth of the link is not configured, the static CR-LSP cannot be set up due to insufficient
bandwidth.
Step 5 Run mpls te bandwidth { bc0 bc0-bw-value | bc1 bc1-bw-value } *
The BC bandwidth of the link is configured.

NOTE
l The maximum reservable bandwidth of a link cannot be greater than the actual bandwidth of the
link. A maximum of 80% of the actual bandwidth of the link is recommended for the maximum
reservable bandwidth of the link.
l Neither the BC0 bandwidth nor the BC1 bandwidth can be greater than the maximum reservable
bandwidth of the link.
----End
5.7.4 Configuring the Static CR-LSP
Context
When configuring a static MPLS TE tunnel, configure static CR-LSPs on the ingress, transit,
and egress nodes. When there is no intermediate node, there is no need to configure a static
CR-LSP on the intermediate node.
NOTE
After static CR-LSPs are configured, you can execute commands again to modify CR-LSP parameters.
Procedure
l Configure the ingress node.
Perform the following operations on the ingress node of a static MPLS TE tunnel.
a. Run system-view

b. Run static-cr-lsp ingress { tunnel-interface tunnel interface-number | tunnel-
name } destination destination-address { nexthop next-hop-address | outgoing-
interface interface-type interface-number } * out-label out-label [ bandwidth [ ct0
| ct1 ] bandwidth ]
The static CR-LSP is configured on the ingress node.
tunnel interface-number specifies the MPLS TE tunnel interface that uses this static
CR-LSP. By default, the Bandwidth Constraints value is ct0, and the value of
bandwidth is 0. The bandwidth used by the tunnel cannot be higher than the
maximum reservable bandwidth of the link.
tunnel-name must be the same as the tunnel name created by using the interface
tunnel interface-number command. tunnel-name is a case-sensitive character string
in which spaces are not supported.
The next hop or outbound interface is determined by the route from the ingress to
the egress. For the difference between the next hop and outbound interface, refer to
Creating IPv4 Static Routes in "Static Route Configuration" in the S1720, S2700,
S5700, and S6720 V200R012(C00&C20) Configuration Guide - IP Unicast
Routing.
If an Ethernet interface is used as an outbound interface of an LSP, the nexthop

next-hop-address parameter must be configured.

NOTE
The configured bandwidth takes effect only during tunnel establishment and protocol
negotiation, and does not limit the bandwidth for traffic forwarding. (S5720HI does not have
this restriction.)
l Configure a transit node.
Perform the following operations on the transit node of a static MPLS TE tunnel.
a. Run system-view
b. Run static-cr-lsp transit lsp-name [ incoming-interface interface-type interface-
number ] in-label in-label { nexthop next-hop-address | outgoing-interface
interface-type interface-number } * out-label out-label [ bandwidth [ ct0 | ct1 ]
bandwidth ] [ description description ]
The static CR-LSP is configured on the transit node.
lsp-name cannot be specified as the same as the name of an existing tunnel on the
node. The name of the MPLS TE tunnel interface associated with the static CR-LSP
can be used, such as Tunnel1.
If an Ethernet interface is used as an outbound interface of an LSP, the nexthop
next-hop-address parameter must be configured.
NOTE
this restriction.)
l Configure the egress node.
Perform the following operations on the egress node of a static MPLS TE tunnel.
a. Run system-view
b. Run static-cr-lsp egress lsp-name [ incoming-interface interface-type interface-
number ] in-label in-label
The static CR-LSP is configured on the egress node.
lsp-name cannot be specified as the same as the name of an existing tunnel on the
node. The name of the MPLS TE tunnel interface associated with the static CR-LSP
can be used, such as Tunnel1.
----End
5.7.5 Verifying the Configuration of a Static MPLS TE Tunnel

Prerequisites
The configurations of the static MPLS TE tunnel are complete.
Procedure
l Run the display mpls static-cr-lsp [ lsp-name ] [ { include | exclude } ip-address mask-
length ] [ verbose ] command to check information about the static CR-LSP.

l Run the display mpls te tunnel [ destination ip-address ] [ lsp-id ingress-lsr-id session-
id local-lsp-id ] [ lsr-role { all | egress | ingress | remote | transit } ] [ name tunnel-
name ] [ { incoming-interface | interface | outgoing-interface } interface-type
interface-number ] [ verbose ] command to check tunnel information.
l Run the display mpls te tunnel statistics or display mpls lsp statistics command to
check the tunnel statistics.
l Run the display mpls te tunnel-interface [ tunnel interface-number ] command to
check information about the tunnel interface on the ingress node.
----End
5.8 Configuring a Dynamic MPLS TE Tunnel

Dynamic MPLS TE tunnels are set up using RSVP-TE signaling and are changed according
to network changes. On a large-scale network, dynamic MPLS TE tunnels reduce the burden
of per-hop configuration. Configuring a dynamic MPLS TE tunnel is the basis for configuring
advanced features of MPLS TE.
Before configuring a dynamic MPLS TE tunnel, complete the following tasks:
l Configure an IGP to ensure reachable routes between nodes.
l Configure an LSR ID for each node.
l Enable MPLS globally on each node.
l Enable MPLS on each interface of each node.
Except that configuring link bandwidth, referencing the CR-LSP attribute template to set up a
CR-LSP, and configuring tunnel constraints are optional, all the other configurations are
mandatory.
5.8.1 Enabling MPLS TE and RSVP-TE

Context
To create a dynamic MPLS TE tunnel, first enable MPLS TE, enable RSVP-TE globally,
enable RSVP-TE on an interface, and perform other configurations, such as setting the link
bandwidth attributes and enabling CSPF.
Procedure
Step 2 Run mpls

Step 3 Run mpls te

MPLS TE is enabled on the node globally.
Step 4 Run mpls rsvp-te
RSVP-TE is enabled on the node.
Step 5 Run quit
The MPLS TE interface view is displayed.
NOTE
Step 8 Run mpls

The MPLS is enabled on the interface.
Step 9 Run mpls te
The MPLS TE is enabled on the interface.
Step 10 Run mpls rsvp-te
RSVP-TE is enabled on the interface.
----End
5.8.2 Configuring an MPLS TE Tunnel Interface
Context
A tunnel interface must be created on the ingress so that a tunnel can be established and
forward data packets.
A tunnel interface supports the following functions:
l Establishes a tunnel. Tunnel constraints, bandwidth attributes, and advanced attributes
such as TE FRR and tunnel re-optimization can be configured on the tunnel interface to
establish the tunnel.
l Manages a tunnel. Tunnel attributes can be modified on the tunnel interface to manage
the tunnel.
NOTE
Because MPLS TE tunnels forward MPLS packets, not IP packets, IP forwarding-related commands run
on the tunnel interface are invalid.

Procedure
A tunnel interface is created and the tunnel interface view is displayed.
If the shutdown command is run on the tunnel interface, all tunnels established on the tunnel
interface will be deleted.
Step 3 Run either of the following commands to assign an IP address to the tunnel interface:
l To configure an IP address for the tunnel interface, run ip address ip-address { mask |
mask-length } [ sub ]
The primary IP address must be configured before the secondary IP address is
configured.
l To configure the tunnel interface to borrow an IP address of another interface, run ip
address unnumbered interface interface-type interface-number
An MPLS TE tunnel can be established even if the tunnel interface is assigned no IP address.
The tunnel interface must obtain an IP address before forwarding traffic. An MPLS TE tunnel
is unidirectional and does not need to configure a separate IP address for the tunnel interface.
Generally, a loopback interface is created on the ingress node and a 32-bit address that is the
same as the LSR ID is assigned to the loopback interface. Then the tunnel interface borrows
the IP address of the loopback interface.
Step 5 Run destination dest-ip-address
A tunnel destination address is configured, which is usually the LSR ID of the egress.
Various types of tunnels require specific destination addresses. If a tunnel protocol is changed
from another protocol to MPLS TE, a configured destination address is deleted automatically
and a new destination address needs to be configured.
A tunnel ID is set.
Step 7 Run mpls te signal-protocol rsvp-te
RSVP-TE is configured as the signaling protocol.
Step 8 (Optional) Run mpls te signalled tunnel-name tunnel-name
The tunnel name is specified.
By default, the tunnel interface name such as Tunnel1 is used as the name of the TE tunnel.
Perform this step to fulfill the following purposes:

l Facilitate TE tunnel management.

l Allow a Huawei device to be connected to a non-Huawei device that uses a tunnel name
that differs from the tunnel interface name.
Step 9 (Optional) Run mpls te cspf disable
Do not perform the constraint shortest path first (CSPF) calculation when an MPLS TE tunnel
is being set up.
The configuration is committed.
NOTE
The mpls te commit command must be run to make configurations take effect each time MPLS TE
parameters are changed on a tunnel interface.
----End
5.8.3 (Optional) Configuring Link Bandwidth
Context
When a non-Huawei device as the ingress node of an MPLS TE tunnel initiates a request for
setting up a CR-LSP with bandwidth constraints, configure link bandwidth on the connected
Huawei device for negotiation so that the CR-LSP can be set up and network resources are
used efficiently.
NOTE
The configured bandwidth takes effect only during tunnel establishment and protocol negotiation, and
does not limit the bandwidth for traffic forwarding. (S5720HI does not have this restriction.)
Procedure
The MPLS-TE-enabled interface view is displayed.

NOTE
Step 4 Run mpls te bandwidth max-reservable-bandwidth bw-value
The maximum available bandwidth of the link is configured.

By default, the maximum reservable bandwidth of a link is 0 bit/s. The bandwidth allocated to
a static CR-LSP built over a link is certainly higher than 0 bit/s. If the maximum reservable
bandwidth of the link is not configured, the static CR-LSP cannot be set up due to insufficient
bandwidth.
Step 5 Run mpls te bandwidth { bc0 bc0-bw-value | bc1 bc1-bw-value } *

The BC bandwidth of the link is configured.
NOTE
l The maximum reservable bandwidth of a link cannot be greater than the actual bandwidth of the
link. A maximum of 80% of the actual bandwidth of the link is recommended for the maximum
reservable bandwidth of the link.
l Neither the BC0 bandwidth nor the BC1 bandwidth can be greater than the maximum reservable
bandwidth of the link.
----End
5.8.4 Advertising TE Link Information

Context
Nodes on an MPLS network use OSPF TE to exchange TE link attributes such as bandwidth
and colors to generate TEDBs. TEDB information is used by CSPF to calculate paths for
MPLS TE tunnels. Current, the device can use two methods to advertise TE information to
generate TEDBs.
l OSPF TE
OSPF TE is an OSPF extension used on an MPLS TE network. LSRs on the MPLS area
exchange Opaque Type 10 LSAs that carry TE link information to generate TEDBs for
CSPF calculation.
OSPF areas do not support TE by default. The OSPF Opaque capability must be enabled
to support OSPF TE, and a node can generate Opaque Type 10 LSAs only if at least one
OSPF neighbor is in the Full state.
NOTE
If OSPF TE is disabled, no Opaque Type 10 LSA is generated or exchanged by nodes to generate

TEDBs. On an OSPF TE-incapable network, CR-LSPs are established using OSPF routes but not
CSPF calculation results.
l IS-IS TE
IS-IS TE is an IS-IS extension used on an MPLS TE network. IS-IS TE defines a new
TLV in Link State Packets (LSPs) and IS-IS TE-enabled nodes send these LSPs to flood
and synchronize TE link information. IS-IS TE extracts TE link information from LSPs
and then transmits the TE link information to the CSPF module for calculating tunnel
paths.
Use the mode in which TE information is advertised according to the IGP used on the
backbone network. Perform the following operations on each node of an MPLS TE tunnel.
Procedure
l Configure OSPF TE.
a. Run system-view

b. Run ospf [ process-id ]
The OSPF view is displayed.

c. Run opaque-capability enable
The OSPF Opaque capability is enabled.

d. (Optional) Run advertise mpls-lsr-id
The node is enabled to advertise an MPLS LSR ID to multiple OSPF areas.
NOTE
This step is performed only on an area border router (ABR) connected to multiple OSPF
areas.
e. Run area area-id
The OSPF area view is displayed.

f. Run mpls-te enable [ standard-complying ]
MPLS TE is enabled in the OSPF area.

l Configure IS-IS TE.
a. Run system-view

b. Run isis [ process-id ]
The IS-IS view is displayed.

c. Run cost-style { compatible [ relax-spf-limit ] | wide | wide-compatible }
The IS-IS wide metric function is enabled.
IS-IS TE uses sub-TLVs of the IS reachability TLV (type 22) to carry TE link
information. The IS-IS wide metric must be configured to support the IS
reachability TLV. The IS-IS wide metric supports the wide, compatible, and wide-
compatible metric types. By default, IS-IS sends and receives LSPs with narrow
metric values.
d. Run traffic-eng [ level-1 | level-2 | level-1-2 ]
IS-IS TE is enabled.
By default, TE is not enabled for IS-IS processes.
If no IS-IS level is specified, the node is a Level-1-2 device that can generate two
TEDBs for communicating with Level-1 and Level-2 devices.
----End
5.8.5 (Optional) Referencing the CR-LSP Attribute Template to

Set Up a CR-LSP
Context
You can create a CR-LSP by using the following methods:
l Creating a CR-LSP without using a CR-LSP attribute template

l Creating a CR-LSP by using a CR-LSP attribute template

It is recommended to use a CR-LSP attribute template to set up a CR-LSP because this
method has the following advantages:
– A CR-LSP attribute template can greatly simplify the configurations of CR-LSPs.
– A maximum of three CR-LSP attribute templates can be created for a hot-standby
CR-LSP or an ordinary backup CR-LSP. You can set up a hot-standby CR-LSP or
an ordinary backup CR-LSP with different path options. (Among the three attribute
templates, the template with the smallest sequence number is preferred. If the setup
fails, the template with a greater sequence number is used.)
– If configurations of a CR-LSP attribute template are modified, configurations of the
CR-LSPs established by using the CR-LSP attribute template are automatically
updated, which makes the configurations of CR-LSPs more flexible.
NOTE
The preceding two methods can be used together. If the TE attribute configured in the tunnel interface
view and the TE attribute configured through a CR-LSP attribute template coexist, the former takes
precedence over the latter.

1. Configuring a CR-LSP Attribute Template
Steps 3 to 10 are optional. You can perform one or more of them as required.
2. Setting Up a CR-LSP by Using a CR-LSP Attribute Template
You can use a CR-LSP attribute template to set up the primary CR-LSP, hot-standby CR-
LSP, and ordinary backup CR-LSP.
Procedure
l Configure a CR-LSP attribute template.
a. Run system-view

b. Run lsp-attribute lsp-attribute-name
A CR-LSP attribute template is created and the LSP attribute view is displayed.
A CR-LSP attribute template can be deleted only when it is not used by any tunnel
interface.
c. (Optional) Run bandwidth { ct0 ct0-bandwidth | ct1 ct1-bandwidth }
The bandwidth is set for the CR-LSP attribute template.
Perform this step to provide bandwidth protection for services transmitted on a TE

tunnel established using this template.
d. (Optional) Run explicit-path path-name
An explicit path is configured for the CR-LSP attribute template.
Perform this step to control the path over which a TE tunnel is established.

e. (Optional) Run affinity property affinity-value [ mask mask-value ]
The affinity attribute is set for the CR-LSP attribute template.
By default, both the affinity value and the affinity mask are 0x0.
This step helps you control the path over which a TE tunnel is established.
f. (Optional) Run priority setup_priority_value [ hold_priority_value ]
The setup priority and hold priority are set for the CR-LSP attribute template.
By default, both the setup priority and the hold priority are 7.
If resources are insufficient, setting the setup and holding priority values helps a
device release resources used by LSPs with lower priorities and use the released
resources to establish LSPs with higher priorities.
g. (Optional) Run hop-limit hop-limit
The hop limit is set for the CR-LSP attribute template.
By default, the hop limit is 32.

h. (Optional) Run fast-reroute [ bandwidth ]
FRR is enabled for the CR-LSP attribute template.
By default, FRR is disabled.
FRR is recommended for networks requiring high reliability.
NOTE
Before enabling or disabling FRR for the CR-LSP attribute template, note the following:
l After FRR is enabled, the system automatically records routes for the CR-LSP.
l After FRR is disabled, attributes of the bypass tunnel are automatically deleted.
l The undo mpls te record-route command can take effect only when FRR is disabled.
i. (Optional) Run record-route [ label ]
The system is configured to record routes for the CR-LSP attribute template.
By default, the system does not record routes for the CR-LSP attribute template.
Perform this step to view label information and the number of hops on a path over
which a TE tunnel is established.
j. (Optional) Run bypass-attributes { bandwidth bandwidth | priority
setup_priority_value [ hold_priority_value ] }*
The bypass tunnel attributes are configured for the CR-LSP attribute template.
By default, the bypass tunnel attributes are not configured.

k. Run commit
Configurations of the CR-LSP attribute template are committed.
When the CR-LSP attribute template is used to set up a CR-LSP:

n The CR-LSP is removed and a new CR-LSP is created if the Break-Before-
Make attribute (the priority attribute) of the CR-LSP attribute template is
modified.

n The CR-LSP is removed after an eligible CR-LSP is created and traffic

switches to the new CR-LSP if the Make-Before-Break attribute of the CR-
LSP attribute template is modified.
l Set up a CR-LSP by using a CR-LSP attribute template.
a. Run system-view
b. Run interface tunnel interface-number
The tunnel interface view is displayed.
c. Run mpls te primary-lsp-constraint { dynamic | lsp-attribute lsp-attribute-
name }
The primary CR-LSP is set up through the specified CR-LSP attribute template.
If dynamic is used, it indicates that when a CR-LSP attribute template is used to set
up a primary CR-LSP, all attributes in the template use the default values.
d. (Optional) Run mpls te hotstandby-lsp-constraint number { dynamic | lsp-
attribute lsp-attribute-name }
The hot-standby CR-LSP is set up by using the specified CR-LSP attribute
template.
A maximum of three CR-LSP attribute templates can be used to set up a hot-
standby CR-LSP. The hot-standby CR-LSP must be consistent with the primary
CR-LSP in the attributes of the setup priority, hold priority, and bandwidth type. To
set up a hot-standby CR-LSP, you should keep on attempting to use CR-LSP
attribute templates one by one in ascending order of the number of the attribute
templates until the hot-standby CR-LSP is set up.
If dynamic is used, it indicates that the hot-standby CR-LSP is assigned the same
bandwidth and priority as the primary CR-LSP, but specified with a different path
from the primary CR-LSP.
e. (Optional) Run mpls te backup hotstandby-lsp-constraint wtr interval
The Wait to Restore (WTR) time is set for the traffic to switch back from the hot-
standby CR-LSP to the primary CR-LSP.
By default, the WTR time for the traffic to switch back from the hot-standby CR-
LSP to the primary CR-LSP is 10 seconds.
NOTE
The hot-standby CR-LSP specified in the mpls te backup hotstandby-lsp-constraint wtr

command must be an existing one established by running the mpls te hotstandby-lsp-
constraint command.
f. (Optional) Run mpls te ordinary-lsp-constraint number { dynamic | lsp-attribute
lsp-attribute-name }
The ordinary backup CR-LSP is set up by using the specified CR-LSP attribute
template.
A maximum of three CR-LSP attribute templates can be used to set up an ordinary
backup CR-LSP. The ordinary backup CR-LSP must be consistent with the primary
CR-LSP in the attributes of the setup priority, hold priority, and bandwidth type. To
set up an ordinary backup CR-LSP, you should keep on attempting to use CR-LSP

attribute templates one by one in ascending order of the number of the attribute
template until the ordinary backup CR-LSP is set up.
If dynamic is used, it indicates that the ordinary backup CR-LSP is assigned the
same bandwidth and priority as the primary CR-LSP.
g. (Optional) Run mpls te backup ordinary-lsp-constraint lock
The attribute template of the ordinary backup CR-LSP is locked.
By default, the attribute template of the ordinary backup CR-LSP is not locked.
NOTE
Before running this command, you must run the mpls te ordinary-lsp-constraint command
to reference the CR-LSP attribute template to set up an ordinary backup CR-LSP.
h. Run mpls te commit
The configurations of the CR-LSP are committed.
----End
5.8.6 (Optional) Configuring Tunnel Constraints
Context
Constraints such as bandwidth and explicit path attributes can be configured on the ingress to
accurately and flexibly establish an RSVP-TE tunnel.

1. Configuring an MPLS TE Explicit Path
You need to configure an explicit path before you can configure constraints on the
explicit path.
An explicit path refers to a vector path on which a series of nodes are arranged in
configuration sequence. The IP address of an interface on the egress is usually used as
the destination address of the explicit path. Links or nodes can be specified for an
explicit path so that a CR-LSP can be established over the specified path, facilitating
resource allocation and efficiently controlling CR-LSP establishment.
Two adjacent nodes are connected in either of the following modes on an explicit path:
– Strict : Two consecutive hops must be directly connected. This mode strictly
controls the path through which the LSP passes.
– Loose: Other nodes may exist between a hop and its next hop.
The strict and loose modes are used either separately or together.
2. Configuring Tunnel Constraints
After constraints are configured for tunnel establishment, a CR-LSP is established over a
path calculated by CSPF.
Procedure
l Configure an MPLS TE explicit path.
a. Run system-view

b. Run explicit-path path-name
An explicit path is created and the explicit path view is displayed.

c. Run next hop ip-address [ include [ [ loose | strict ] | [ incoming | outgoing ] ] * |
exclude ]
A next-hop address is specified for the explicit path.
By default, the include strict parameter is configured, meaning that a hop and its
next hop must be directly connected. An explicit path can be configured to pass
through a specified node or not to pass through a specified node.
Either of the following parameters can be configured:

n incoming: sets the ip-address to the IP address of an inbound interface of a
next-hop node.
n outgoing: sets the ip-address to the IP address of an outbound interface of a
next-hop node.
d. You can run the following commands to add, modify, or delete nodes on the explicit
path.
n Run list hop [ ip-address ]
Information about nodes on the explicit path is displayed.
n Run add hop ip-address1 [ include [ [ loose | strict ] | [ incoming |
outgoing ] ] * | exclude ] { after | before } ip-address2
A node is added to the explicit path.
By default, the include strict parameter is configured, meaning that a hop and
its next hop must be directly connected. An explicit path can be configured to
pass through a specified node or not to pass through a specified node.
○ incoming: sets the ip-address1 to the IP address of an inbound interface
of a new-added node.
○ outgoing: sets the ip-address1 to the IP address of an outbound interface
of a new-added node.
n Run modify hop ip-address1 ip-address2 [ include [ [ loose | strict ] |
[ incoming | outgoing ] ] * | exclude ]
The address of a node is changed to allow another specified node to be used by
the explicit path.
By default, the include strict parameter is configured, meaning that a hop and
its next hop must be directly connected. An explicit path can be configured to
pass through a specified node or not to pass through a specified node.
○ incoming: sets the ip-address2 to the IP address of an inbound interface
of the modified node.
○ outgoing: sets the ip-address2 to the IP address of an outbound interface
of the modified node.
n Run delete hop ip-address
A node is deleted from the explicit path.
l Configure tunnel constraints.

a. Run system-view

b. Run interface tunnel tunnel-number

c. Run mpls te bandwidth { ct0 ct0-bw-value | ct1 ct1-bw-value }
The bandwidth is configured for the tunnel.
The bandwidth used by the tunnel cannot be greater than the maximum reservable
link bandwidth.
Ignore this step if only an explicit path is required.
NOTE
this restriction.)
d. Run mpls te path explicit-path path-name
An explicit path is configured for the tunnel.
Ignore this step if only the bandwidth needs to be specified.

e. Run mpls te commit
----End
5.8.7 Configuring Path Calculation
Context
To calculate a tunnel path meeting specified constraints, CSPF should be configured on the
ingress.
CSPF extends the shortest path first (SPF) algorithm and is able to calculate the shortest path
meeting MPLS TE requirements. CSPF calculates paths using the following information:
l Link state information sent by IGP-TE and saved in TEDBs
l Network resource attributes, such as the maximum available bandwidth, maximum
reservable bandwidth, and affinity property, sent by IGP-TE and saved in TEDBs
l Configured constraints such as explicit paths
NOTE
l An RSVP-TE tunnel can be established on a CSPF-disabled ingress. However, to allow a path to

meet tunnel constraints, you are advised to enable CSPF on the ingress before establishing the
RSVP-TE tunnel.
l Enabling CSPF on all transit nodes is recommended. The tunnel function fails if CSPF or IGP TE is
not enabled on the ingress, IGP TE is not enabled on some transit nodes or the egress, and CSPF is
enabled on some transit nodes.

Procedure
Step 2 Run mpls
Step 3 Run mpls te cspf
CSPF is enabled on a node.
CSPF is disabled by default.
Step 4 (Optional) Run mpls te cspf preferred-igp { isis [ isis-process-id [ level-1 | level-2 ] ] | ospf
[ ospf-process-id [ area { area-id-1 | area-id-2 } ] ] }
A preferred IGP is specified.
By default, OSPF is preferred for CSPF path calculation.
If a single IGP protocol is only configured on the backbone network to advertise OSPF or IS-
IS TE information, ignore this step.
----End
5.8.8 Verifying the Configuration of a Dynamic MPLS TE Tunnel

Prerequisites
The configurations of a dynamic MPLS TE tunnel are complete.
Procedure
l Run the display mpls te link-administration bandwidth-allocation [ interface
interface-type interface-number ] command to check information about the allocated link
bandwidth.
l Run the display ospf [ process-id ] mpls-te [ area area-id ] [ self-originated ] command
to check information about OSPF TE.
l Run one of the following commands to check IS-IS TE information:
– display isis traffic-eng advertisements
– display isis traffic-eng link
– display isis traffic-eng network
– display isis traffic-eng statistics
– display isis traffic-eng sub-tlvs
l Run the display explicit-path [ [ name ] path-name ] [ tunnel-interface | lsp-attribute |
verbose ] command to check configured explicit paths.
l Run the display mpls te cspf destination ip-address [ affinity properties [ mask mask-
value ] | bandwidth { ct0 ct0-bandwidth | ct1 ct1-bandwidth } * | explicit-path path-
name | hop-limit hop-limit-number | metric-type { igp | te } | priority setup-priority |
srlg-strict exclude-path-name | tie-breaking { random | most-fill | least-fill } ] * [ hot-
standby [ explicit-path path-name | overlap-path | affinity properties [ mask mask-

value ] | hop-limit hop-limit-number | srlg { preferred | strict } ] * ] command to check

information about a path that is calculated using CSPF based on specified conditions.
l Run the display mpls te cspf tedb { all | area { area-id | area-id-ip } | interface ip-
address | network-lsa | node [ router-id ] | srlg srlg-number | overload-node }
command to check information about TEDBs that can meet specified conditions and be
used by CSPF to calculate paths.
l Run the display mpls rsvp-te command to check RSVP information.
l Run the display mpls rsvp-te established [ interface interface-type interface-number
peer-ip-address ] command to check information about the established RSVP-TE CR-
LSPs.
l Run the display mpls rsvp-te peer [ interface interface-type interface-number ]
command to check RSVP neighbor parameters.
l Run the display mpls rsvp-te reservation [ interface interface-type interface-number
peer-ip-address ] command to check information about RSVP resource reservation.
l Run the display mpls rsvp-te request [ interface interface-type interface-number peer-
ip-address ] command to check information about the RSVP-TE request messages on
interfaces.
l Run the display mpls rsvp-te sender [ interface interface-type interface-number peer-
ip-address ] command to check information about RSVP senders.
l Run the display mpls rsvp-te statistics { global | interface [ interface-type interface-
number ] } command to check RSVP-TE statistics.
l Run the display mpls te link-administration admission-control [ interface interface-
type interface-number | stale-interface interface-index ] command to check the tunnels
set up on the local node.
interface-number ] [ verbose ] command to check tunnel information.
check tunnel statistics.
l Run the display lsp-attribute [ name lsp-attribute-name ] [ tunnel-interface | verbose ]
command to check the configurations of the CR-LSP attribute template and the tunnels
using it.
l Run the display mpls te tunnel-interface lsp-constraint [ tunnel interface-number ]
command to view information about the CR-LSP attribute template on the TE tunnel
interface.
l Run the display mpls te tunnel-interface [ tunnel interface-number | auto-bypass-
tunnel [ tunnel-name ] ] command to check information about the MPLS TE tunnel.
l Run the display mpls te tunnel c-hop [ tunnel-name ] [ lsp-id ingress-lsr-id session-id
lsp-id ] command to check path computation results of tunnels.
l Run the display mpls te session-entry [ ingress-lsr-id tunnel-id egress-lsr-id ] command
to check detailed information about the LSP session entry.
----End

5.9 Importing Traffic to an MPLS TE Tunnel

An MPLS TE tunnel does not automatically direct traffic. To enable traffic to travel along an
MPLS TE tunnel, you need to use some method to direct traffic to the MPLS TE tunnel.
Before importing traffic to the MPLS TE tunnel, complete one of the following tasks:
l Configure a static MPLS TE tunnel. For details, see 5.7 Configuring a Static MPLS TE
Tunnel.
l Configure a dynamic MPLS TE tunnel. For details, see 5.8 Configuring a Dynamic
MPLS TE Tunnel.
To direct traffic to the MPLS TE tunnel, perform one of the following operations according to
the network planning. You are advised to use the auto route mechanism.
5.9.1 Configuring Static Routes
Context
Using static routes is the simplest method for importing traffic to an MPLS TE tunnel.
Procedure
Static routes in an MPLS TE tunnel are similar to common static routes. You only need to
configure a static route with a TE tunnel interface as the outbound interface. For detailed
instructions, see Configuring IPv4 Static Routes in "Static Route Configuration" in the S1720,
S2700, S5700, and S6720 V200R012(C00&C20) Configuration Guide - IP Unicast Routing.
5.9.2 Configuring a Tunnel Policy
Context
In general, VPN traffic is forwarded through an LSP tunnel but not an MPLS TE tunnel. To
import VPN traffic to the MPLS TE tunnel, you need to configure a tunnel policy.
Procedure
You can configure either of the following types of tunnel policies according to service
requirements:
l Tunnel type prioritizing policy: Such a policy specifies the sequence in which different
types of tunnels are selected by the VPN. For example, you can specify the VPN to
select the TE tunnel first.
l Tunnel binding policy: This policy binds a TE tunnel to a specified VPN by binding a
specified destination address to the TE tunnel to provide QoS guarantee.

For detailed instructions, see Configuring and Applying a Tunnel Policy in "BGP/MPLS IP
VPN Configuration" in the S1720, S2700, S5700, and S6720 V200R012(C00&C20)
Configuration Guide - VPN.
5.9.3 Configuring Auto Routes

Context
After you configure auto routes, TE tunnels act as logical links to participate in IGP route
calculation and tunnel interfaces are used as the outbound interfaces of packets. Devices on
network nodes determine whether to advertise LSP information to neighboring nodes to
instruct packet forwarding. Two modes are available for auto routes:
l Configuring IGP shortcut: A device uses a TE tunnel for local route calculation and
does not advertise the TE tunnel to its peers as a route. Therefore, the peers of this device
cannot use the TE tunnel for route calculation.
l Configuring forwarding adjacency: A device uses a TE tunnel for local route
calculation and advertises the TE tunnel to its peers as a route. Therefore, the peers of
this device can use the TE tunnel for route calculation.
NOTE
l IGP shortcut and forwarding adjacency are exclusive to each other.

l When using forwarding adjacency to advertise LSP information to other nodes for bidirectional
detection on links, you must configure another tunnel for transmitting packets in the opposite
direction, and then enable forwarding adjacency on the two tunnels.
Procedure
l Configuring IGP Shortcut
a. Run system-view
The interface view of the MPLS TE tunnel is displayed.
c. Run mpls te igp shortcut [ isis | ospf ]
The IGP shortcut is configured.
By default, the IGP shortcut is not configured. If the IGP type is not specified when
the IGP shortcut is configured, both IS-IS and OSPF are supported by default.
d. Run mpls te igp metric { absolute absolute-value | relative relative-value }
The IGP metric value for the tunnel is configured.
By default, the metric value used by the TE tunnel is the same as that of the IGP.
You can specify a metric value used by the TE tunnel when path is calculated in the
IGP shortcut feature.
n If the absolute metric is used, the TE tunnel is equal to the configured metric
value.
n If the relative metric is used, the TE tunnel is equal to the sum of the metric
value of the corresponding IGP path and relative metric value.

The current TE tunnel configuration is committed.

f. You can select either of the following modes to configure IGP shortcut.
n For IS-IS, run isis enable [ process-id ]
IS-IS is enabled on the tunnel interface.
n For OSPF, run the following commands in sequence:
1) Run the quit command to return to the system view.
2) Run the ospf [ process-id ] command to enter the OSPF view.
3) Run the enable traffic-adjustment command to enable IGP shortcut
function.
l Configuring Forwarding Adjacency
a. Run system-view


c. Run mpls te igp advertise [ hold-time interval ]
The forwarding adjacency is enabled.

d. Run mpls te igp metric { absolute absolute-value | relative relative-value }
The IGP metric value for the tunnel is configured.
NOTE
The IGP metric value must be set properly to ensure that LSP information is advertised and
used correctly. For example, the metric of a TE tunnel must be less than that of IGP routes to
ensure that the TE tunnel is used as a route link.
If relative is configured and IS-IS is used as an IGP, this step cannot modify the IS-IS metric
value. To change the IS-IS metric value, configure absolute in this step.

f. You can select either of the following modes to enable the forwarding adjacency.
n For IS-IS, run isis enable [ process-id ]
IS-IS is enabled on the tunnel interface.
n For OSPF, run the following commands in sequence:
1) Run quit
2) Run ospf [ process-id ]
The OSPF view is displayed.
3) Run enable traffic-adjustment advertise
Forwarding adjacency is enabled.
----End

5.9.4 Verifying the Configuration of Importing Traffic to an

MPLS TE Tunnel
Prerequisites
The configuration for importing traffic to an MPLS TE tunnel is complete.
Procedure
l Run the display current-configuration command to view the configuration for
importing traffic to an MPLS TE tunnel.
l Run the display ip routing-table command to view the routes with an MPLS TE tunnel
interface as the outbound interface.
l Run the display ospf [ process-id ] traffic-adjustment command to check tunnel
information about OSPF processes related to traffic adjustment (IGP shortcut and
forwarding adjacency).
----End
5.10 Adjusting RSVP-TE Signaling Parameters

RSVP-TE provides various signaling parameters, which meet the requirements for reliability
and network resources.
Before adjusting RSVP-TE signaling parameters, complete the following task:
MPLS TE Tunnel.
The following configurations are optional and can be performed in any sequence.
5.10.1 Configuring an RSVP Resource Reservation Style

Context
If multiple CR-LSPs pass through the same node, the ingress nodes can be configured with an
RSVP resource reservation style to allow the CR-LSPs to share reserved resources or use
separate reserved resources on the overlapping node.
A reservation style is used by an RSVP node to reserve resources after receiving resource
reservation requests from upstream nodes. The device supports the following reservation
styles:
l Fixed filter (FF): creates an exclusive reservation for each sender. A sender does not
share its resource reservation with other senders, and each CR-LSP on a link has a
separate resource reservation.
l SE: creates a single reservation for a series of selected upstream senders. CR-LSPs on a
link share the same resource reservation.

The SE style is used for tunnels established using the Make-Before-Break mechanism,
whereas the FF style is seldom used.
Procedure
Step 2 Run interface tunnel tunnel-number
Step 3 Run mpls te resv-style { ff | se }
A resource reservation style is configured.
The default resource reservation style is SE.
----End
5.10.2 Enabling Reservation Confirmation Mechanism
Context
Receiving an ResvConf message does not mean that the resource reservation succeeds. It
means that resources are reserved successfully only on the farthest upstream node where this
Resv message arrives. These resources, however, may be preempted by other applications
later. You can enable reservation confirmation mechanism to prevent this problem.
Perform the following configurations on the egress node of an MPLS TE tunnel.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te resvconfirm
The reservation confirmation mechanism is enabled.
The reservation confirmation is initiated by the receiver of Path message. An object that
requires confirming the reservation is carried along the Resv message sent by the receiver.
----End

5.10.3 Configuring RSVP Timers
Context
If an RSVP node does not receive any Refresh message within a specified period, it deletes
the path or reservation state. You can set the interval for sending Path/Resv messages and
retry count by setting RSVP timers to change the timeout interval. The default interval and
retry count are recommended. The timeout interval is calculated using the following formula:
Timeout interval = (keep-multiplier-number + 0.5) x 1.5 x refresh-interval.
In the formula, keep-multiplier-number specifies the retry count allowed for RSVP Refresh
messages; refresh-interval specifies the interval for sending RSVP Refresh messages.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te timer refresh refresh-interval
The interval for sending RSVP Refresh messages is set.
By default, the interval for sending RSVP Refresh messages is 30 seconds.
If the interval is modified, the modification takes effect after the timer expires.
You are not advised to set a long interval or modify the interval frequently.
Step 4 Run mpls rsvp-te keep-multiplier keep-multiplier-number
The retry count allowed for RSVP Refresh messages is configured.
By default, the retry count allowed for RSVP Refresh messages is 3.
----End
5.10.4 Configuring RSVP-TE Refresh Mechanism
Context
Enabling Srefresh in the mpls view on two nodes that are the neighbors of each other can
reduce the cost and improve the performance of a network. In the MPLS view, Srefresh can
be enabled on the entire device. After Srefresh is enabled, the retransmission of Srefresh
messages is automatically enabled on the interface or the device.
NOTE
The Srefresh mechanism in MPLS view is applied to the TE FRR networking. Srefresh is enabled globally on
the Point of Local Repair (PLR) and Merge Point (MP) over an FRR bypass tunnel. This allows efficient use
of network resources and improves Srefresh reliability.

Assume that a node initializes the retransmission interval as Rf seconds. If receiving no ACK
message within Rf seconds, the node retransmits the RSVP message after (1 + Delta) x Rf
seconds. The value of Delta depends on the link rate. The node retransmits the message until
it receives an ACK message or the times of retransmission reach the threshold (that is,
retransmission increment value).
Procedure
l Perform the following steps in the MPLS view.
a. Run system-view

b. Run mpls

c. Run mpls rsvp-te srefresh
Srefresh is enabled.
By default, Srefresh is disabled globally.

l Perform the following steps in the interface view.
a. Run system-view

b. Run interface interface-type interface-number
The interface view is displayed.

c. (Optional) On an Ethernet interface, run undo portswitch

NOTE
Only the S5720EI, S5720HI, S5730HI, S6720EI, S6720HI, and S6720S-EI support
switching between Layer 2 and Layer 3 modes.
d. Run mpls rsvp-te srefresh
Srefresh is enabled.
By default, Srefresh is disabled on all interfaces.

e. (Optional) Run mpls rsvp-te timer retransmission { increment-value increment |
retransmit-value interval } *
The retransmission parameters are set.
By default, increment is set to 1, and interval is set to 5000 milliseconds.
----End

5.10.5 Configuring RSVP Hello Extension
Context
The RSVP Hello extension mechanism is used to fast detect reachability of RSVP neighbors.
When the mechanism detects that a neighboring RSVP node is unreachable, the MPLS TE
tunnel is torn down.
NOTE
For details about the RSVP Hello extension mechanism, see RFC 3209.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te hello
RSVP Hello extension function is enabled on this node.
By default, the RSVP hello extension is disabled.
Step 4 Run mpls rsvp-te hello-lost times
The permitted maximum number of dropped Hello messages is set.
When the RSVP Hello extension is enabled, by default, Hello ACK messages cannot be
received for consecutive three times, exceeding which the link is regarded as faulty, and the
TE tunnel is torn down.
Step 5 Run mpls rsvp-te timer hello interval
The interval for sending Hello messages is set.
When the RSVP Hello extension is enabled, by default, the interval of Hello message is 3
seconds.
If the interval is modified, the modification takes effect after the timer expires.
Step 6 Run quit
The interface view of the RSVP-TE-enabled interface is displayed.

NOTE
The RSVP Hello extension function is enabled on the interface.
----End
5.10.6 Configuring the RSVP Message Format
Context
You can adjust object information in RSVP messages by configuring the RSVP message
format. In scenarios where an RSVP-TE tunnel is deployed, when devices from other vendors
on the RSVP-TE tunnel use different format of RSVP message, you can modify the format of
RSVP messages to be sent by the Huawei device to implement interworking.
You can configure the transit and egress nodes to add the down-reason object in an RSVP
message to be sent, facilitating fault locating.
Procedure
l Configure the formats of objects in an RSVP message.
Perform the following steps on each node of the MPLS TE tunnel:
a. Run system-view

b. Run mpls

c. Run mpls rsvp-te send-message { suggest-label | extend-class-type value-length-
type | session-attribute without-affinity | down-reason }
The formats of objects are specified for RSVP messages to be sent.
The configuration guidelines of this command are as follows:
n If a non-Huawei device requires the suggest-label object in a Path message

sent by a Huawei device, specify suggest-label.
n If a non-Huawei device uses the value-length-type (VLT) encoding format of
the extended-class-type object but a Huawei device uses the type-length-value
(TLV) encoding format of the extended-class-type object, specify extend-
class-type value-length-type.
n If a non-Huawei device does not support the session-attribute object sent by a
Huawei device and the session-attribute object sent by the Huawei device has
an affinity attribute, specify session-attribute without-affinity.
n If you want an ingress to learn RSVP-TE tunnel Down causes of the transit
and egress nodes, run the mpls rsvp-te send-message down-reason
command.
l Configure the format of the Record Route Object (RRO) in a Resv message.

When the format in a Resv message sent by a non-Huawei device connected to the
Huawei device is different from that on the Huawei device, run the following command
to adjust the format of Resv messages on the Huawei device to be the same as that on the
non-Huawei device to implement interworking.
Perform the following configurations on the transit and egress nodes of an MPLS TE
tunnel.
a. Run system-view
b. Run mpls
c. Run the following commands as required.
n On a transit node, run the mpls rsvp-te resv-rro transit { { incoming |
incoming-with-label } | { routerid | routerid-with-label } | { outgoing |
outgoing-with-label } } * command.
n On an egress, run the mpls rsvp-te resv-rro egress { { incoming | incoming-
with-label } | { routerid | routerid-with-label } } * command.
----End
5.10.7 Configuring RSVP Authentication

Context
RSVP key authentication prevents an unauthorized node from setting up RSVP neighbor
relationships with the local node or generating forged packets to attack the local node. By
default, RSVP authentication is not configured. Configuring RSVP authentication is
recommended to ensure system security.
RSVP key authentication prevents the following unauthorized means of setting up RSVP
neighbor relationships, protecting the local node from attacks (such as malicious reservation
of high bandwidth):
l An unauthorized node attempts to set up a neighbor relationship with the local node.
l A remote node generates and sends forged RSVP messages to set up a neighbor
relationship with the local node.
RSVP key authentication alone cannot prevent anti-replay attacks or RSVP message mis-
sequence during network congestion. RSVP message mis-sequence causes authentication
termination between RSVP neighbors. The handshake and message window functions,
together with RSVP key authentication, can prevent the preceding problems.
The RSVP authentication lifetime is configured, preventing unceasing RSVP authentication.
In the situation where no CR-LSP exists between RSVP neighbors, the neighbor relationship
is kept Up until the RSVP authentication lifetime expires.
The RSVP key authentication is configured either in the interface view or the MPLS RSVP-
TE neighbor view:
l Configure RSVP key authentication in the interface view: the RSVP key authentication
is performed between directly connected nodes.
l Configure RSVP key authentication in the MPLS RSVP-TE neighbor view: the RSVP
key authentication is performed between neighboring nodes, which is recommended.

The configuration must be complete on two neighboring nodes within three refreshing
intervals. If the configuration is not complete on either of the two neighboring nodes after
three intervals elapse, the session goes Down.
Procedure
Step 2 Run either of the following commands to enter the interface view or the MPLS RSVP-TE
neighbor view:
l To enter the interface view of an MPLS TE tunnel, run interface interface-type
interface-number
RSVP key authentication configured in the interface view takes effect only on the
current interface and has the lowest preference.
NOTE
On an Ethernet interface, run the undo portswitch command to switch the working mode of the
interface to Layer 3 mode.
l To enter the MPLS RSVP-TE neighbor view, run mpls rsvp-te peer ip-address
– When ip-address is specified as an interface address but not the LSR ID of the
RSVP neighbor, key authentication is based on this neighbor's interface address.
This means that RSVP key authentication takes effect only on the specified
interface of the neighbor, providing high security. In this case, RSVP key
authentication has the highest preference.
– When ip-address is specified as an address equal to the LSR ID of the RSVP
neighbor, key authentication is based on the neighbor's LSR ID. This means that
RSVP key authentication takes effect on all interfaces of the neighbor. In this case,
this RSVP key authentication has the higher preference than that configured in the
interface view, but has the lower preference than that configured based on the
neighbor interface address.
NOTE
If a neighbor node is identified by its LSR-ID, CSPF must be enabled on two neighboring devices
where RSVP authentication is required.
Step 3 Run mpls rsvp-te authentication { { cipher | plain } auth-key | keychain keychain-name }
The authentication key is configured.
HMAC-MD5 or keychain authentication is enabled by configuring one of the following
optional parameters:
l cipher: configures HMAC-MD5 authentication with keys displayed in ciphertext.
l plain: configures HMAC-MD5 authentication with keys displayed in plaintext.
l keychain: configures keychain authentication by using a globally configured keychain.
At present, only HMAC-MD5 authentication is supported.

Note that HMAC-MD5 encryption algorithm cannot ensure security. Keychain

authentication is recommended.
Step 4 (Optional) Run mpls rsvp-te authentication lifetime lifetime

The RSVP authentication lifetime is set.
lifetime is in the format of HH:MM:SS. The value ranges from 00:00:01 to 23:59:59. By
default, the time is 00:30:00, that is, 30 minutes.
RSVP neighbors to remain the neighbor relationship when no CR-LSP exists between them
until the RSVP authentication lifetime expires. Configuring the RSVP authentication time
does not affect the existing CR-LSPs.
Step 5 (Optional) Run mpls rsvp-te authentication handshake
The handshake function is configured.
The handshake function helps a device to establish an RSVP neighbor relationship with its
neighbor. If a device receives RSVP messages from a neighbor, with which the device has not
established an RSVP authentication relationship, the device will send Challenge messages
carrying local identifier to this neighbor. After receiving the Challenge messages, the
neighbor returns Response messages carrying the identifier the same as that in the Challenge
messages. After receiving the Response messages, the local end checks the identifier carried
in the Response messages. If the identifier in the Response messages is the same as the local
identifier, the device determines to establish an RSVP authentication relationship with its
neighbor.
NOTE
If you run the mpls rsvp-te authentication lifetime lifetime command after configuring the handshake
function, note that the RSVP authentication lifetime must be greater than the interval for sending RSVP
refresh messages configured by mpls rsvp-te timer refresh command.
If the RSVP authentication lifetime is smaller than the interval for sending RSVP refresh messages, the
RSVP authentication relationship will be deleted because no RSVP refresh message is received within
the RSVP authentication lifetime. In such a case, after the next RSVP refresh message is received, the
handshake operation is triggered. Repeated handshake operations will cause RSVP tunnels unable to be
set up or cause RSVP tunnels to be deleted.
Step 6 (Optional) Run mpls rsvp-te authentication window-size window-size

The message window function is configured.
window-size is the number of valid sequence numbers carried in RSVP messages that a
device can save.
The default window size is 1, which means that a device saves only the largest sequence
number of the RSVP message from neighbors.
When window-size is larger than 1, it means that a device accepts several valid sequence
numbers.

NOTE
If RSVP is enabled on an Eth-Trunk interface, only one neighbor relationship is established on the trunk
link between RSVP neighbors. Therefore, any member interface of the trunk interface receives RSVP
messages in a random order, resulting in RSVP message mis-sequence. Configuring RSVP message
window size prevents RSVP message mis-sequence.
The window size larger than 32 is recommended. If the window size is set too small, the RSVP packets
are discarded because the sequence number is beyond the range of the window size, causing an RSVP
neighbor relationship to be terminated.
Step 7 Run quit

Step 8 (Optional) Set an interval at which a Challenge message is retransmitted and the maximum
number of times that a Challenge message can be retransmitted.
If Authentication messages exchanged between two RSVP nodes are out of order, a node
sends a Challenge message to the other one to request for connection restoration. If no reply
to the Challenge message is received, the node retransmits the Challenge message at a
specified interval. If no reply is received after the maximum number of retransmission times
is reached, the neighbor relationship is not restored. If a reply is received before the maximum
number of retransmission times is reached, the neighbor relationship is restored, and the
number of retransmission times is cleared for the Challenge message.
If the interval at which a Challenge message is retransmitted or the maximum number of
times that a Challenge message can be retransmitted does not meet your RSVP authentication
success ratio requirement, perform the following configurations:
1. Run mpls
2. Run mpls rsvp-te retrans-timer challenge retransmission-interval
The interval at which a Challenge message is retransmitted is specified.
The default interval is 1000 ms.
3. Run mpls rsvp-te challenge-lost max-miss-times
The maximum number of times that a Challenge message can be retransmitted is
specified.
The default value is 3.
----End
5.10.8 Verifying the Configuration of Adjusting RSVP-TE

Signaling Parameters
Prerequisites
The configurations of adjusting RSVP signaling parameters are complete.
Procedure
l Run the display mpls rsvp-te command to check related information about RSVP-TE.
l Run the display default-parameter mpls rsvp-te command to check default parameters
of RSVP-TE.

l Run the display mpls rsvp-te session ingress-lsr-id tunnel-id egress-lsr-id command to
check information about the specified RSVP session.
l Run the display mpls rsvp-te psb-content [ ingress-lsr-id tunnel-id lsp-id ] command to
check information about RSVP-TE PSB.
l Run the display mpls rsvp-te rsb-content [ ingress-lsr-id tunnel-id lsp-id ] command to
check information about RSVP-TE RSB.
command to view information about the RSVP neighbor on an RSVP-TE-enabled
interface.
----End
5.11 Adjusting the Path of a CR-LSP

CSPF uses the TEDB and constraints to calculate appropriate paths and establishes CR-LSPs
through the signaling protocol. MPLS TE provides many methods to affect CSPF
computation to adjust the CR-LSP path.
Before adjusting the path of a CR-LSP, complete the following task:
MPLS TE Tunnel.
5.11.1 Configuring Tie-Breaking of CSPF
Context
You can configure the CSPF tie-breaking function to select a path from multiple paths with
the same weight value.
Procedure
Step 2 Run mpls
Step 3 Run mpls te tie-breaking { least-fill | most-fill | random }
CR-LSP tie-breaking policy for the LSR is configured.

Tie-breaking policies are classified as follows:
l least-fill: the route with the smallest ratio of the occupied available bandwidth to the
maximum reservable bandwidth is selected.
l most-fill: the route with the largest ratio of the occupied available bandwidth to the
maximum reservable bandwidth is selected.
l random: selects a route randomly.
The default tie-breaking policy is random.
NOTE
The maximum reservable bandwidth is the bandwidth configured by the command mpls te bandwidth
max-reservable-bandwidth bw-value.
Step 4 Run quit
The tunnel interface view of the MPLS TE tunnel is displayed.
Step 6 Run mpls te tie-breaking { least-fill | most-fill | random }
The CR-LSP tie-breaking policy for current tunnel is configured.
The parameters have the same functions as those used in step 3.
NOTE
The tunnel preferentially takes the tie-breaking policy configured in its tunnel interface view. If the tie-
breaking policy is not configured in the tunnel interface view, the configuration in the MPLS view is
used.
----End
5.11.2 Configuring Metrics for Path Calculation
Context
You can configure the metric type that is used for setting up a tunnel.
Procedure
l Specifying the metric type used by the tunnel
a. Run system-view


c. Run mpls te path metric-type { igp | te }
The metric type for path computation is configured.

d. Run mpls te commit
The current configuration of the tunnel is committed.

e. Run quit

f. (Optional) Run mpls

g. (Optional) Run mpls te path metric-type { igp | te }
The path metric type used by the tunnel during route selection is specified.
If the mpls te path metric-type command is not run in the tunnel interface view,
the metric type in the MPLS view is used; otherwise, the metric type in the tunnel
interface view is used.
By default, path metric type used by the tunnel during route selection is TE.
l (Optional) Configuring the TE metric value of the path
If the metric type of a specified tunnel is TE, you can modify the TE metric value of the
path on the outbound interface of the ingress and the transit node by performing the
following configurations.
a. Run system-view

The view of the MPLS-TE-enabled interface is displayed.


NOTE
d. Run mpls te metric value
The TE metric value of the path is configured.
By default, the path uses the IGP metric value as the TE metric value.
NOTE
If the IGP is OSPF and the current device is a stub router, the mpls te metric command does
not take effect.
----End

5.11.3 Configuring CR-LSP Hop Limit

Context
Similar to the administrative group and the affinity property, the hop limit is a condition for
CR-LSP path selection and is used to specify the number of hops along a CR-LSP to be set
up.
Procedure
Step 3 Run mpls te hop-limit hop-limit-value [ best-effort | secondary ]
The number of hops along the CR-LSP is set. The hop-limit-value is an integer ranging from
1 to 32.
----End
5.11.4 Configuring Route Pinning

Context
By configuring the route pinning function, you can use the path that is originally selected,
rather than another eligible path, to set up a CR-LSP.
NOTE
If route pinning is enabled, the MPLS TE re-optimization cannot be used at the same time.
Procedure
Step 3 Run mpls te route-pinning
Route pinning is enabled.
By default, route pinning is disabled.


----End
5.11.5 Configuring Administrative Group and Affinity Property
Context
The configuration of the administrative group affects only LSPs to be set up; the
configuration of the affinity property affects established LSPs by recalculating the paths.
Procedure
The interface view of the MPLS-TE-enabled interface is displayed.
NOTE
Step 4 Run mpls te link administrative group value

The administrative group of the MPLS TE link is configured.
The modification of administrative group takes effect only on LSPs that are established after
modification.
Step 5 Run quit
Step 7 Run mpls te affinity property properties [ mask mask-value ] [ secondary | best-effort ]
The affinity for the tunnel is configured.
By default, the values of administrative group, affinity property, and mask are all 0x0.
After the modified affinity property is committed, the established LSP in this tunnel may be
affected and the system recalculates the path for the TE tunnel.

----End
5.11.6 Configuring SRLG
Context
In the networking scenario where the hot standby CR-LSP is set up or TE FRR is enabled,
configure the SRLG attribute on the outbound interface of the ingress node of the MPLS TE
tunnel or the PLR and the other member links of the SRLG to which the outbound interface
belongs.
Configuring SRLG includes:
l Configuring SRLG for the link

l Configuring SRLG path calculation mode for the tunnel
l Deleting the member interfaces of all SRLGs
Perform the following configurations according to actual networking.
Procedure
l Configuring SRLG for the link
Perform the following configurations on the links which are in the same SRLG.
a. Run system-view
The interface view is displayed.
NOTE
d. Run mpls te srlg srlg-number
The interface is configured as an SRLG member.
On a network with CR-LSP hot standby or TE FRR configured, the SRLG attribute
can be configured for the outbound interface of the ingress node of the MPLS TE
tunnel or the PLR and other members of the SRLG to which the outbound interface
belongs. A link joins an SRLG after the SRLG attribute is configured on an
outbound interface of the link.
l Configuring SRLG path calculation mode for the tunnel
Perform the following configurations on the ingress node of the hot-standby tunnel or the
TE FRR tunnel.

a. Run system-view
b. Run mpls
c. Run mpls te srlg path-calculation [ strict | preferred ]
The SRLG path calculation mode is configured.
If you specify the strict keyword, CSPF avoids the following links when
calculating the bypass CR-LSP or backup CR-LSP:
n Link with the same SRLG attributes as SRLG attributes of the primary CR-
LSP
n All links along the primary CR-LSP regardless of whether the links are
configured with SRLG attributes
CSPF does not exclude the nodes that the primary CR-LSP passes.
NOTE
l If you specify the strict keyword, CSPF always considers the SRLG as a constraint
when calculating the path for the bypass CR-LSP or the backup CR-LSP.
l If you specify the preferred keyword, CSPF tries to calculate the path which avoids the
links in the same SRLG as protected interfaces; if the calculation fails, CSPF does not
consider the SRLG as a constraint.
l Delete the member interfaces of all SRLGs.
Perform the following configurations to delete member interfaces of all SRLGs from a
node of the MPLS TE tunnel.
a. Run system-view
b. Run mpls
c. Run undo mpls te srlg all-config
The member interfaces of all SRLGs are deleted from the MPLS TE node.
NOTE
The undo mpls te srlg all-config does not delete an SRLG-based path calculation mode
configured in the mpls te srlg path-calculation command in the MPLS view.
----End
5.11.7 Associating CR-LSP Establishment with the Overload

Setting
Context
A node becomes overloaded in the following situations:
l When the node is transmitting a large number of services and its system resources are
exhausted, the node marks itself overloaded.

l When the node is transmitting a large number of services and its CPU is overburdened,
an administrator can run the set-overload command to mark the node overloaded.
If there are overloaded nodes on an MPLS TE network, associate CR-LSP establishment with
the IS-IS overload setting to ensure that CR-LSPs are established over paths excluding
overloaded nodes. This configuration prevents overloaded nodes from being further burdened
and improves CR-LSP reliability.
Procedure
Step 2 Run mpls
Step 3 Run mpls te path-selection overload
CR-LSP establishment is associated with the IS-IS overload setting. This association allows
CSPF to calculate paths excluding overloaded IS-IS nodes.
Before the association is configured, the mpls te record-route command must be run to
enable the route and label record.
Traffic travels through an existing CR-LSP before a new CR-LSP is established. After the
new CR-LSP is established, traffic switches to the new CR-LSP and the original CR-LSP is
deleted. This traffic switchover is performed based on the Make-Before-Break mechanism.
Traffic is not dropped during the switchover.
The mpls te path-selection overload command has the following influences on the CR-LSP
establishment:
l CSPF recalculates paths excluding overloaded nodes for established CR-LSPs.
l CSPF calculates paths excluding overloaded nodes for new CR-LSPs.
NOTE
This command does not take effect on bypass tunnels.

If the ingress or egress is marked overloaded, the mpls te path-selection overload command does not
take effect. The established CR-LSPs associated with the ingress or egress will not be reestablished and
new CR-LSPs associated with the ingress or egress will also not be established.
----End
5.11.8 Configuring Failed Link Timer

Context
CSPF uses a locally-maintained traffic-engineering database (TEDB) to calculate the shortest
path to the destination address. Then, the signaling protocol applies for and reserves resources
for the path. In the case of a link on a network is faulty, if the routing protocol fails to notify
CSPF of updating the TEDB in time, this may cause the path calculated by CSPF to contain
the faulty link.
As a result, the control packets, such as RSVP Path messages, of a signaling protocol are
discarded on the faulty link. Then, the signaling protocol returns an error message to the

upstream node. Receiving the link error message on the upstream node triggers CSPF to
recalculate a path. The path recalculated by CSPF and returned to the signaling protocol still
contains the faulty link because the TEDB is not updated. The control packets of the signaling
protocol are still discarded and the signaling protocol returns an error message to trigger
CSPF to recalculate a path. The procedure repeats until the TEDB is updated.
To avoid the preceding situation, when the signaling protocol returns an error message to
notify CSPF of a link failure, CSPF sets the status of the faulty link to INACTIVE and
enables a failed link timer. Then, CSPF does not use the faulty link in path calculation until
CSPF receives a TEDB update event or the failed link timer expires.
Before the failed link timer expires, if a TEDB update event is received, CSPF deletes the
failed link timer.
Procedure
Step 2 Run mpls
Step 3 Run mpls te cspf timer failed-link interval
The failed link timer is configured.
By default, the failed link timer is set to 10 seconds.
The failed link timer is a local configuration. If the failed link timers of nodes are set to
different values, a failed link that is in ACTIVE state on one node may be in INACTIVE state
on other nodes.
----End
5.11.9 Configuring Flooding Threshold

Context
The bandwidth flooding threshold indicates the ratio of the link bandwidth occupied or
released by a TE tunnel to the link bandwidth remained in the TEDB.
If the link bandwidth changes little, bandwidth flooding wastes network resources. For
example, if link bandwidth is 100 Mbit/s and 100 TE tunnels (with bandwidth as 1 Mbit/s) are
created along this link, bandwidth flooding need be performed for 100 times.
If the flooding threshold is set to 10%, bandwidth flooding is not performed when tunnel 1 to
tunnel 9 are created. When tunnel 10 is created, the bandwidth of tunnel 1 to tunnel 10 (10
Mbit/s in total) is flooded. Similarly, bandwidth flooding is not performed when tunnel 11 to
tunnel 18 are created. When tunnel 19 is created, the bandwidth of tunnel 11 to tunnel 19 is
flooded. Therefore, configuring bandwidth flooding threshold can reduce the times of
bandwidth flooding and hence ensure the efficient use of network resources.
By default, on a link, IGP flood information about this link and CSPF updates the TEDB
accordingly if one of the following conditions is met:

l The ratio of the bandwidth reserved for an MPLS TE tunnel to the bandwidth remained
in the TEDB is equal to or higher than 10%.
l The ratio of the bandwidth released by an MPLS TE tunnel to the bandwidth remained in
the TEDB is equal to or higher than 10%.
Perform the following configurations on the ingress or transit node of an MPSL TE tunnel.
Procedure
The view of the MPLS-TE-enabled interface is displayed.

NOTE
Step 4 Run mpls te bandwidth change thresholds { down | up } percent
The threshold of bandwidth flooding is set.
----End
5.11.10 Verifying the Configuration of Adjusting the Path of a

CR-LSP
Prerequisites
The configurations of adjusting the path of a CR-LSP are complete.
Procedure
l Run the display mpls te tunnel verbose command to check information about the
MPLS TE tunnel.
l Run the display mpls te srlg { srlg-number | all } command to check the SRLG
configuration and interfaces in the SRLG.
l Run the display mpls te link-administration srlg-information [ interface interface-
type interface-number ] command to check the SRLG that interfaces belong to.
l Run the display mpls te tunnel c-hop [ tunnel-name ] [ lsp-id ingress-lsr-id session-id
lsp-id ] command to check path computation results of tunnels.
l Run the display default-parameter mpls te cspf command to check default CSPF
settings.
----End

5.12 Adjusting the Establishment of an MPLS TE Tunnel

During establishment of an MPLS TE tunnel, specific configurations are required in practice.
MPLS TE provides multiple methods to adjust establishment of MPLS TE tunnels.
Before adjusting establishment of an MPLS TE tunnel, complete the following task:
MPLS TE Tunnel.
5.12.1 Configuring Loop Detection

Context
In the loop detection mechanism, a maximum number of 32 hops are allowed on an LSP. If
information about the local LSR is recorded in the path information table, or the number of
hops on the path exceeds 32, this indicates that a loop occurs and the LSP fails to be set up.
By configuring the loop detection function, you can prevent loops.
Procedure
Step 3 Run mpls te loop-detection
The loop detection on tunnel creation is enabled.
By default, loop detection is disabled.
----End
5.12.2 Configuring Route Record and Label Record

Context
By configuring route record and label record, you can determine whether to record routes and
labels during the establishment of an RSVP-TE tunnel.

Procedure
Step 3 Run mpls te record-route [ label ]
The route and label are recorded when establishing the tunnel.
By default, routes and labels are not recorded.
----End
5.12.3 Configuring Re-optimization for CR-LSP
Context
By configuring the tunnel re-optimization function, you can periodically recompute routes for
a CR-LSP. If the recomputed routes are better than the routes in use, a new CR-LSP is then
established according to the recomputed routes. In addition, services are switched to the new
CR-LSP, and the previous CR-LSP is deleted.
If an upstream node on an MPLS network is busy but its downstream node is idle or an
upstream node is idle but its downstream node is busy, a CR-LSP may be torn down before
the new CR-LSP is established, causing a temporary traffic interruption. In this case, you can
configure the switching and deletion delays.
NOTE
l If the re-optimization is enabled, the route pinning cannot be used at the same time.
l The CR-LSP re-optimization cannot be configured when the resource reservation style is FF.
Procedure
Step 3 Run mpls te reoptimization [ frequency interval ]
Periodic re-optimization is enabled.

By default, re-optimization is disabled. The default periodic re-optimization interval is 3600

seconds.
Step 5 Run quit
Step 6 (Optional) Set the switching and deletion delays.
1. Run mpls
2. Run mpls te switch-delay switch-time delete-delay delete-time
The switching and deletion delays are set.
By default, the switching delay is 5000 ms and the deletion delay is 7000 ms.
Step 7 Run return
Back to the user view.
Step 8 (Optional) Run mpls te reoptimization [ tunnel interface-number ]
Manual re-optimization is enabled.
After you configure the automatic re-optimization in the tunnel interface view, you can return
to the user view and run the mpls te reoptimization command to immediately re-optimize all
tunnels or the specified tunnel on which the automatic re-optimization is enabled. After you
perform the manual re-optimization, the timer of the automatic re-optimization is reset and
counts again.
----End
5.12.4 Configuring Tunnel Reestablishment Parameters

Context
By configuring the tunnel reestablishment function, you can periodically recompute the route
for a CR-LSP. If the route in recomputation is better than the route in use, a new CR-LSP is
then established according to the recomputed route. In addition, services are switched to the
new CR-LSP, and the previous CR-LSP is deleted.
Procedure
Step 3 Run mpls te timer retry interval
The interval for re-establishing a tunnel is specified.

By default, the interval for re-establishing a tunnel is 30 seconds.

If the establishment of a tunnel fails, the system attempts to reestablish the tunnel within the
set interval and the maximum number of attempts is the set reestablishment times.
----End
5.12.5 Configuring the RSVP Signaling Delay-Trigger Function
Context
In the case that a fault occurs on an MPLS network, a great number of RSVP CR-LSPs need
to be reestablished. This causes consumption of a large number of system resources. By
configuring the delay for triggering the RSVP signaling, you can reduce the consumption of
system resources when establishing an RSVP CR-LSP.
Perform the following configurations on each node on which multiple CR-LSPs need to be
reestablished.
Procedure
Step 2 Run mpls
Step 3 Run mpls te signaling-delay-trigger enable
The RSVP signaling delay-trigger function is enabled.
By default, the RSVP signaling delay-trigger function is not enabled.
----End
5.12.6 Configuring the Tunnel Priority
Context
In the process of establishing a CR-LSP, if no path with the required bandwidth exists, you
can perform bandwidth preemption according to setup priorities and holding priorities.
Procedure

Step 3 Run mpls te priority setup-priority [ hold-priority ]
The priority for the tunnel is configured.
Both the setup priority and the holding priority range from 0 to 7. The smaller the value is, the
higher the priority is.
By default, both the setup priority and the holding priority are 7. If only the setup priority
value is set, the holding priority value is the same as the setup priority value.
NOTE
The setup priority should not be higher than the holding priority. So the value of the setup priority must
not be less than that of the holding priority.
----End
5.12.7 Verifying the Configuration of Adjusting the

Establishment of an MPLS TE Tunnel
Prerequisites
The configurations of adjusting establishment of an MPLS TE tunnel are complete.
Procedure
l Run the display mpls te tunnel-interface [ tunnel interface-number ] command to
check information about the tunnel interface.
----End
5.13 Configuring CR-LSP Backup

CR-LSP backup provides an end-to-end protection mechanism. If a primary CR-LSP fails,
traffic rapidly switches to a backup CR-LSP, ensuring uninterrupted traffic transmission.
Before configuring CR-LSP backup, complete the following tasks:
l Configure a dynamic MPLS TE or DS-TE tunnel. For details, see 5.8 Configuring a
Dynamic MPLS TE Tunnel.
l Enable MPLS, MPLS TE, and RSVP-TE globally and on interfaces of each node along a
backup CR-LSP.
NOTE
If CR-LSP hot standby is configured, perform the operation of 5.19 Configuring Static BFD for CR-LSPs
or 5.20 Configuring Dynamic BFD for CR-LSPs to implement fast switching at the millisecond level.

Configuring forcible switchover, locking a backup CR-LSP attribute template, configuring
dynamic bandwidth for hot-standby CR-LSPs, and configuring a best-effort path are optional.
5.13.1 Creating a Backup CR-LSP
Context
CR-LSP backup can be configured to allow traffic to switch from a primary CR-LSP to a
backup CR-LSP, providing end-to-end protection.
Procedure
Step 3 Run mpls te backup hot-standby
or run mpls te backup ordinary
The mode of establishing a backup CR-LSP is configured.
If hot-standby is specified, a hot-standby CR-LSP is set up. To implement fast switching at

the millisecond level, perform the operation of 5.19 Configuring Static BFD for CR-LSPs
or 5.20 Configuring Dynamic BFD for CR-LSPs.
NOTE
A tunnel interface cannot be used for both a bypass tunnel and a backup tunnel. A protection failure will
occur if the mpls te backup and mpls te bypass-tunnel commands are run on the tunnel interface, or if
the mpls te backup and mpls te protected-interface commands are run on the tunnel interface. For
details on how to create a bypass CR-LSP, see Configuring Manual TE FRR or Configuring Auto TE
FRR.
A tunnel interface cannot be used for both a bypass tunnel and a protection tunnel in a tunnel protection
group. A protection failure will occur if the mpls te backup and mpls te protection tunnel commands
are run on the tunnel interface. For details on how to create a protection tunnel, see Configuring a
Tunnel Protection Group.
After hot standby or ordinary backup is configured, the system selects a path for a backup
CR-LSP. To specify a path for a backup CR-LSP, repeatedly perform one or more of steps 4 to
6. When hot standby is configured, repeatedly perform one or more of steps 7 to 9.
Step 4 (Optional) Run mpls te path explicit-path path-name secondary
An explicit path is specified for the backup CR-LSP.
Use a separate explicit path for the backup CR-LSP to prevent the backup CR-LSP from
completely overlapping its primary CR-LSP. Protection will fail if the backup CR-LSP
completely overlaps its primary CR-LSP.

The mpls te path explicit-path command can be run successfully only after an explicit path
is set up by running the explicit-path path-name command in the system view, and the nodes
on the path are specified.
Step 5 (Optional) Run mpls te affinity property properties [ mask mask-value ] secondary
The affinity property is configured for the backup CR-LSP.
By default, the affinity property used by the backup CR-LSP is 0x0 and the mask is 0x0.
Step 6 (Optional) Run mpls te hop-limit hop-limit-value secondary
The hop limit is set for the backup CR-LSP.
The default hop limit is 32.
Step 7 (Optional) Run mpls te backup hot-standby overlap-path
The path overlapping function is configured. This function allows a hot-standby CR-LSP to
use links of a primary CR-LSP.
By default, the path overlapping function is disabled. If the path overlapping function is
disabled, a hot-standby CR-LSP may fail to be set up.
After the path overlapping function is configured, the path of the hot-standby CR-LSP
partially overlaps the path of the primary CR-LSP when the hot-standby CR-LSP cannot
exclude paths of the primary CR-LSP.
Step 8 (Optional) Run mpls te backup hot-standby wtr interval
The WTR time for a switchback is set.
By default, the WTR time for switching traffic from a hot-standby CR-LSP to a primary CR-
LSP is 10 seconds.
Step 9 (Optional) Run mpls te backup hot-standby mode { revertive [ wtr interval ] | non-
revertive }
A revertive mode is specified.
By default, the revertive mode is used.
----End
5.13.2 (Optional) Configuring Forcible Switchover
Context
If a backup CR-LSP has been established and a primary CR-LSP needs to be adjusted,
configure the forcible switchover function to switch traffic from the primary CR-LSP to the
backup CR-LSP. After adjusting the primary CR-LSP, switch traffic back to the primary CR-
LSP. This process prevents traffic loss during the primary CR-LSP adjustment.

Procedure
l Before adjusting a primary CR-LSP, perform the following configurations.
a. Run system-view
The MPLS TE tunnel interface view is displayed.
c. Run hotstandby-switch force
Traffic is switched to a backup CR-LSP.
To prevent traffic loss, check that a backup CR-LSP has been established before
running the hotstandby-switch force command.
l After adjusting the primary CR-LSP, perform the following configurations.

a. Run system-view
The MPLS TE tunnel interface view is displayed.
c. Run hotstandby-switch clear
Traffic is switched backup to the primary CR-LSP.
----End
5.13.3 (Optional) Locking a Backup CR-LSP Attribute Template
Context
A maximum of three hot-standby or ordinary backup attribute templates can be used for
establishing a hot-standby or an ordinary CR-LSP. TE attribute templates are prioritized. The
system attempts to use each template in ascending order by priority to establish a backup CR-
LSP.
If an existing backup CR-LSP is set up using a lower-priority attribute template, the system
automatically attempts to set up a new backup CR-LSP using a higher-priority attribute
template, which is unneeded sometimes. If a CR-LSP has been established using the locked
CR-LSP attribute template, the CR-LSP will not be unnecessarily reestablished using another
template with a higher priority. Locking a CR-LSP attribute template allows the existing CR-
LSP to keep transmitting traffic without triggering unneeded traffic switchovers, efficiently
using system resources.
Procedure

Step 3 Run mpls te primary-lsp-constraint { dynamic | lsp-attribute lsp-attribute-name }
An attribute template is specified for setting up a primary CR-LSP.
Step 4 Run either of the following commands as needed to establish a backup CR-LSP:
l To establish an ordinary backup CR-LSP, run mpls te ordinary-lsp-constraint number
{ dynamic | lsp-attribute lsp-attribute-name }
l To establish a hot-standby CR-LSP, run mpls te hotstandby-lsp-constraint number
{ dynamic | lsp-attribute lsp-attribute-name }
Step 5 Run either of the following commands as needed to lock a backup CR-LSP attribute template:
l To lock an attribute template for an ordinary backup CR-LSP, run mpls te backup
ordinary-lsp-constraint lock
l To lock an attribute template for a hot-standby CR-LSP, run mpls te backup
hotstandby-lsp-constraint lock
NOTE
A used attribute template can be unlocked after the undo mpls te backup ordinary-lsp-constraint lock or
undo mpls te backup hotstandby-lsp-constraint lock command is run. After unlocking templates, the
system uses each available template in ascending order by priority. If a template has a higher priority than that
of the currently used template, the system establishes a CR-LSP using the higher-priority template.
----End
5.13.4 (Optional) Configuring Dynamic Bandwidth for Hot-

Standby CR-LSPs
Context
Hot-standby CR-LSPs are established using reserved bandwidth resources by default. The
dynamic bandwidth function can be configured to allow the system to create a primary CR-
LSP and a hot-standby CR-LSP with the bandwidth of 0 bit/s simultaneously.
The dynamic bandwidth protection function allows a hot-standby CR-LSP to obtain

bandwidth resources only after the hot-standby CR-LSP takes over traffic from a faulty
primary CR-LSP. If the primary CR-LSP fails, traffic immediately switches to the hot-standby
CR-LSP with 0 bit/s bandwidth. The ingress node uses the make-before-break mechanism to
reestablish a hot-standby CR-LSP. After the new hot-standby CR-LSP has been successfully
established, the ingress node switches traffic to this CR-LSP and tears down the hot-standby
CR-LSP with 0 bit/s bandwidth. If bandwidth resources are insufficient, the ingress node is
unable to reestablish a hot-standby CR-LSP with the desired bandwidth, and therefore
switches traffic to the hot-standby CR-LSP with 0 bit/s bandwidth, ensuring uninterrupted
traffic transmission.

Procedure
l Perform the following configurations to enable the dynamic bandwidth function for hot-
standby CR-LSPs that are established not using attribute templates.
a. Run system-view


c. Run mpls te backup hot-standby dynamic-bandwidth
The dynamic bandwidth function is enabled for hot-standby CR-LSPs.
NOTE
l If a hot-standby CR-LSP has been established before the dynamic bandwidth function is
enabled, the system uses the Make-Before-Break mechanism to establish a new hot-standby
CR-LSP with the bandwidth of 0 bit/s to replace the existing hot-standby CR-LSP.
l The undo mpls te backup hot-standby dynamic-bandwidth command can be used to
disable the dynamic bandwidth function. This allows the hot-standby CR-LSP with the
bandwidth of 0 bit/s to obtain bandwidth.

l Perform the following configurations to enable the dynamic bandwidth function for hot-
standby CR-LSPs that are established using attribute templates.
a. Run system-view


c. Run mpls te backup hotstandby-lsp-constraint dynamic-bandwidth
The dynamic bandwidth function is enabled for hot-standby CR-LSPs set up by

using an attribute template.
NOTE
l If a hot-standby CR-LSP has been established before the dynamic bandwidth function is
enabled, the system uses the Make-Before-Break mechanism to establish a new hot-standby
CR-LSP with the bandwidth of 0 bit/s to replace the existing hot-standby CR-LSP.
l The undo mpls te backup hotstandby-lsp-constraint dynamic-bandwidth command can
be used to disable the dynamic bandwidth function of the hot-standby CR-LSP which is set up
by using an attribute template. This allows the hot-standby CR-LSP with no bandwidth to
obtain bandwidth.
----End

5.13.5 (Optional) Configuring a Best-Effort Path
Context
A best-effort path is configured on the ingress node of a primary CR-LSP to take over traffic
if both the primary and backup CR-LSPs fail.
Procedure
Step 3 Run mpls te backup ordinary best-effort
A best-effort path is configured.
NOTE
A tunnel interface cannot be used for both a best-effort path and a manually configured ordinary backup
tunnel. A protection failure will occur if the mpls te backup ordinary best-effort and mpls te backup
ordinary commands are run on the tunnel interface.
To establish a best-effort path over a specified path, run either or both of step 4 and step 5.
Step 4 (Optional) Run mpls te affinity property properties [ mask mask-value ] best-effort
The affinity property of the best-effort path is configured.
By default, the affinity property used by the best-effort path is 0x0 and the mask is 0x0.
Step 5 (Optional) Run mpls te hop-limit hop-limit-value best-effort
The hop limit of the best-effort path is set.
The default hop limit is 32.
----End
5.13.6 Verifying the CR-LSP Backup Configuration
Prerequisites
The configurations of CR-LSP backup are complete.
Procedure
l Run the display mpls te tunnel-interface [ tunnel tunnel-number ] command to check
information about the tunnel interface.

l Run the display mpls te hot-standby state { all [ verbose ] | interface tunnel interface-
number } command to check information about the hot-standby status.
interface-number ] [ verbose ] command to check CR-LSP information.
----End
5.14 Configuring Manual TE FRR

Manual TE FRR is a local protection mechanism used on MPLS TE networks. TE manual
FRR switches traffic on a primary MPLS TE tunnel to a manually configured bypass tunnel if
a link or node on the primary tunnel fails.
Before configuring manual MPLS TE FRR, complete the following tasks:
MPLS TE Tunnel.
l Enable MPLS, MPLS TE and RSVP-TE in the system view and interface view of each
node along a bypass tunnel.
l Enable CSPF on a PLR.
NOTE
Perform the operation of 5.18 Configuring Dynamic BFD for RSVP to implement fast switching at the
millisecond level.
Except that configuring a TE FRR scanning timer and changing the PSB and RSB timeout
multiplier are optional, other configurations are mandatory.
5.14.1 Enabling TE FRR

Context
TE FRR must be enabled for a primary tunnel before a bypass tunnel is established.
Procedure
The interface view of a primary tunnel is displayed.
Step 3 Run mpls te fast-reroute [ bandwidth ]
TE FRR is enabled.

NOTE
Only the primary tunnel in a tunnel protection group can be configured together with TE FRR on the
ingress node. Neither the protection tunnel nor the tunnel protection group itself can be used together
with TE FRR. If the tunnel protection group and TE FRR are used, neither of them takes effect.
For example, Tunnel1 and Tunnel2 are tunnel interfaces on MPLS TE tunnels and the tunnel named
Tunnel2 has a tunnel ID of 200. The mpls te protection tunnel 200 and mpls te fast-reroute
commands cannot be configured simultaneously on Tunnel1. That is, the tunnel protection group and TE
FRR cannot be used together on Tunnel1. A configuration failure will occur if the mpls te protection
tunnel 200 command is run on Tunnel1 and the mpls te fast-reroute command is run on Tunnel2.

----End
5.14.2 Configuring a Bypass Tunnel

Context
A bypass tunnel provides protection for a link or node on a primary tunnel. An explicit path
and attributes must be specified for a bypass tunnel when TE manual FRR is being
configured.
Bypass tunnels are established on selected links or nodes that are not on the protected primary
tunnel. If a link or node on the protected primary tunnel is used for a bypass tunnel and fails,
the bypass tunnel also fails to protect the primary tunnel.
NOTE
l FRR does not take effect if multiple nodes or links fail simultaneously. After FRR switching is
performed to switch data from the primary tunnel to a bypass tunnel, the bypass tunnel must remain
Up when forwarding data. If the bypass tunnel goes Down, the protected traffic is interrupted and
FRR fails. Even though the bypass tunnel goes Up again, traffic is unable to flow through the bypass
tunnel but travels through the primary tunnel after the primary tunnel recovers or is reestablished.
l By default, the system searches for an optimal manual FRR tunnel for each primary tunnel every 1
second and binds the bypass tunnel to the primary tunnel if there is an optimal bypass tunnel.
Perform the following configurations on the PLR.
Procedure
The tunnel interface view of a bypass tunnel is displayed.
Step 3 Run either of the following commands to configure the IP address for the tunnel interface:
l To configure an IP address for the interface, run ip address ip-address { mask | mask-
length } [ sub ]
l To configure the tunnel interface to borrow an IP address of another interface, run ip
address unnumbered interface interface-type interface-number
A tunnel interface must have an IP address to forward traffic. An MPLS TE tunnel is
unidirectional and does not need to configure a separate IP address for the tunnel interface.

The tunnel interface usually borrows the IP address of the local loopback interface used as an
LSR ID.
Step 5 Run destination ip-address
The LSR ID of an MP is specified as the destination address of the bypass tunnel.
The tunnel ID is set for the bypass tunnel.
Step 7 (Optional) Run mpls te path explicit-path path-name
An explicit path is specified for the bypass tunnel.
Before using this command, ensure that the explicit path has been created using the explicit-
path command. Note that physical links of a bypass tunnel cannot overlap protected physical
links of the primary tunnel.
Step 8 Run mpls te bypass-tunnel
The bypass tunnel function is enabled.
After a bypass tunnel is configured, the system automatically records routes related to the
bypass tunnel.
NOTE
l A tunnel interface cannot be used for both a bypass tunnel and a backup tunnel. A protection failure
will occur if the mpls te bypass-tunnel and mpls te backup commands are both configured on the
tunnel interface.
l A tunnel interface cannot be used for both a bypass tunnel and a primary tunnel. A protection failure
will occur if the mpls te bypass-tunnel and mpls te fast-reroute commands are both configured on
the tunnel interface.
l A tunnel interface cannot be used for both a bypass tunnel and a protection tunnel in a tunnel
protection group. A protection failure will occur if the mpls te bypass-tunnel and mpls te
protection tunnel commands are both configured on the tunnel interface.
Step 9 Run mpls te protected-interface interface-type interface-number
An interface to be protected by a bypass tunnel is specified.
NOTE
l A bypass tunnel protects a maximum of six physical interfaces.

l A tunnel interface cannot be used for both a bypass tunnel and a backup tunnel. A protection failure
will occur if the mpls te protected-interface and mpls te backup commands are both configured
on the tunnel interface.
----End

5.14.3 (Optional) Configuring a TE FRR Scanning Timer

Context
A TE FRR-enabled device periodically refreshes the binding between a bypass CR-LSP and a
primary LSP at a specified interval. The PLR searches for the optimal TE bypass CR-LSP and
binds it to a primary CR-LSP. A TE FRR scanning timer is set to determine the interval at
which the binding between a bypass CR-LSP and a primary CR-LSP is refreshed.
Procedure
Step 2 Run mpls
Step 3 Run mpls te timer fast-reroute [ weight ]
Set the interval at which the binding between a bypass CR-LSP and a primary CR-LSP is
refreshed.
By default, the time weight used to calculate the interval is 300. And the actual interval at
which the binding between a bypass CR-LSP and a primary LSP is refreshed depends on
device performance and the maximum number of LSPs that can be established on the device.
----End
5.14.4 (Optional) Changing the PSB and RSB Timeout Multiplier

Context
To help allow TE FRR to operate during the RSVP GR process, the timeout multiplier of the
Path State Block (PSB) and Reservation State Block (RSB) can be set. The setting prevents
the situation where information in PSBs and RSBs is dropped due to a timeout before the GR
processes are complete for a large number of CR-LSPs.
Procedure
Step 2 Run mpls
The PSB and RSB timeout multiplier is set.
The default timeout multiplier is 3.

NOTE
Setting the timeout multiplier to 5 or greater is recommended for a network where a large number of
CR-LSPs are established and RSVP GR is configured.
----End
5.14.5 Verifying the Manual TE FRR Configuration
Prerequisites
The configurations of manual TE FRR are complete.
Procedure
l Run the display mpls lsp lsp-id ingress-lsr-id session-id lsp-id [ verbose ] command to
check information about a specified primary tunnel.
l Run the display mpls lsp attribute bypass-inuse { inuse | not-exists | exists-not-used }
command to check information about the attribute of a specified bypass LSP.
l Run the display mpls lsp attribute bypass-tunnel tunnel-name command to check
information about the attribute of a bypass tunnel.
tunnel [ tunnel-name ] ] command to check detailed information about the tunnel
interface of a specified primary or bypass tunnel.
l Run the display mpls te tunnel path [ [ [ tunnel-name ] tunnel-name ] [ lsp-id ingress-
lsr-id session-id lsp-id ] | fast-reroute { local-protection-available | local-protection-
inuse } | lsr-role { ingress | transit | egress } ] command to check information about
paths of a specified primary or bypass tunnel.
l Run the display mpls rsvp-te statistics fast-reroute command to check TE FRR
statistics.
l Run the display mpls stale-interface [ interface-index ] [ verbose ] command to check
the information about MPLS interfaces in the Stale state.
----End

Auto TE FRR is a local protection technique and is used to protect a CR-LSP against link
faults and node faults. Auto TE FRR does not need to be configured manually.
Before configuring auto TE FRR, complete the following task:
MPLS TE Tunnel.
l Enable MPLS, MPLS TE and RSVP-TE in the system view and interface view of each
node along a bypass tunnel.
l Enable CSPF on a PLR.

NOTE
Perform the operation of 5.18 Configuring Dynamic BFD for RSVP to implement fast switching at the
millisecond level.
Except that configuring a TE FRR scanning timer, changing the PSB and RSB timeout
multiplier, configuring auto bypass tunnel re-optimization, and configuring interworking with
other vendors are optional, other configurations are mandatory.
5.15.1 Enabling Auto TE FRR

Context
Before configuring auto TE FRR, enable auto TE FRR globally on the PLR. To implement
link protection, enable link protection on an interface.
Procedure
Step 2 Run mpls
Step 3 Run mpls te auto-frr
Auto TE FRR is enabled globally.
After auto TE FRR is enabled globally, link protection is enabled on all interfaces enabled
with MPLS TE.
Step 4 (Optional) Configure MPLS TE Auto FRR in the interface view.
1. Run quit
2. Run interface interface-type interface-number
The interface view of the outbound interface of the primary tunnel is displayed.
3. (Optional) On an Ethernet interface, run undo portswitch
NOTE
Only the S5720EI, S5720HI, S5730HI, S6720EI, S6720HI, and S6720S-EI support switching
between Layer 2 and Layer 3 modes.
4. Run mpls te auto-frr { link | node | default }
Auto TE FRR is enabled on the outbound interface on the ingress node of the primary
tunnel.

To implement link protection, specify link. If link is not specified, the system provides
only node protection.
By default, after auto TE FRR is enabled globally, all the MPLS TE interfaces are
automatically configured with the mpls te auto-frr default command. To disable auto
TE FRR on some interfaces, run the mpls te auto-frr block command on these
interfaces. Then, these interfaces no longer have auto TE FRR capability even if auto TE
FRR is enabled or is to be re-enabled globally.
NOTE
After mpls te auto-frr is used in the MPLS view, the mpls te auto-frr default or mpls te auto-
frr node command used on an interface protects only nodes. When the topology does not meet the
requirement to set up an automatic bypass tunnel for node protection, the penultimate hop (but not
other hops) on the primary tunnel attempts to set up an automatic bypass tunnel for link protection.
----End
5.15.2 Enabling the TE FRR and Configuring the Auto Bypass

Tunnel Attributes
Context
After TE Auto FRR is enabled, the system automatically sets up a bypass tunnel.
Perform the following configurations on the ingress node of the primary MPLS TE tunnel.
Procedure
The tunnel interface view of the primary tunnel is displayed.
Step 3 Run mpls te fast-reroute [ bandwidth ]
The TE FRR is enabled.
To guarantee the tunnel bandwidth, you must specify the parameter bandwidth.
Step 4 (Optional) Run mpls te bypass-attributes [ bandwidth bandwidth ] [ priority setup-priority
[ hold-priority ] ]
The attributes of the bypass tunnel are configured.
NOTE
l The bypass tunnel attributes can be configured only after the mpls te fast-reroute bandwidth
command is run on the primary tunnel.
l The bandwidth of the bypass tunnel cannot be greater than the bandwidth of the primary tunnel.
l When the attributes of the automatic bypass tunnel are not configured, by default, the bandwidth of
the automatic bypass tunnel is the same as the bandwidth of the primary tunnel.
l The setup priority of the bypass tunnel cannot be higher than the holding priority. Both priorities
cannot be higher than the priority of the primary tunnel.
l When the bandwidth of the primary tunnel is changed or the FRR is disabled, the attributes of the
bypass tunnel are cleared automatically.


The current configuration of the tunnel is committed.
----End
5.15.3 (Optional) Configuring a TE FRR Scanning Timer

Context
A TE FRR-enabled device periodically refreshes the binding between a bypass CR-LSP and a
primary LSP at a specified interval. The PLR searches for the optimal TE bypass CR-LSP and
binds it to a primary CR-LSP. A TE FRR scanning timer is set to determine the interval at
which the binding between a bypass CR-LSP and a primary CR-LSP is refreshed.
Procedure
Step 2 Run mpls
Step 3 Run mpls te timer fast-reroute [ weight ]
Set the interval at which the binding between a bypass CR-LSP and a primary CR-LSP is
refreshed.
By default, the time weight used to calculate the interval is 300. And the actual interval at
which the binding between a bypass CR-LSP and a primary LSP is refreshed depends on
device performance and the maximum number of LSPs that can be established on the device.
----End
5.15.4 (Optional) Changing the PSB and RSB Timeout Multiplier

Context
To help allow TE FRR to operate during the RSVP GR process, the timeout multiplier of the
Path State Block (PSB) and Reservation State Block (RSB) can be set. The setting prevents
the situation where information in PSBs and RSBs is dropped due to a timeout before the GR
processes are complete for a large number of CR-LSPs.
Procedure
Step 2 Run mpls

The PSB and RSB timeout multiplier is set.
The default timeout multiplier is 3.
NOTE
Setting the timeout multiplier to 5 or greater is recommended for a network where a large number of
CR-LSPs are established and RSVP GR is configured.
----End
5.15.5 (Optional) Configuring Auto Bypass Tunnel Re-

Optimization
Context
Network changes often cause the changes in optimal paths. Auto Bypass tunnel re-
optimization allows paths to be recalculated at certain intervals for an auto bypass tunnel. If
an optimal path to the same destination is found due to some reasons, such as the changes in
the cost, a new auto bypass tunnel will be set up over this optimal path. In this manner,
network resources are optimized.
Procedure
Step 2 Run mpls
Step 3 Run mpls te auto-frr reoptimization [ frequency interval ]
Auto bypass tunnel re-optimization is enabled.
By default, auto bypass tunnel re-optimization is disabled. If re-optimization is enabled, the

default interval at which auto bypass tunnel re-optimization is performed is 3600 seconds.
Step 4 (Optional) Immediately re-optimize the TE tunnels.

1. Run return
Return to the user view.

2. Run mpls te reoptimization
Manual re-optimization is enabled.
After you configure the automatic re-optimization in the tunnel interface view, you can
return to the user view and run the mpls te reoptimization command to immediately re-
optimize the TE tunnels. After you perform the manual re-optimization, the timer of the
automatic re-optimization is reset and counts again.
----End

5.15.6 (Optional) Configuring Interworking with a Non-Huawei

Device
Context
If a non-Huawei device connected to the Huawei device uses the integer mode to save the
bandwidth of FRR objects, configure the Huawei device to save the bandwidth of FRR
objects in integer mode.
Perform the following operations on the PLR connected to the non-Huawei device.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te fast-reroute-bandwidth compatible
The device is configured to save the bandwidth of FRR objects in integer mode.
By default, the bandwidth of FRR objects is saved in the float point mode.
----End
5.15.7 Verifying the Auto TE FRR Configuration
Prerequisites
The configurations of the auto TE FRR function are complete.
Procedure
l Run the display mpls te tunnel verbose command to check binding information about
the primary tunnel and the auto bypass tunnel.
l Run the display mpls lsp attribute bypass-inuse { inuse | not-exists | exists-not-used }
command to check information about the attribute of a specified bypass LSP.
l Run the display mpls lsp attribute bypass-tunnel tunnel-name command to check
information about the attribute of a bypass tunnel.
tunnel [ tunnel-name ] ] command to check detailed information about the tunnel
interface of a specified primary or bypass tunnel.
l Run the display mpls te tunnel path [ [ [ tunnel-name ] tunnel-name ] [ lsp-id ingress-
lsr-id session-id lsp-id ] | fast-reroute { local-protection-available | local-protection-
inuse } | lsr-role { ingress | transit | egress } ] command to check information about
paths of a specified primary or bypass tunnel.
statistics.

l Run the display mpls stale-interface [ interface-index ] [ verbose ] command to check

the information about MPLS interfaces in the Stale state.
----End
5.16 Configuring Association Between TE FRR and CR-

LSP Backup
After the primary CR-LSP is faulty, the system starts the TE FRR bypass tunnel and tries to
restore the primary CR-LSP the same time it sets up a backup CR-LSP.
Before configuring association between TE FRR and CR-LSP backup, complete the following
tasks:
l Configure CR-LSP backup (except for the best-effort path) in either hot standby mode or
ordinary backup mode. For details, see 5.13 Configuring CR-LSP Backup.
l Configure manual TE FRR or auto TE FRR. For details, see 5.14 Configuring Manual
TE FRR or 5.15 Configuring Auto TE FRR.
Context
Association between TE FRR and CR-LSP backup protects the entire CR-LSP.
Procedure
Step 3 Run mpls te backup frr-in-use
When the primary CR-LSP is faulty (that is, the primary CR-LSP is in FRR-in-use state), the
system starts the bypass CR-LSP and tries to restore the primary CR-LSP. At the same time,
the system attempts to set up a backup CR-LSP.
The tunnel configurations are committed.
----End
Verifying the Configuration

Run the display mpls te tunnel-interface [ tunnel interface-number | auto-bypass-tunnel
[ tunnel-name ] ] command to view information about the tunnel.

5.17 Configuring a Tunnel Protection Group

A configured protection tunnel can be bound to a working tunnel to form a tunnel protection
group. If the working tunnel fails, traffic switches to the protection tunnel. The tunnel
protection group helps improve tunnel reliability.
Before configuring a tunnel protection group, complete the following tasks:
l Create a working tunnel. For details, see 5.7 Configuring a Static MPLS TE Tunnel or
5.8 Configuring a Dynamic MPLS TE Tunnel.
l Create a protection tunnel. For details, see 5.7 Configuring a Static MPLS TE Tunnel
or 5.8 Configuring a Dynamic MPLS TE Tunnel.
NOTE
l A TE tunnel protection group enhances reliability of the primary tunnel through planning. Before
configuring a TE tunnel protection group, plan the network. To ensure better performance of the
protection tunnel, the protection tunnel must detour the links and nodes through which the primary
tunnel passes.
l Perform the operation of 5.19 Configuring Static BFD for CR-LSPs or 5.20 Configuring
Dynamic BFD for CR-LSPs to implement fast switching at the millisecond level.
Except that configuring the protection switching trigger mechanism is optional, other
configurations are mandatory.
5.17.1 Creating a Tunnel Protection Group

Context
A configured protection tunnel can be bound to a working tunnel to form a tunnel protection
group. If the working tunnel fails, traffic switches to the protection tunnel, improving tunnel
reliability.
When creating a tunnel protocol group, you can set the switchback delay and a switchback
mode. The switchback modes are classified into revertive and non-revertive modes. You can
set the switchback delay only when the revertive mode is used.
NOTE
You can also perform the following steps to modify a tunnel protection group.
Procedure

Step 3 Run mpls te protection tunnel tunnel-id [ holdoff holdoff-time ] [ mode { non-revertive |
revertive [ wtr wtr-time ] } ]
The working tunnel is added to the protection group.
The following parameters can be configured in this step:
l tunnel-id specifies the tunnel ID of a protection tunnel.
l The holdoff time specifies the time between the declaration of signal failure and the
initialization of protection switching. The holdoff time ranges from 0 to 100. The default
hold-off time is 0 milliseconds. holdoff-time specifies a multiplier of 100 milliseconds.
Holdoff-time = 100 milliseconds x holdoff-time
l non-revertive mode means that traffic does not switch back to a working tunnel even
though a working tunnel recovers.
l revertive mode means that traffic can switch back to a working tunnel after the working
tunnel recovers.
By default, the tunnel protection group works in revertive mode.
l Wait to restore (WTR) time is the time elapses before traffic switching is performed. The
WTR time ranges from 0 to 30 minutes. The default WTR time is 12 minutes. The wtr-
time parameter specifies a multiplier of 30 seconds.
WTR time = 30 seconds x wtr-time
NOTE
If the number of working tunnels in the same tunnel protection group is N, perform Step 2 and Step 3 on
each interface with a specific interface-number.

The current configuration of the tunnel protection group is committed.
----End
5.17.2 (Optional) Configuring the Protection Switching Trigger

Mechanism
Context
After configuring a tunnel protection group, you can configure a trigger mechanism of
protection switching to force traffic to switch to the primary LSP or the backup LSP.
Alternatively, you can perform switchover manually.
Pay attention to the protection switching mechanism before configuring the protection
switching trigger mechanism.
The device performs protection switching based on the following rules, see Table 5-27. ↑ in
this table indicates that the priority level in the upper line is higher than that in a lower line.

Table 5-27 Switching rules

Switching Request Order of Description
Priority
Clear Highest Clears all switching requests initiated manually,

including forcible and manual switching. A signal
failure does not trigger traffic switching.
Lockout of protection ↑ Prevents traffic from switching to a protection

tunnel even though a working tunnel fails.
Forcible switch ↑ Forcibly switches traffic from a working tunnel to a

protection tunnel, irrespective of whether the
protection tunnel functions properly (unless a
higher priority switch request takes effect).
Signal failure ↑ Automatically triggers protection switching.
Manual switching ↑ Switches traffic from a working tunnel to a

protection tunnel only when the protection tunnel
functions properly or switches traffic from the
protection tunnel to the working tunnel only when
the working tunnel functions properly.
Wait to restore ↑ Switches traffic from a protection tunnel to a

working tunnel after the working tunnel recovers
after the wait-to-restore (WTR) timer elapses.
No request Lowest There is no switching request.
Procedure
Step 3 Select one of the following protection switching trigger methods as required:
l To forcibly switch traffic from the working tunnel to the protection tunnel, run mpls te
protect-switch force
l To prevent traffic from switching on the working tunnel, run mpls te protect-switch
lock
l To switch traffic to the protection tunnel, run mpls te protect-switch manual
l To cancel the configuration of the protection switching trigger mechanism, run mpls te
protect-switch clear

The current configuration is committed.
----End
5.17.3 Verifying the Configuration of a Tunnel Protection Group
Prerequisites
All configurations of a tunnel protection group are complete.
Procedure
Step 1 Run the display mpls te protection tunnel { all | tunnel-id | interface tunnel interface-
number } [ verbose ] command to check information about a tunnel protection group.
Step 2 Run the display mpls te protection binding protect-tunnel { tunnel-id | interface tunnel
interface-number } command to check the binding between the working and protection
tunnels.
----End
5.18 Configuring Dynamic BFD for RSVP

When a Layer 2 device exists between a PLR and its downstream neighbors, configure
dynamic BFD for RSVP to detect link faults between RSVP neighboring nodes.
Before configuring dynamic BFD for RSVP, complete one of the following tasks:
MPLS TE Tunnel.
l Configure manual TE FRR. For details, see 5.14 Configuring Manual TE FRR.
l Configure auto TE FRR. For details, see 5.15 Configuring Auto TE FRR.
Except that adjusting BFD parameters is optional, other configurations are mandatory.
5.18.1 Enabling BFD Globally
Context
To configure dynamic BFD for RSVP, you must enable BFD on both ends of RSVP
neighbors.
Perform the following configurations on the two RSVP neighboring nodes with a Layer 2
device exists between them.
Procedure

Step 2 Run bfd
BFD is enabled globally.
----End
5.18.2 Enabling BFD for RSVP
Context
Enabling BFD for RSVP in the following manners:
l Enabling BFD for RSVP Globally

Enable BFD for RSVP globally when a large number of RSVP-enabled interfaces of the
local node need to be enabled with BFD for RSVP.
l Enabling BFD for RSVP on the RSVP Interface
Enable BFD for RSVP on the RSVP interface when a small number of RSVP-enabled
interfaces of the local node need to be enabled with BFD for RSVP.
Procedure
l Enable BFD for RSVP globally.
a. Run system-view

b. Run mpls

c. Run mpls rsvp-te bfd all-interfaces enable
BFD for RSVP is enabled globally.
After this command is run in the MPLS view, BFD for RSVP is enabled on all
RSVP interfaces except the interfaces with BFD for RSVP that are blocked.
d. (Optional) Disable BFD for RSVP on the RSVP interfaces that does not need to be
enabled with BFD for RSVP.
i. Run quit
ii. Run interface interface-type interface-number
The view of the RSVP-TE-enabled interface is displayed.
iii. On an Ethernet interface, run undo portswitch
iv. Run mpls rsvp-te bfd block
BFD for RSVP is disabled on the interface.

l Enable BFD for RSVP on the RSVP interface.

a. Run system-view
c. Run mpls rsvp-te bfd enable
BFD for RSVP is enabled on the RSVP interface.
----End
5.18.3 (Optional) Adjusting BFD Parameters

Context
BFD parameters are adjusted on the ingress node of a TE tunnel using either of the following
modes:
l Adjusting Global BFD Parameters
Adjust global BFD parameters when a large number of RSVP-enabled interfaces of the
local node use the same BFD parameters.
l Adjusting BFD Parameters on an RSVP Interface
Adjust global BFD parameters on an RSVP interface when certain RSVP-enabled
interfaces of the local node need to use BFD parameters different from global BFD
parameters.
Procedure
l Adjust global BFD parameters globally.
a. Run system-view
b. Run mpls
c. Run mpls rsvp-te bfd all-interfaces { min-tx-interval tx-interval | min-rx-
interval rx-interval | detect-multiplier multiplier } *
BFD parameters are set globally.
Parameters are described as follows:
n tx-interval indicates the Desired Min Tx Interval (DMTI), that is, the desired
minimum interval for the local end sending BFD control packets.
n rx-interval indicates the Required Min Rx Interval (RMRI), that is, the
supported minimum interval for the local end receiving BFD control packets.
n multiplier indicates the BFD detection multiplier.
BFD detection parameters that take effect on the local node may be different from
the configured parameters:

n Actual local sending interval = MAX { Locally-configured DMTI, Remotely-

configured RMRI }
n Actual local receiving interval = MAX { Remotely-configured DMTI,
Locally-configured RMRI }
n Actual local detection interval = Actual local receiving interval x Configured
remote detection multiplier
l Adjust BFD parameters on an RSVP interface.
a. Run system-view



NOTE
d. Run mpls rsvp-te bfd { min-tx-interval tx-interval | min-rx-interval rx-interval |
detect-multiplier multiplier } *
BFD parameters on the RSVP interface are adjusted.
----End
5.18.4 Verifying the Configuration of Dynamic BFD for RSVP
Prerequisites
The configurations of dynamic BFD for RSVP are complete.
Procedure
l Run the display mpls rsvp-te bfd session { all | interface interface-type interface-
number | peer ip-address } [ verbose ] command to check information about the BFD
for RSVP session.
l Run the display mpls rsvp-te command to check the RSVP-TE configuration.
l Run the display mpls rsvp-te interface [ interface-type interface-number ] command to
check the RSVP-TE configuration on the interface.
command to check information about the RSVP neighbor.
----End

5.19 Configuring Static BFD for CR-LSPs

Static BFD for CR-LSPs can rapidly detect a fault on a CR-LSP and notifies the forwarding
plane, ensuring fast traffic switchover.
Before configuring static BFD for CR-LSPs, complete one of the following tasks:
Tunnel.
MPLS TE Tunnel.
l Configure CR-LSP backup. For details, see 5.13 Configuring CR-LSP Backup.
l 5.17 Configuring a Tunnel Protection Group
The following configurations are mandatory.
Context
To configure static BFD for CR-LSP, you must enable BFD globally on the ingress node and
the egress node of a tunnel.
Perform the following configurations on the ingress and egress nodes of an MPLS TE tunnel.
Procedure
Step 2 Run bfd
----End
5.19.2 Configuring BFD Parameters on the Ingress Node of the

Tunnel
Context
The BFD parameters configured on the ingress node include the local and remote
discriminators, local intervals at which BFD packets are sent and received, and BFD detection
multiplier, which determine the establishment of a BFD session.

Procedure
Step 2 Run bfd cfg-name bind mpls-te interface tunnel interface-number te-lsp [ backup ]
BFD is configured to detect the primary or backup CR-LSP bound to a specified tunnel.
The parameter backup means that backup CR-LSPs are to be checked.
Step 3 Run discriminator local discr-value
The local discriminator is set.
Step 4 Run discriminator remote discr-value
The remote discriminator is set.
Step 5 (Optional) Run min-tx-interval interval
The local interval at which BFD packets are sent is set.
Step 6 (Optional) Run min-rx-interval interval
The local interval at which BFD packets are received is set.
Step 7 (Optional) Run detect-multiplier multiplier
The local detection multiplier is adjusted.
By default, the local detection multiplier is 3.
Actual local sending interval = MAX { Configured local sending interval, Configured remote
receiving interval }
Actual local receiving interval = MAX { Configured remote sending interval, Configured
local receiving interval }
Actual local detection interval = Actual local receiving interval x Configured remote detection
multiplier
For example:
l The local sending and receiving intervals are set to 200 ms and 300 ms respectively and
the detection multiplier is set to 4.
l The remote sending and receiving intervals are set to 100 ms and 600 ms respectively
and the detection multiplier is set to 5.
Then,
l Actual local sending interval = MAX {200 ms, 600 ms} = 600 ms; Actual local
receiving interval = MAX {100 ms, 300 ms} = 300 ms; Actual local detection interval is
300 ms x 5 = 1500 ms.
l Actual remote sending interval = MAX {100 ms, 300 ms} = 300 ms; Actual remote
receiving interval = MAX {200 ms, 600 ms} = 600 ms; Actual remote detection interval
is 600 ms x 4 = 2400 ms.
Step 8 Run process-pst

The system is enabled to modify the port status table (PST) when the BFD session status
changes.
When the BFD status changes, BFD notifies the application of the change, triggering a fast
switchover between the primary and backup CR-LSPs.
Step 9 Run notify neighbor-down
A BFD session is configured to notify the upper layer protocol when the BFD session detects
a neighbor Down event.
In most cases, when you use a BFD session to detect link faults, the BFD session notifies the
upper layer protocol of a link fault in the following scenarios:
l When the BFD detection time expires, the BFD session notifies the upper layer protocol.
BFD sessions must be configured on both ends. If the BFD session on the local end does
not receive any BFD packets from the remote end within the detection time, the BFD
session on the local end concludes that the link fails and notifies the upper layer protocol
of the link fault.
l When a BFD session detects a neighbor Down event, the BFD session notifies the upper
layer protocol. If the BFD session on the local end detects a neighbor Down event within
the detection time, the BFD session on the local end directly notifies the upper layer
protocol of the neighbor Down event.
When you use a BFD session to detect faults on an LSP, you need only be concerned about
whether a fault occurs on the link from the local end to remote end. In this situation, run the
notify neighbor-down command to configure the BFD session to notify the upper layer
protocol only when the BFD session detects a neighbor Down event. This configuration
prevents the BFD session from notifying the upper layer protocol when the BFD detection
time expires and ensures that services are not interrupted.
Step 10 Run commit
----End
5.19.3 Configuring BFD Parameters on the Egress Node of the

Tunnel
Context
The BFD parameters configured on the egress node include the local and remote
Procedure
Step 2 Configure a reverse tunnel to inform the ingress node of a fault if the fault occurs. The reverse
tunnel can be the IP link, LSP, or TE tunnel. To ensure that the forward and reverse paths are

over the same link, a CR-LSP is preferentially selected to notify the ingress node of an LSP
fault. Run the following commands as required.
l For an IP link, run bfd session-name bind peer-ip ip-address [ vpn-instance vpn-name ]
[ interface interface-type interface-number] [ source-ip ip-address ]
l For an LDP LSP, run bfd session-name bind ldp-lsp peer-ip ip-address nexthop ip-
address [ interface interface-type interface-number ]
l For a static LSP, run bfd session-name bind static-lsp lsp-name
l For a CR-LSP, run bfd session-name bind mpls-te interface tunnel interface-number
te-lsp [ backup ]
l For a TE tunnel, run bfd session-name bind mpls-te interface tunnel interface-number
NOTE
When an IP link is used as the reverse tunnel, you do not need to perform steps 8 and 9.
multiplier
For example:
Then,
300 ms x 5 = 1500 ms.

is 600 ms x 4 = 2400 ms.
Step 8 (Optional) Run process-pst
changes.
If an LSP or a TE tunnel is used as a reverse tunnel to notify the ingress node of a fault, you
can run this command to allow the reverse tunnel to switch traffic if the BFD session goes
Down. If a single-hop IP link is used as a reverse tunnel, this command can be configured.
Because the process-pst command can be only configured for BFD single-link detection.
of the link fault.
Step 10 Run commit
----End
5.19.4 Verifying the Configuration of Static BFD for CR-LSPs
Prerequisites
The configurations of static BFD for CR-LSPs are complete.
Procedure
l Run the display bfd configuration mpls-te interface tunnel interface-number te-lsp
[ verbose ] command to check BFD configurations on the ingress.
l Run the following commands to check BFD configurations on the egress:

– Run the display bfd configuration all [ for-ip | for-lsp | for-te ] [ verbose ]
command to check all BFD configurations.
– Run the display bfd configuration static [ for-ip | for-lsp | for-te | name cfg-
name ] [ verbose ] command to check the static BFD configurations.
– Run the display bfd configuration peer-ip peer-ip [ vpn-instance vpn-instance-
name ] [ verbose ] command to check the configurations of BFD with the reverse
path being an IP link.
– Run the display bfd configuration static-lsp lsp-name [ verbose ] command to
check the configurations of BFD with the reverse path being a static LSP.
– Run the display bfd configuration ldp-lsp peer-ip peer-ip nexthop nexthop-
address [ interface interface-type interface-number ] [ verbose ] command to
check the configurations of BFD with the backward channel being an LDP LSP.
– Run the display bfd configuration mpls-te interface tunnel interface-number te-
lsp [ verbose ] command to check the configurations of BFD with the backward
channel being a CR-LSP.
– Run the display bfd configuration mpls-te interface tunnel interface-number
[ verbose ] command to check the configurations of BFD with the backward
channel being a TE tunnel.
l Run the display bfd session mpls-te interface tunnel interface-number te-lsp
[ verbose ] command to check BFD session configurations on the ingress.
l Run the following commands to check BFD session configurations on the egress:
– Run the display bfd session all [ for-ip | for-lsp | for-te ] [ verbose ] command to
check all the BFD configurations.
– Run the display bfd session static [ for-ip | for-lsp | for-te ] [ verbose ] command
to check the static BFD configurations.
– Run the display bfd session peer-ip peer-ip [ vpn-instance vpn-instance-name ]
channel being an IP link.
– Run the display bfd session static-lsp lsp-name [ verbose ] command to check the
configurations of BFD with the backward channel being a static LSP.
– Run the display bfd session ldp-lsp peer-ip peer-ip nexthop nexthop-address
[ interface interface-type interface-number ] [ verbose ] command to check the
configurations of BFD with the backward channel being an LDP LSP.
– Run the display bfd session mpls-te interface tunnel interface-number te-lsp
– Run the display bfd session mpls-te interface tunnel interface-number [ verbose ]
command to check the configurations of BFD with the backward channel being a
TE tunnel.
l Run the following command to check BFD statistics:
– Run the display bfd statistics session all [ for-ip | for-lsp | for-te ] command to
check all BFD session statistics.
– Run the display bfd statistics session peer-ip peer-ip [ vpn-instance vpn-instance-
name ] command to check statistics about the BFD session that detects faults in the
IP link.
– Run the display bfd statistics session static-lsp lsp-name command to check
statistics about the BFD session that detects faults in the static LSP.

– Run the display bfd statistics session ldp-lsp peer-ip peer-ip nexthop nexthop-
address [ interface interface-type interface-number ] command to check statistics
of the BFD session that detects faults in the LDP LSP.
– Run the display bfd statistics session mpls-te interface tunnel interface-number
te-lsp command to check statistics about the BFD session that detects faults in the
CR-LSP.
command to check statistics on BFD sessions for TE tunnels.
----End
5.20 Configuring Dynamic BFD for CR-LSPs

Compared with static BFD for CR-LSPs, dynamic BFD for CR-LSPs simplifies the
configuration and reduces manual operations.
Before configuring dynamic BFD for CR-LSPs, complete one of the following tasks:
Tunnel.
MPLS TE Tunnel.
l Configure CR-LSP backup. For details, see 5.13 Configuring CR-LSP Backup.
l 5.17 Configuring a Tunnel Protection Group
Except that adjusting BFD parameters is optional, other configurations are mandatory.
Context
To configure dynamic BFD for CR-LSP, enable BFD globally on the ingress node and the
egress node of a tunnel.
Procedure
Step 2 Run bfd
----End

5.20.2 Enabling the Capability of Dynamically Creating BFD

Sessions on the Ingress
Context
Enabling the capability of dynamically creating BFD sessions on a TE tunnel can be
implemented in either of the following methods:
l Enabling MPLS TE BFD Globally when BFD sessions need to be created

automatically on a large number of TE tunnels of the ingress node
l Enabling MPLS TE BFD on the Tunnel Interface when BFD sessions need to be
created automatically on a small number of TE tunnels of the ingress node
Procedure
l Enable MPLS TE BFD globally.
a. Run system-view

b. Run mpls

c. Run mpls te bfd enable
The capability of dynamically creating BFD sessions is enabled on the TE tunnel.
After this command is run in the MPLS view, dynamic BFD for TE is enabled on
all the tunnel interfaces, excluding the interfaces on which dynamic BFD for TE are
blocked.
d. (Optional) Block the capability of dynamically creating BFD sessions for TE on the
tunnel interfaces of the TE tunnels that do not need dynamic BFD for TE.
i. Run quit
ii. Run interface tunnel interface-number
The TE tunnel interface view is displayed.
iii. Run mpls te bfd block
The capability of dynamically creating BFD sessions on the tunnel interface is
blocked.
iv. Run mpls te commit
The current configuration on this tunnel interface is committed.
l Enable MPLS TE BFD on a tunnel interface.
a. Run system-view


c. Run mpls te bfd enable

The capability of dynamically creating BFD sessions is enabled on the TE tunnel.
The command configured in the tunnel interface view takes effect only on the
current tunnel interface.
The configuration of the TE tunnel is committed.
----End
5.20.3 Enabling the Capability of Passively Creating BFD Sessions

on the Egress
Context
On a unidirectional LSP, creating a BFD session on the active role (ingress node) triggers the
sending of LSP ping request messages to the passive role (egress node). Only after the passive
role receives the ping packets, a BFD session can be automatically set up.
Procedure
Step 2 Run bfd
The BFD view is displayed.
Step 3 Run mpls-passive
The capability of passively creating BFD sessions is enabled.
After this command is run, a BFD session can be created only after the egress receives an LSP
Ping request containing a BFD TLV from the ingress.
----End
5.20.4 (Optional) Adjusting BFD Parameters

Context
BFD parameters are adjusted on the ingress node of a TE tunnel using either of the following
modes:
l Adjusting Global BFD Parameters when a large number of TE tunnels on the ingress
node use the same BFD parameters
l Adjusting BFD Parameters on an Interface when certain TE tunnels on the ingress
node need to use BFD parameters different from global BFD parameters

multiplier
On the egress node of the TE tunnel enabled with the capability of passively creating BFD
sessions, the default values of the receiving interval, sending interval and detection multiplier
cannot be adjusted. The default values of these three parameters are the minimum
configurable values on the egress node. Therefore, the BFD detection interval on the ingress
and that on the egress node of a CR-LSP are as follows:
l Actual detection interval on the ingress = Configured receiving interval on the ingress
node x 3
l Actual detection interval on the egress = Configured sending interval on the ingress x
Configured detection multiplier on the ingress node
Procedure
l Adjust global BFD parameters.
a. Run system-view

b. Run mpls

c. Run mpls te bfd { min-tx-interval tx-interval | min-rx-interval rx-interval |
BFD time parameters are adjusted globally.

l Adjust BFD parameters on the tunnel interface.
a. Run system-view


c. Run mpls te bfd { min-tx-interval tx-interval | min-rx-interval rx-interval |
BFD time parameters are adjusted.
If min-tx-interval tx-interval configured on a local end is different from min-rx-

interval rx-interval configured on a remote end, the larger value takes effect.
The detect-multiplier multiplier value configured on the remote end takes effect.
The current configurations of the TE tunnel interface are committed.
----End

5.20.5 Verifying the Configuration of Dynamic BFD for CR-LSPs
Prerequisites
The configurations of dynamic BFD for CR-LSPs are complete.
Procedure
l Run the display bfd configuration dynamic [ verbose ] command to check the
configuration of dynamic BFD on the ingress.
l Run the display bfd configuration passive-dynamic [ peer-ip peer-ip remote-
discriminator discriminator ] [ verbose ] command to check the configuration of
dynamic BFD on the egress.
l Run the display bfd session dynamic [ verbose ] command to check information about
the BFD session on the ingress.
l Run the display bfd session passive-dynamic [ peer-ip peer-ip remote-discriminator
remote-discr-value ] [ verbose ] command to check information about the BFD session
passively created on the egress.
l Check the BFD statistics.
– Run the display bfd statistics command to check statistics about all BFD sessions.
– Run the display bfd statistics session dynamic command to check statistics about
dynamic BFD sessions.
l Run the display mpls bfd session [ fec fec-address | monitor | nexthop ip-address |
outgoing-interface interface-type interface-number | statistics | verbose ] or display
mpls bfd session protocol { cr-static | rsvp-te } [ lsp-id ingress-lsr-id session-id lsp-id
[ verbose ] ] command to check information about BFD sessions.
----End
5.21 Configuring Static BFD for TE Tunnels

Static BFD for TE allows applications such as VPN FRR and VLL FRR to fast switch traffic
if the primary tunnel fails, preventing service interruption.
Before configuring static BFD for TE tunnels, complete one of the following tasks:
Tunnel.
MPLS TE Tunnel.
l Configure a tunnel protection group. For details, see 5.17 Configuring a Tunnel
Protection Group.
The following configurations are mandatory.

Context
To configure static BFD for TE, enable BFD globally on the ingress and egress nodes of a
tunnel.
Procedure
Step 2 Run bfd
----End
5.21.2 Configuring BFD Parameters on the Ingress Node of the

Tunnel
Context
The BFD parameters configured on the ingress node include the local and remote
Procedure
Step 2 Run bfd cfg-name bind mpls-te interface tunnel interface-number
BFD is configured to detect faults in a specified tunnel.
NOTE
If the status of the tunnel to be checked is Down, the BFD session cannot be set up.


multiplier
For example:
Then,
300 ms x 5 = 1500 ms.
is 600 ms x 4 = 2400 ms.
Step 8 Run process-pst
changes.
When the BFD status changes, BFD notifies the application of the change, triggering a fast
switchover between TE tunnels.
of the link fault.

Step 10 Run commit
----End
5.21.3 Configuring BFD Parameters on the Egress Node of the

Tunnel
Context
The BFD parameters configured on the egress node include the local and remote
Procedure
Step 2 Configure a reverse tunnel to inform the ingress node of a fault if the fault occurs. The reverse
tunnel can be the IP link, LSP, or TE tunnel. To ensure that the forward and reverse paths are
over the same link, a TE tunnel is preferentially selected to notify the ingress node of an LSP
fault. Run the following commands as required.
l For an IP link, run bfd session-name bind peer-ip ip-address [ vpn-instance vpn-name ]
[ interface interface-type interface-number] [ source-ip ip-address ]
l For an LDP LSP, run bfd session-name bind ldp-lsp peer-ip ip-address nexthop ip-
address [ interface interface-type interface-number ]
l For a static LSP, run bfd session-name bind static-lsp lsp-name
l For a TE tunnel, run bfd session-name bind mpls-te interface tunnel interface-number
NOTE
When an IP link is used as the reverse tunnel, you do not need to perform steps 8 and 9.



multiplier
For example:
Then,
300 ms x 5 = 1500 ms.
is 600 ms x 4 = 2400 ms.
Step 8 (Optional) Run process-pst
changes.
If an LSP or a TE tunnel is used as a reverse tunnel to notify the ingress node of a fault, you
can run this command to allow the reverse tunnel to switch traffic if the BFD session goes
Down. If a single-hop IP link is used as a reverse tunnel, this command can be configured.
Because the process-pst command can be only configured for BFD single-link detection.
of the link fault.

Step 10 Run commit
----End
5.21.4 Verifying the Configuration of Static BFD for TE Tunnels
Prerequisites
The configurations of static BFD for TE tunnels are complete.
Procedure
l Run the display bfd configuration mpls-te interface tunnel interface-number
[ verbose ] command to check BFD configurations on the ingress.
l Run the following commands to check BFD configurations on the egress:
– Run the display bfd configuration all [ for-ip | for-lsp | for-te ] [ verbose ]
command to check all BFD configurations.
– Run the display bfd configuration static [ for-ip | for-lsp | for-te | name cfg-
name ] [ verbose ] command to check the static BFD configurations.
– Run the display bfd configuration peer-ip peer-ip [ vpn-instance vpn-instance-
name ] [ verbose ] command to check the configurations of BFD with the reverse
path being an IP link.
– Run the display bfd configuration static-lsp lsp-name [ verbose ] command to
check the configurations of BFD with the reverse path being a static LSP.
– Run the display bfd configuration ldp-lsp peer-ip peer-ip nexthop nexthop-
address [ interface interface-type interface-number ] [ verbose ] command to
check the configurations of BFD with the backward channel being an LDP LSP.
– Run the display bfd configuration mpls-te interface tunnel interface-number te-
lsp [ verbose ] command to check the configurations of BFD with the backward
– Run the display bfd configuration mpls-te interface tunnel interface-number
channel being a TE tunnel.
l Run the display bfd session mpls-te interface tunnel interface-number [ verbose ]
command to check BFD session configurations on the ingress.
l Run the following commands to check BFD session configurations on the egress:
– Run the display bfd session all [ for-ip | for-lsp | for-te ] [ verbose ] command to
check all the BFD configurations.

– Run the display bfd session static [ for-ip | for-lsp | for-te ] [ verbose ] command
to check the static BFD configurations.
– Run the display bfd session peer-ip peer-ip [ vpn-instance vpn-instance-name ]
channel being an IP link.
– Run the display bfd session static-lsp lsp-name [ verbose ] command to check the
configurations of BFD with the backward channel being a static LSP.
– Run the display bfd session ldp-lsp peer-ip peer-ip nexthop nexthop-address
[ interface interface-type interface-number ] [ verbose ] command to check the
configurations of BFD with the backward channel being an LDP LSP.
– Run the display bfd session mpls-te interface tunnel interface-number te-lsp
– Run the display bfd session mpls-te interface tunnel interface-number [ verbose ]
command to check the configurations of BFD with the backward channel being a
TE tunnel.
l Run the following command to check BFD statistics:
– Run the display bfd statistics session all [ for-ip | for-lsp | for-te ] command to
check all BFD session statistics.
– Run the display bfd statistics session peer-ip peer-ip [ vpn-instance vpn-instance-
name ] command to check statistics about the BFD session that detects faults in the
IP link.
– Run the display bfd statistics session static-lsp lsp-name command to check
statistics about the BFD session that detects faults in the static LSP.
– Run the display bfd statistics session ldp-lsp peer-ip peer-ip nexthop nexthop-
address [ interface interface-type interface-number ] command to check statistics
of the BFD session that detects faults in the LDP LSP.
te-lsp command to check statistics about the BFD session that detects faults in the
CR-LSP.
command to check statistics on BFD sessions for TE tunnels.
----End
5.22 Configuring RSVP GR

RSVP GR prevents service interruptions during an active/standby switchover and allows a
dynamic CR-LSP to be restored.
Before configuring RSVP GR, complete the following tasks:
MPLS TE Tunnel.
l Configure IS-IS GR or OSPF GR on each LSR.

Enabling the RSVP GR support function and modifying the basic time and configuring Hello
sessions between RSVP GR nodes are optional.
5.22.1 Enabling the RSVP Hello Extension Function
Context
By configuring the RSVP Hello extension, you can enable a device to quickly check
reachability between RSVP nodes.
Perform the following configurations on a GR node and its neighboring nodes.
Procedure
Step 2 Run mpls
The RSVP Hello extension function is enabled globally.
Step 4 Run quit
The RSVP-TE interface view is displayed.

NOTE
The RSVP Hello extension function is enabled on the interface.
By default, although the RSVP Hello extension function has been enabled globally, it is
disabled on RSVP-enabled interfaces.
----End

5.22.2 Enabling RSVP GR
Context
RSVP GR prevents service interruptions during an active/standby switchover and allows a
dynamic CR-LSP to be restored.
Perform the following configurations on a GR node.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te hello full-gr
The RSVP GR function and the RSVP GR helper function are enabled.
By default, the RSVP GR function and the RSVP GR helper function are disabled.
----End
5.22.3 (Optional) Enabling the RSVP GR Helper Function
Context
By being enabled with RSVP GR Helper, a device supports the GR capability of its neighbor.
RSVP GR takes effect on the RSVP GR-enabled neighbor automatically after the neighbor is
enabled with RSVP GR. If the GR node's neighbor is a GR node, do not perform the
following configurations. If the GR node's neighbor is not a GR node, perform the following
configurations.
Perform the following configurations on GR Helper nodes.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te hello support-peer-gr
The function of RSVP GR Helper on the neighbor is enabled.
----End

5.22.4 (Optional) Configuring Hello Sessions Between RSVP GR

Nodes
Context
If TE FRR is deployed, a Hello session is required between a PLR and an MP.
Perform the following configurations on the PLR and MP of the bypass CR-LSP.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te hello nodeid-session ip-address
A Hello session is set up between a restarting node and a neighbor node.
ip-address is the LSR ID of the RSVP neighbor.
----End
5.22.5 (Optional) Modifying Basic Time
Context
After an active/standby switchover starts, an RSVP GR node has an RSVP smoothing period,
during which the data plane continues forwarding data if the control plane is not restored.
After RSVP smoothing is completed, a restart timer is started.
Restart timer value = Basic time + Number of ingress LSPs x 60 ms + Number of none-
ingress LSPs x 15 ms
In this formula, the default basic time is 90 seconds and is configurable by using a command
line, and the number of LSPs is the number of LSPs with the local node being the ingress.
After the restart timer expires, the recovery timer is started.
Recovery timer = Restart time + Total number of LSPs x 40 ms
Perform the following configurations on a GR node.
Procedure
Step 2 Run mpls

Step 3 Run mpls rsvp-te hello basic-restart-time basic-restart-time

The RSVP GR basic time is modified.
By default, the RSVP GR basic time is 90 seconds.
----End
5.22.6 Verifying the RSVP GR Configuration

Prerequisites
The configurations of RSVP GR are complete.
Procedure
l Run the display mpls rsvp-te graceful-restart command to check the status of the local
RSVP GR.
l Run the display mpls rsvp-te graceful-restart peer [ { interface interface-type
interface-number | node-id } [ ip-address ] ] command to check the status of RSVP GR
on a neighbor.
----End
5.23 Maintaining MPLS TE
5.23.1 Verifying the Connectivity of the TE Tunnel

Procedure
l Run the ping lsp [ -a source-ip | -c count | -exp exp-value | -h ttl-value | -m interval | -r
reply-mode | -s packet-size | -t time-out | -v ] * te tunnel interface-number [ hot-standby
| primary ] [ draft6 ] command to check the connectivity of the TE tunnel between the
ingress and egress.
If draft6 is specified, the ping lsp command is implemented according to draft-ietf-mpls-
lsp-ping-06. By default, the command is implemented according to RFC 4379. If the
hot-standby parameter is specified, the hot-standby CR-LSP can be tested.
l Run the tracert lsp [ -a source-ip | -exp exp-value | -h ttl-value | -r reply-mode | -t time-
out ] * te tunnel interface-number [ hot-standby | primary ] [ draft6 ] command to
trace the hops of a TE tunnel.
If draft6 is specified, the tracert lsp command is implemented according to draft-ietf-
mpls-lsp-ping-06. By default, the command is implemented according to RFC 4379. If
the hot-standby parameter is specified, the hot-standby CR-LSP can be tested.
----End

5.23.2 Verifying a TE Tunnel by Using NQA

Procedure
After configuring MPLS TE, you can use NQA to check the connectivity and jitter of the TE
tunnel. For detailed configurations, see NQA Configuration in the S1720, S2700, S5700, and
S6720 V200R012(C00&C20) Configuration Guide - Network Management and Monitoring.
5.23.3 Enabling the MPLS TE Trap Function

Context
To facilitate operation and maintenance and learn about the running status of the MPLS
network, configure the MPLS TE trap function so that the device can notify the NMS of the
RSVP and MPLS TE status change and usage of dynamic labels.
If the proportion of used MPLS resources, such as LSPs, dynamic labels, and dynamic BFD
sessions to all supported ones reaches a specified upper limit, new MPLS services may fail to
be established because of insufficient resources. To facilitate operation and maintenance, an
upper alarm threshold of MPLS resource usage can be set. If MPLS resource usage reaches
the specified upper alarm threshold, an alarm is generated.
Procedure
l Configure the RSVP trap function.
a. Run the system-view command to enter the system view.
b. Run the snmp-agent trap enable feature-name mpls_rsvp [ trap-name trap-
name ] command to enable the trap function for the RSVP module.
By default, the trap function is disabled for the RSVP module.
l Configure the alarm function for LSPM.
b. Run the snmp-agent trap enable feature-name mpls_lspm trap-name trapname
command to enable the trap function for the LSPM module.
By default, the trap function is disabled for the LSPM module.
c. Run the snmp-agent trap suppress feature-name lsp trap-name { mplsxcup |
mplsxcdown } trap-interval trap-interval [ max-trap-number max-trap-number ]
command to set the interval for suppressing excess LSP traps.
By default, the interval for suppressing the display of excessive LSP traps is 300
seconds, and a maximum of three LSP traps can be sent in the suppression interval.
d. Run the mpls command to enter the MPLS view.
e. Run the mpls dynamic-label-number threshold-alarm upper-limit upper-limit-
value lower-limit lower-limit-value command to set alarm thresholds for dynamic
label usage.
You can set the following parameters:
n upper-limit-value: a percent indicating the upper limit of dynamic labels. If
dynamic label usage reaches the upper limit, an alarm is generated. An upper
limit less than or equal to 95% is recommended.

n lower-limit-value: a percent indicating the lower limit of dynamic labels. If

dynamic label usage falls below the lower limit, an alarm is generated.
n The value of upper-limit-value must be greater than that of lower-limit-value.
By default, the upper limit is 80%, and the lower limit is 70%, which are
recommended.
NOTE
l Each command only configures the trigger conditions for an alarm and its clear alarm.
Although trigger conditions are met, the alarm and its clear alarm can be generated only
after the snmp-agent trap enable feature-name mpls_lspm trap-name
{ hwMplsDynamicLabelThresholdExceed |
hwMplsDynamicLabelThresholdExceedClear } command is run to enable the device
to generate a dynamic label insufficiency alarm and its clear alarm.
l After the snmp-agent trap enable feature-name mpls_lspm trap-name
{ hwMplsDynamicLabelTotalCountExceed |
hwMplsDynamicLabelTotalCountExceedClear } command is run to enable the device
to generate limit-reaching alarms and their clear alarms, the following situations occur:
l If the number of dynamic labels reaches the maximum number of dynamic labels
supported by a device, a limit-reaching alarm is generated.
l If the number of dynamic labels falls below 95% of the maximum number of
dynamic labels supported by the device, a clear alarm is generated.
f. Run the mpls rsvp-lsp-number [ ingress | transit | egress ] threshold-alarm
upper-limit upper-limit-value lower-limit lower-limit-value command to configure
the upper and lower thresholds of alarms for RSVP LSP usage.
The parameters in this command are described as follows:
n upper-limit-value specifies the upper threshold of alarms for RSVP LSP usage.
An alarm is generated when the proportion of established RSVP LSPs to total
supported RSVP LSPs reaches the upper limit.
n lower-limit-value specifies the lower threshold of clear alarms for RSVP LSP
usage. A clear alarm is generated when the proportion of established RSVP
LSPs to total supported RSVP LSPs falls below the lower limit.
The default upper limit of an alarm for RSVP LSP usage is 80%. The default lower
limit of a clear alarm for RSVP LSP usage is 75%. Using the default upper limit
and lower limit is recommended.

NOTE
l This command configures the alarm threshold for RSVP LSP usage. The alarm that the
number of RSVP LSPs reached the upper threshold is generated only when the
command snmp-agent trap enable feature-name mpls_lspm trap-name
hwmplslspthresholdexceed is configured, and the actual RSVP LSP usage reaches the
upper limit of the alarm threshold. The alarm that the number of RSVP LSPs fell below
the lower threshold is generated only when the command snmp-agent trap enable
feature-name mpls_lspm trap-name hwmplslspthresholdexceedclear is configured,
and the actual RSVP LSP usage falls below the lower limit of the clear alarm threshold.
{ hwmplslsptotalcountexceed | hwmplslsptotalcountexceedclear } command is run to
enable LSP limit-crossing alarm and LSP limit-crossing clear alarm, an alarm is
generated in the following situations:
l If the total number of RSVP LSPs reaches the upper limit, a limit-crossing alarm is
generated.
l If the total number of RSVP LSPs falls below 95% of the upper limit, a limit-
crossing clear alarm is generated.
g. Run the mpls total-crlsp-number [ ingress | transit | egress ] threshold-alarm
upper-limit upper-limit-value lower-limit lower-limit-value command to configure
the upper and lower thresholds of alarms for total CR-LSP usage.
The parameters in this command are described as follows:
n upper-limit-value specifies the upper threshold of alarms for total CR-LSP

usage. An alarm is generated when the proportion of established CR-LSPs to
total supported CR-LSPs reaches the upper limit.
n lower-limit-value specifies the lower threshold of clear alarms for total CR-
LSP usage. A clear alarm is generated when the proportion of established CR-
LSPs to total supported CR-LSPs falls below the lower limit.
The default upper limit of an alarm for total CR-LSP usage is 80%. The default
lower limit of a clear alarm for total CR-LSP usage is 75%. Using the default upper
limit and lower limit is recommended.
NOTE
l This command configures the alarm threshold for total CR-LSP usage. The alarm that
the number of total CR-LSPs reached the upper threshold is generated only when the
command snmp-agent trap enable feature-name mpls_lspm trap-name
hwmplslspthresholdexceed is configured, and the actual total CR-LSP usage reaches
the upper limit of the alarm threshold. The alarm that the number of total CR-LSPs fell
below the lower threshold is generated only when the command snmp-agent trap
enable feature-name mpls_lspm trap-name hwmplslspthresholdexceedclear is
configured, and the actual total CR-LSP usage falls below the lower limit of the clear
alarm threshold.
{ hwmplslsptotalcountexceed | hwmplslsptotalcountexceedclear } command is run to
enable LSP limit-crossing alarm and LSP limit-crossing clear alarm, an alarm is
generated in the following situations:
l If the total number of CR-LSPs reaches the upper limit, a limit-crossing alarm is
generated.
l If the total number of CR-LSPs falls below 95% of the upper limit, a limit-crossing
clear alarm is generated.
l Configure MPLS resource threshold-related alarms.


b. Run the mpls command to enter the MPLS view.
c. Run the mpls rsvp-peer-number threshold-alarm upper-limit upper-limit-value
lower-limit lower-limit-value command to configure the conditions that trigger the
threshold-reaching alarm and its clear alarm for RSVP neighbors.
Note the following issues when configuring trigger conditions:
n upper-limit-value: upper alarm threshold for the proportion of configured
RSVP neighbors to all RSVP neighbors supported by a device.
n lower-limit-value: lower alarm threshold for the proportion of configured
RSVP neighbors to all RSVP neighbors supported by a device.
By default, the upper alarm threshold is 80%, and the lower alarm threshold is 75%,
which are recommended.
NOTE
l The mpls rsvp-peer-number threshold-alarm command only configures the trigger

conditions for an alarm and its clear alarm. Although trigger conditions are met, the
alarm and its clear alarm can be generated only after the snmp-agent trap enable
feature-name mpls_rsvp trap-name { hwrsvpteifnbrthresholdexceed |
hwrsvpteifnbrthresholdexceedclear } command is run to enable the device to generate
the RSVP neighbor threshold-reaching alarm and its clear alarm.
l After the snmp-agent trap enable feature-name mpls_rsvp trap-name
{ hwrsvpteifnbrtotalcountexceed | hwrsvpteifnbrtotalcountexceedclear } command
is run to enable the device to generate limit-reaching alarms and their clear alarms, the
following situations occur:
l If the number of configured RSVP neighbors reaches the maximum number of
RSVP neighbors supported by a device, a limit-reaching alarm is generated.
l If the number of configured RSVP neighbors falls below 95% of the maximum
number of RSVP neighbors supported by the device, a clear alarm is generated.
d. Run the mpls bfd-te-number threshold-alarm upper-limit upper-limit-value
lower-limit lower-limit-value command to configure the conditions that trigger the
threshold-reaching alarm and its clear alarm for dynamic BFD sessions for TE.
n upper-limit-value: upper alarm threshold for the proportion of used TE
resources to all TE resources supported by a device.
n lower-limit-value: lower alarm threshold for the proportion of used TE

NOTE
{ hwmplsresourcethresholdexceed | hwmplsresourcethresholdexceedclear }
command is run to enable the device to generate an MPLS resource insufficiency alarm
and its clear alarm.
{ hwmplsresourcetotalcountexceed | hwmplsresourcetotalcountexceedclear }
command is run to enable the device to generate limit-reaching alarms and their clear
alarms, the following situations occur:
l If the number of used TE resources reaches the maximum number of TE resources
l If the number of used TE resources falls below 95% of the maximum number of
TE resources supported by a device, a clear alarm is generated.
e. Run the mpls autobypass-tunnel-number threshold-alarm upper-limit upper-
limit-value lower-limit lower-limit-value command to configure the conditions that
trigger the threshold-reaching alarm and its clear alarm for Auto bypass tunnel
interfaces.
n upper-limit-value: upper alarm threshold for the proportion of used TE
n lower-limit-value: lower alarm threshold for the proportion of used TE
NOTE
{ hwmplsresourcethresholdexceed | hwmplsresourcethresholdexceedclear }
command is run to enable the device to generate an MPLS resource insufficiency alarm
and its clear alarm.
{ hwmplsresourcetotalcountexceed | hwmplsresourcetotalcountexceedclear }
command is run to enable the device to generate limit-reaching alarms and their clear
alarms, the following situations occur:
l If the number of used TE resources reaches the maximum number of TE resources
l If the number of used TE resources falls below 95% of the maximum number of
TE resources supported by a device, a clear alarm is generated.
----End
Checking the Configuration

l Run the display snmp-agent trap feature-name mpls_rsvp all command to view status
of all traps on the RSVP module.
l Run the display snmp-agent trap feature-name mpls_lspm all command to view
status of all traps on the LSPM module.

5.23.4 Configuring Conditions That Trigger CSPF Resource

Threshold-Reaching Alarms
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the mpls command to enter the MPLS view.
Step 3 Run the mpls { cspf-link-number | cspf-node-number | cspf-nlsa-number | cspf-srlg-

number } threshold-alarm upper-limit upper-limit-value lower-limit lower-limit-value
command to set the upper and lower alarm thresholds for proportion of used CSPF resources
to the maximum number of CSPF resources that device supports.
Configure the following parameters in the preceding command:
l upper-limit-value specifies the upper alarm threshold (percent) for the proportion of used
CSPF resources to the maximum number of CSPF resources that a device supports.
l lower-limit-value specifies the lower alarm threshold (percent) for the proportion of used
CSPF resources to the maximum number of CSPF resources that a device supports.
upper-limit-value must be greater than lower-limit-value.
By default, the upper threshold for alarms is 80%, and the lower threshold for clear alarms is
75%, which are recommended.
NOTE
l The mpls cspf threshold-alarm command only configures the trigger conditions for alarms and
clear alarms. Although trigger conditions are met, an alarm and its clear alarm can be generated only
{ hwmplsresourcethresholdexceed | hwmplsresourcethresholdexceedclear } command is run to
enable the device to generate an MPLS resource insufficiency alarm and its clear alarm.
{ hwmplsresourcetotalcountexceed | hwmplsresourcetotalcountexceedclear } command is run to
enable the device to generate maximum number-reaching alarms and their clear alarms, the
following situations occur:
– If the number of used CSPF resources reaches the maximum number of CSPF resources
supported by a device, a maximum number-reaching alarm is generated.
– If the number of used CSPF resources falls to 95% or below of the maximum number of CSPF
resources supported by a device, a clear alarm is generated.
----End
5.23.5 Clearing the Operation Information
Context
Cleared statistics cannot be restored. Exercise caution when you use the command.

Procedure
l Run the reset mpls rsvp-te statistics { global | interface [ interface-type interface-
number ] } command in the user view to clear statistics about RSVP-TE.
l Run the reset mpls stale-interface [ interface-index ] command in the user view to
delete the information about MPLS interfaces in the Stale state.
----End
5.23.6 Checking Information About TE

Context
To check TE information during routine maintenance, run the following display commands in
any view.
Procedure
l Run the display default-parameter mpls te management command to check default
parameters of MPLS TE management.
check tunnel statistics.
l Run the display mpls te tunnel-interface last-error [ tunnel-name ] command to check
information about tunnel faults.
l Run the display mpls te tunnel-interface failed command to check MPLS TE tunnels
that fail to be established or are being established.
l Run the display mpls te tunnel-interface traffic-state [ tunnel-name ] command to
check traffic on the tunnel interface of the local node.
statistics.
----End
5.23.7 Resetting the Tunnel Interface

Context
To make the tunnel-related configuration take effect, you can run the mpls te commit
command in the tunnel interface view and run the reset command in the user view.
NOTE
If the configuration is modified in the interface view of the TE tunnel but the mpls te commit command
is not configured, the system cannot execute the reset mpls te tunnel-interface tunnel command to re-
establish the tunnel.
Procedure
Step 1 Run the reset mpls te tunnel-interface tunnel interface-number command to reset the tunnel
interface.
----End

5.23.8 Resetting the RSVP Process
Context
Resetting the RSVP process results in the release and reestablishment of all RSVP CR-LSPs.
To reestablish all RSVP CR-LSPs or verify the operation process of RSVP, run the following
reset command in the user view.
Procedure
l Run the reset mpls rsvp-te command to reset the RSVP process.
----End
5.23.9 Deleting or Resetting the Bypass Tunnel
Context
In a scenario where auto TE FRR is used, you can run the following reset command to release
or re-establish bypass tunnels.
Procedure
l Run the reset mpls te auto-frr { lsp-id ingress-lsr-id tunnel-id | name bypass-tunnel-
name } command to delete or reset the auto FRR bypass tunnel.
----End
5.24 Configuration Examples for MPLS TE
5.24.1 Example for Configuring a Static MPLS TE Tunnel
Networking Requirements
As shown in Figure 5-35, static TE tunnels from LSRA to LSRC and from LSRC to LSRA
need to be set up.
Figure 5-35 Networking of static MPLS TE tunnels

Loopback1 Loopback1 Loopback1
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE0/0/1 GE0/0/1 GE0/0/2 GE0/0/1
VLANIF100 VLANIF100 VLANIF200 VLANIF200
172.1.1.1/24 172.1.1.2/24 172.2.1.1/24 172.2.1.2/24
LSRA LSRB LSRC

Configuration Roadmap
The configuration roadmap is as follows:
1. Assign an IP address to each interface on each LSR and configure OSPF to ensure that
there are reachable routes between LSRs.
2. Configure an ID for each LSR and globally enable MPLS and MPLS TE on each LSR
and interface.
3. Create a tunnel interface on the ingress node and set the tunnel type to static CR-LSP.
4. Configure the static LSP bound to the tunnel; specify the next hop address and outgoing
label on the ingress node; specify the inbound interface, incoming label, next hop
address, and outgoing label on the transit node; specify the incoming label and inbound
interface on the egress node.
NOTE
l The value of the outgoing label of each node is the value of the incoming label of its next node.
l When running the static-cr-lsp ingress { tunnel-interface tunnel interface-number | tunnel-name }
destination destination-address { nexthop next-hop-address | outgoing-interface interface-type
interface-number } * out-label out-label command to configure the ingress node of a CR-LSP,
ensure that tunnel-name must be the same as the tunnel name created by using the interface tunnel
interface-number command. tunnel-name is a case-sensitive character string without spaces. For
example, the name of the tunnel created by using the interface tunnel 1 command is Tunnel1. In
this case, the parameter of the ingress node of the static CR-LSP is Tunnel1; otherwise, the tunnel
cannot be created. There is no such limitation on the transit node and egress node.
Procedure
Step 1 Configure an IP address and routing protocol for each interface.
# Configure LSRA. Configure IP addresses for interfaces of LSRB and LSRC and OSPF
according to Figure 5-35. The configurations of LSRB and LSRC are similar to the
configuration of LSRA, and are not mentioned here.
<HUAWEI> system-view
[HUAWEI] sysname LSRA
[LSRA] vlan batch 100
[LSRA] interface vlanif 100
[LSRA-Vlanif100] ip address 172.1.1.1 255.255.255.0
[LSRA-Vlanif100] quit
[LSRA] interface gigabitethernet 0/0/1
[LSRA-GigabitEthernet0/0/1] port link-type trunk
[LSRA-GigabitEthernet0/0/1] port trunk allow-pass vlan 100
[LSRA-GigabitEthernet0/0/1] quit
[LSRA] interface loopback 1
[LSRA-LoopBack1] ip address 1.1.1.9 255.255.255.255
[LSRA-LoopBack1] quit
[LSRA] ospf 1
[LSRA-ospf-1] area 0
[LSRA-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[LSRA-ospf-1-area-0.0.0.0] quit
[LSRA-ospf-1] quit
After the configurations are complete, OSPF neighbor relationships can be set up between
LSRA, LSRB, and LSRC. Run the display ospf peer command. You can see that the
neighbor status is Full. Run the display ip routing-table command. You can see that LSRs
have learnt the routes to Loopback1 of each other.

Step 2 Configure basic MPLS functions and enable MPLS TE.

# Configure LSRA. The configurations of LSRB and LSRC are similar to the configuration of
LSRA, and are not mentioned here.
[LSRA] mpls lsr-id 1.1.1.9
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
[LSRA-Vlanif100] mpls
[LSRA-Vlanif100] mpls te
Step 3 Configure MPLS TE tunnels.

# On LSRA, create an MPLS TE tunnel from LSRA to LSRC.
[LSRA] interface tunnel 1
[LSRA-Tunnel1] ip address unnumbered interface loopback 1
[LSRA-Tunnel1] tunnel-protocol mpls te
[LSRA-Tunnel1] destination 3.3.3.9
[LSRA-Tunnel1] mpls te tunnel-id 100
[LSRA-Tunnel1] mpls te signal-protocol cr-static
[LSRA-Tunnel1] mpls te commit
[LSRA-Tunnel1] quit
# On LSRC, create an MPLS TE tunnel from LSRC to LSRA.

[LSRC] interface tunnel 1
[LSRC-Tunnel1] ip address unnumbered interface loopback 1
[LSRC-Tunnel1] tunnel-protocol mpls te
[LSRC-Tunnel1] destination 1.1.1.9
[LSRC-Tunnel1] mpls te tunnel-id 200
[LSRC-Tunnel1] mpls te signal-protocol cr-static
[LSRC-Tunnel1] mpls te commit
[LSRC-Tunnel1] quit
Step 4 Create a static CR-LSP from LSRA to LSRC.

# Configure LSRA as the ingress node of the static CR-LSP.
[LSRA] static-cr-lsp ingress tunnel-interface Tunnel1 destination 3.3.3.9 nexthop
172.1.1.2 out-label 20
# Configure LSRB as the transit node of the static CR-LSP.

[LSRB] static-cr-lsp transit LSRA2LSRC incoming-interface vlanif 100 in-label 20
nexthop 172.2.1.2 out-label 30
# Configure LSRC as the egress node of the static CR-LSP.

[LSRC] static-cr-lsp egress LSRA2LSRC incoming-interface vlanif 200 in-label 30
Step 5 Create a static CR-LSP from LSRC to LSRA.

# Configure LSRC as the ingress node of the static CR-LSP.
[LSRC] static-cr-lsp ingress tunnel-interface Tunnel1 destination 1.1.1.9 nexthop
172.2.1.1 out-label 120
# Configure LSRB as the transit node of the static CR-LSP.

[LSRB] static-cr-lsp transit LSRC2LSRA incoming-interface vlanif 200 in-label 120
nexthop 172.1.1.1 out-label 130
# Configure LSRA as the egress node of the static CR-LSP.

[LSRA] static-cr-lsp egress LSRC2LSRA incoming-interface vlanif 100 in-label 130

Step 6 Verify the configuration.

After the configurations are complete, run the display interface tunnel command on LSRA.
You can see that the tunnel interface status is Up.
The display on LSRA is used as an example.
[LSRA] display interface tunnel 1
Tunnel1 current state : UP
Line protocol current state : UP
...
Run the display mpls te tunnel command on each LSR to view the MPLS TE tunnel status.
[LSRA] display mpls te tunnel
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
1.1.1.9 3.3.3.9 1 --/20 I Tunnel1
- - - 130/-- E LSRC2LSRA
Run the display mpls lsp or display mpls static-cr-lsp command on each LSR to view the
static CR-LSP status.
[LSRA] display mpls static-cr-lsp
TOTAL : 2 STATIC CRLSP(S)
UP : 2 STATIC CRLSP(S)
DOWN : 0 STATIC CRLSP(S)
Name FEC I/O Label I/O If Status
Tunnel1 3.3.3.9/32 NULL/20 -/Vlanif100 Up
LSRC2LSRA -/- 130/NULL Vlanif100/- Up
When a static CR-LSP is used to establish an MPLS TE tunnel, the transit node and the egress
node do not forward packets according to the specified incoming label and outgoing label.
Therefore, no EFC information is displayed on LSRB or LSRC.
----End
Configuration Files
l LSRA configuration file
#
sysname LSRA
#
vlan batch 100
#
mpls lsr-id 1.1.1.9
mpls
mpls te
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
#
interface GigabitEthernet0/0/1
port link-type trunk
port trunk allow-pass vlan 100
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#

interface Tunnel1
ip address unnumbered interface LoopBack1
tunnel-protocol mpls te
destination 3.3.3.9
mpls te signal-protocol cr-static
mpls te tunnel-id 100
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
static-cr-lsp ingress tunnel-interface Tunnel1 destination 3.3.3.9 nexthop
172.1.1.2 out-label 20 bandwidth ct0 0
static-cr-lsp egress LSRC2LSRA incoming-interface Vlanif100 in-label 130
#
return
l LSRB configuration file
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
static-cr-lsp transit LSRA2LSRC incoming-interface Vlanif100 in-label 20
nexthop 172.2.1.2 out-label 30 bandwidth ct0 0
static-cr-lsp transit LSRC2LSRA incoming-interface Vlanif200 in-label 120
nexthop 172.1.1.1 out-label 130 bandwidth ct0 0
#
return
l LSRC configuration file
#
sysname LSRC
#
vlan batch 200
#
mpls lsr-id 3.3.3.9

mpls
mpls te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
interface Tunnel1
destination 1.1.1.9
mpls te signal-protocol cr-static
mpls te commit
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
#
static-cr-lsp egress LSRA2LSRC incoming-interface Vlanif200 in-label 30
static-cr-lsp ingress tunnel-interface Tunnel1 destination 1.1.1.9 nexthop
172.2.1.1 out-label 120 bandwidth ct0 0
#
return
5.24.2 Example for Configuring a Dynamic MPLS TE Tunnel
As shown in Figure 5-36, an enterprise establishes its own MPLS backbone network with
LSRA, LSRB, and LSRC deployed. The MPLS backbone network uses IS-IS, and LSRA,
LSRB, and LSRC are level-2 devices. A tunnel needs to be set up over the public network on
the MPLS backbone network to transmit L2VPN or L3VPN services, and the tunnel must be
able to adapt to network topology changes to ensure stable data transmission.
RSVP-TE is used to establish a dynamic MPLS TE tunnel.
Figure 5-36 Networking of a dynamic MPLS TE tunnel

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE0/0/1 GE0/0/1 GE0/0/2 GE0/0/1
172.1.1.1/24 172.1.1.2/24 172.2.1.1/24 172.2.1.2/24
LSRA LSRB LSRC

1. On the MPLS backbone network, MPLS LDP and MPLS TE tunnels can carry L2VPN
or L3VPN services. Configure an MPLS TE tunnel to ensure stable data transmission
upon frequent topology changes on the enterprise network.
2. Configure IS-IS to ensure that there are reachable routes between devices on the MPLS
backbone network.
3. Enable MPLS TE and RSVP-TE on each node so that an MPLS TE tunnel can be set up.
4. Enable IS-IS TE and change the cost type so that TE information can be advertised to
other nodes through IS-IS.
5. Create a tunnel interface on the ingress node, configure tunnel attributes, and enable
MPLS TE CSPF to create a dynamic MPLS TE tunnel.
Procedure
Step 1 Assign IP addresses to interfaces.
# Configure LSRA. Configure IP addresses for interfaces of LSRB and LSRC according to
Figure 5-36. The configurations of LSRB and LSRC are similar to the configuration of
Step 2 Configure IS-IS to advertise routes.

# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] network-entity 00.0005.0000.0000.0001.00
[LSRA-isis-1] is-level level-2
[LSRA-isis-1] quit
[LSRA-Vlanif100] isis enable 1
[LSRA-LoopBack1] isis enable 1
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] network-entity 00.0005.0000.0000.0002.00
[LSRB-isis-1] is-level level-2
[LSRB-isis-1] quit
[LSRB] interface vlanif 100
[LSRB-Vlanif100] isis enable 1
[LSRB-Vlanif100] quit
[LSRB] interface loopback 1
[LSRB-LoopBack1] isis enable 1
[LSRB-LoopBack1] quit

# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] network-entity 00.0005.0000.0000.0003.00
[LSRC-isis-1] is-level level-2
[LSRC-isis-1] quit
[LSRC] interface vlanif 200
[LSRC-Vlanif200] isis enable 1
[LSRC-Vlanif200] quit
[LSRC] interface loopback 1
[LSRC-LoopBack1] isis enable 1
[LSRC-LoopBack1] quit
After the configurations are complete, run the display ip routing-table command on each
LSR. You can see that the LSRs have learned the routes from each other. The display on
LSRA is used as an example.
[LSRA] display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.9/32 Direct 0 0 D 127.0.0.1 LoopBack1

2.2.2.9/32 ISIS-L2 15 10 D 172.1.1.2 Vlanif100
3.3.3.9/32 ISIS-L2 15 20 D 172.1.1.2 Vlanif100
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 ISIS-L2 15 20 D 172.1.1.2 Vlanif100
Step 3 Configure basic MPLS functions and enable MPLS TE and RSVP-TE.
Enable MPLS, MPLS TE, and RSVP-TE globally on each node and interfaces along the
tunnel.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] mpls rsvp-te
[LSRA-mpls] quit
[LSRA-Vlanif100] mpls rsvp-te
Step 4 Configure IS-IS TE.

[LSRA] isis 1
[LSRA-isis-1] cost-style wide
[LSRA-isis-1] traffic-eng level-2
[LSRA-isis-1] quit
Step 5 Configure an MPLS TE tunnel interface and enable MPLS TE CSPF.

# On the ingress node of the tunnel, create a tunnel interface, and set the IP address, tunnel
protocol, destination IP address, tunnel ID, and dynamic signaling protocol for the tunnel
interface. Then run the mpls te commit command to commit the configuration.

# Configure LSRA.
[LSRA-Tunnel1] mpls te signal-protocol rsvp-te
[LSRA-Tunnel1] quit
[LSRA] mpls
[LSRA-mpls] mpls te cspf
[LSRA-mpls] quit

[LSRA] display interface tunnel
Last line protocol up time : 2013-01-14 09:18:46
Description:
...
Run the display mpls te tunnel-interface command on LSRA. You can view tunnel interface
information.
[LSRA] display mpls te tunnel-interface
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------
Tunnel State Desc : UP
Active LSP : Primary LSP
Session ID : 100
Ingress LSR ID : 1.1.1.9 Egress LSR ID: 3.3.3.9
Admin State : UP Oper State : UP
Primary LSP State : UP
Main LSP State : READY LSP ID : 3
Run the display mpls te tunnel verbose command on LSRA. You can view detailed
information about the tunnel.
[LSRA] display mpls te tunnel verbose
No : 1
Tunnel-Name : Tunnel1
Tunnel Interface Name : Tunnel1
TunnelIndex : 1 LSP Index : 2048
Session ID : 100 LSP ID : 3
LSR Role : Ingress LSP Type : Primary
Ingress LSR ID : 1.1.1.9
Egress LSR ID : 3.3.3.9
In-Interface : -
Out-Interface : Vlanif100
Sign-Protocol : RSVP TE Resv Style : SE
IncludeAnyAff : 0x0 ExcludeAnyAff : 0x0
IncludeAllAff : 0x0
LspConstraint : -
ER-Hop Table Index : - AR-Hop Table Index: -
C-Hop Table Index : -
PrevTunnelIndexInSession: - NextTunnelIndexInSession: -
PSB Handle : 16388
Created Time : 2013-09-16 11:51:21+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
Bandwidth Reserved Flag : Unreserved

CT0 Bandwidth(Kbit/sec) : 0 CT1 Bandwidth(Kbit/sec): 0

Setup-Priority : 7 Hold-Priority : 7
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
TE Attribute Flag : 0x3 Protected Flag : 0x0
Bypass In Use : Not Exists
Bypass Tunnel Id : -
BypassTunnel : -
Bypass LSP ID : - FrrNextHop : -
ReferAutoBypassHandle : -
FrrPrevTunnelTableIndex : - FrrNextTunnelTableIndex: -
Bypass Attribute(Not configured)
Setup Priority : - Hold Priority : -
HopLimit : - Bandwidth : -
IncludeAnyGroup : - ExcludeAnyGroup : -
IncludeAllGroup : -
Bypass Unbound Bandwidth Info(Kbit/sec)
CT0 Unbound Bandwidth : - CT1 Unbound Bandwidth: -
--------------------------------
BFD Information
--------------------------------
NextSessionTunnelIndex : - PrevSessionTunnelIndex: -
NextLspId : - PrevLspId : -
Run the display mpls te cspf tedb all command on LSRA. You can view link information in
the TEDB.
[LSRA] display mpls te cspf tedb all
Maximum Nodes Supported: 512 Current Total Node Number: 3
Maximum Links Supported: 2048 Current Total Link Number: 4
Maximum SRLGs supported: 5120 Current Total SRLG Number: 0
ID Router-ID IGP Process-ID Area Link-Count
1 1.1.1.9 ISIS 1 Level-2 1
2 2.2.2.9 ISIS 1 Level-2 2
3 3.3.3.9 ISIS 1 Level-2 1
----End
Configuration Files
#
sysname LSRA
#
vlan batch 100
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
interface Vlanif100

ip address 172.1.1.1 255.255.255.0

isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.9
mpls te commit
#
return

#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
vlan batch 200
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
5.24.3 Example for Setting Up CR-LSPs Using CR-LSP Attribute

Templates
As shown in Figure 5-37, an MPLS TE tunnel is set up between LSRA and LSRC. The
primary path of the tunnel is LSRA -> LSRB -> LSRC. When the primary CR-LSP fails,
traffic must be switched to a backup CR-LSP.
LSRA needs to set up multiple MPLS TE tunnels to meet service requirements. The network
administrator wants to simplify the MPLS TE tunnel configuration.
NOTE
In this scenario, to avoid loops, ensure that all connected interfaces have STP disabled and connected
interfaces are removed from VLAN 1. If STP is enabled and VLANIF interfaces of switches are used to
construct a Layer 3 ring network, an interface on the network will be blocked. As a result, Layer 3
services on the network cannot run normally.

Figure 5-37 Networking of CR-LSP setup using CR-LSP attribute templates

Loopback1
6.6.6.9/32
GE0/0/1 GE0/0/2
VLANIF600 VLANIF700
172.6.1.2/24 172.7.1.1/24
LSRF
GE0/0/2 GE0/0/3
VLANIF600 VLANIF700
172.6.1.1/24 Loopback1 172.7.1.2/24
Loopback1 2.2.2.9/32 Loopback1
GE0/0/1 GE0/0/2
1.1.1.9/32 VLANIF100 VLANIF200 3.3.3.9/32
172.1.1.2/24 172.2.1.1/24
LSRA LSRC
GE0/0/1 GE0/0/1
VLANIF100 VLANIF200
GE0/0/3 LSRB GE0/0/2
172.1.1.1/24 172.2.1.2/24
VLANIF400 VLANIF500
172.4.1.1/24 172.5.1.2/24
Loopback1
5.5.5.9/32
GE0/0/1 GE0/0/2
VLANIF400 VLANIF500
172.4.1.2/24 172.5.1.1/24
LSRE
Primary CR-LSP
1. Assign IP addresses to interfaces and configure OSPF to ensure that public network
routes between the nodes are reachable.
2. Configure LSR IDs for the nodes, enable MPLS, MPLS TE, RSVP-TE, and CSPF on the
LSRs globally and on their interfaces, and enable OSPF TE on the LSRs.
3. Use CR-LSP attribute templates to simplify the configuration. Configure different
attribute templates for the primary CR-LSP, hot-standby CR-LSP, and ordinary backup
CR-LSP.
4. On the ingress node of the primary tunnel, create a tunnel interface, configure the tunnel
IP address, tunneling protocol, destination IP address, tunnel ID, and RSVP-TE signaling
protocol for the tunnel interface, and then apply the corresponding CR-LSP attribute
template to set up the primary CR-LSP.
5. Configure hot-standby and ordinary backup CR-LSPs on the ingress node of the primary
tunnel. In this way, traffic can be switched to the backup CR-LSP when the primary CR-
LSP fails. Apply the CR-LSP corresponding attribute template to create the backup CR-
LSP.
Procedure
Step 1 Assign IP addresses to interfaces and configure OSPF on the LSRs.

# Configure LSRA. Assign IP addresses to interfaces of LSRB, LSRC, LSRE, and LSRF
according to Figure 5-37. The configurations on these LSRs are similar to the configuration
on LSRA, and are not mentioned here.
[LSRA] vlan batch 100 400 600
[LSRA] ospf 1
[LSRA-ospf-1] quit
After the configurations are complete, run the display ip routing-table command on the
LSRs. You can see that the LSRs learn the routes of Loopback1 from each other. The
command output on LSRA is provided as an example:
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 172.1.1.2 Vlanif100
3.3.3.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
OSPF 10 2 D 172.4.1.2 Vlanif400
OSPF 10 2 D 172.6.1.2 Vlanif600
5.5.5.9/32 OSPF 10 1 D 172.4.1.2 Vlanif400
6.6.6.9/32 OSPF 10 1 D 172.6.1.2 Vlanif600
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.4.1.0/24 Direct 0 0 D 172.4.1.1 Vlanif400
172.4.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif400
172.5.1.0/24 OSPF 10 2 D 172.4.1.2 Vlanif400
172.6.1.0/24 Direct 0 0 D 172.6.1.1 Vlanif600

172.6.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif600

172.7.1.0/24 OSPF 10 2 D 172.6.1.2 Vlanif600
Step 2 Configure basic MPLS capabilities and enable MPLS TE, RSVP-TE, and CSPF.
# Configure LSRA. The configurations on LSRB, LSRC, LSRE, and LSRF are similar to the
configuration on LSRA, and are not mentioned here. CSPF needs to be enabled only on the
ingress node of the primary tunnel.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
Step 3 Configure OSPF TE.
# Configure LSRA. The configurations on LSRB, LSRC, LSRE, and LSRF are similar to the
configuration on LSRA, and are not mentioned here.
[LSRA] ospf
[LSRA-ospf-1] opaque-capability enable
[LSRA-ospf-1-area-0.0.0.0] mpls-te enable
[LSRA-ospf-1] quit
Step 4 Configure CR-LSP attribute templates and specify explicit paths for the CR-LSPs.
# Specify an explicit path for the primary CR-LSP.

[LSRA] explicit-path pri-path
[LSRA-explicit-path-pri-path] next hop 172.1.1.2
[LSRA-explicit-path-pri-path] quit
# Specify an explicit path for the hot-standby CR-LSP.

[LSRA] explicit-path hotstandby-path
[LSRA-explicit-path-hotstandby-path] next hop 172.4.1.2
[LSRA-explicit-path-hotstandby-path] quit
# Specify an explicit path for the ordinary backup CR-LSP.

[LSRA] explicit-path ordinary-path
[LSRA-explicit-path-ordinary-path] next hop 172.6.1.2
[LSRA-explicit-path-ordinary-path] quit

# Configure the CR-LSP attribute template used for setting up the primary CR-LSP.
[LSRA] lsp-attribute lsp_attribute_pri
[LSRA-lsp-attribute-lsp_attribute_pri] explicit-path pri-path
[LSRA-lsp-attribute-lsp_attribute_pri] commit
[LSRA-lsp-attribute-lsp_attribute_pri] quit
# Configure the CR-LSP attribute template used for setting up the hot-standby CR-LSP.
[LSRA] lsp-attribute lsp_attribute_hotstandby
[LSRA-lsp-attribute-lsp_attribute_hotstandby] explicit-path hotstandby-path
[LSRA-lsp-attribute-lsp_attribute_hotstandby] hop-limit 12
[LSRA-lsp-attribute-lsp_attribute_hotstandby] commit
[LSRA-lsp-attribute-lsp_attribute_hotstandby] quit
# Configure the CR-LSP attribute template used for setting up the ordinary backup CR-LSP.
[LSRA] lsp-attribute lsp_attribute_ordinary
[LSRA-lsp-attribute-lsp_attribute_ordinary] explicit-path ordinary-path
[LSRA-lsp-attribute-lsp_attribute_ordinary] hop-limit 15
[LSRA-lsp-attribute-lsp_attribute_ordinary] commit
[LSRA-lsp-attribute-lsp_attribute_ordinary] quit
Step 5 On the ingress node LSRA, create the MPLS TE tunnel on the primary CR-LSP.
# Specify an MPLS TE tunnel interface for the primary CR-LSP and apply the primary CR-
LSP attribute template to set up this CR-LSP.
[LSRA-Tunnel1] ip address unnumbered interface loopBack 1
[LSRA-Tunnel1] mpls te primary-lsp-constraint lsp-attribute lsp_attribute_pri
[LSRA-Tunnel1] quit
Run the display interface tunnel 1 command on LSRA to check the tunnel status. The tunnel
is in Up state.
Description:
...
Step 6 Configure hot-standby and common backup CR-LSPs on the ingress node.
# On LSRA, apply CR-LSP attribute templates to create hot-standby and common backup
CR-LSPs.
[LSRA-Tunnel1] mpls te hotstandby-lsp-constraint 1 lsp-attribute
lsp_attribute_hotstandby
[LSRA-Tunnel1] mpls te ordinary-lsp-constraint 1 lsp-attribute
lsp_attribute_ordinary
[LSRA-Tunnel1] quit
Run the display mpls te tunnel-interface command on LSRA to check tunnel information.
You can see that the hot-standby CR-LSP has been set up successfully.
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------


Session ID : 100
Hot-Standby LSP State : UP

Run the display mpls te tunnel-interface lsp-constraint command on LSRA to view the
configurations of the CR-LSP attribute templates.
[LSRA] display mpls te tunnel-interface lsp-constraint
Tunnel Name : Tunnel1
Primary-lsp-constraint Name : lsp_attribute_pri
Hotstandby-lsp-constraint Number: 1
Hotstandby-lsp-constraint Name : lsp_attribute_hotstandby
Ordinary-lsp-constraint Number : 1
Ordinary-lsp-constraint Name : lsp_attribute_ordinary
# Run the display mpls te tunnel verbose command on LSRA to view detailed tunnel
information. You can see that the primary and hot-standby CR-LSPs have been set up using
the attribute templates.
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : 1
ER-Hop Table Index : 0 AR-Hop Table Index: 0
C-Hop Table Index : 1
PrevTunnelIndexInSession: 2 NextTunnelIndexInSession: -
PSB Handle : 8194
Created Time : 2013-09-16 14:53:15+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -


IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
No : 2
LSR Role : Ingress LSP Type : Hot-Standby
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : 1
PrevTunnelIndexInSession: - NextTunnelIndexInSession: 1
PSB Handle : 8195
Created Time : 2013-09-16 14:53:15+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------

# Run the shutdown command on GE0/0/1 and GE0/0/3 of LSRA.

[LSRA-GigabitEthernet0/0/1] shutdown
# Run the display mpls te tunnel verbose command on LSRA. You can see that an ordinary
CR-LSP has been set up using the attribute template.
No : 1
LSR Role : Ingress LSP Type : Ordinary
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : 1
PSB Handle : 8196
Created Time : 2013-09-16 15:00:08+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------

----End
Configuration File
#
sysname LSRA
#
vlan batch 100 400 600
#
mpls lsr-id
1.1.1.9
mpls
mpls
te
mpls rsvp-
te
mpls te cspf
#
explicit-path hotstandby-path
next hop 172.4.1.2
next hop 172.5.1.2
next hop 3.3.3.9
#
explicit-path ordinary-path
next hop 172.6.1.2
next hop 172.7.1.2
next hop 3.3.3.9
#
explicit-path pri-path
next hop 172.1.1.2
next hop 172.2.1.2
next hop 3.3.3.9
#
lsp-attribute lsp_attribute_hotstandby
explicit-path hotstandby-path
hop-limit 12
commit
#
lsp-attribute lsp_attribute_ordinary
explicit-path ordinary-path
hop-limit 15
commit
#
lsp-attribute lsp_attribute_pri
commit
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.1 255.255.255.0
mpls

mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
destination 3.3.3.9
mpls te primary-lsp-constraint lsp-attribute lsp_attribute_pri
mpls te hotstandby-lsp-constraint 1 lsp-attribute lsp_attribute_hotstandby
mpls te ordinary-lsp-constraint 1 lsp-attribute lsp_attribute_ordinary
mpls te record-route
mpls te commit
#
ospf 1
opaque-capability enable
area 0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255
network 172.6.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#


#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255

network 172.5.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255
mpls-te enable
#
return
l LSRE configuration file
#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9
0.0.0.0
network 172.4.1.0
0.0.0.255
network 172.5.1.0 0.0.0.255
mpls-te enable
#
return
l LSRF configuration file
#
sysname LSRF
#
vlan batch 600 700
#
mpls lsr-id 6.6.6.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#

interface Vlanif700
ip address 172.7.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 6.6.6.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 6.6.6.9
0.0.0.0
network 172.6.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255
mpls-te enable
#
return
5.24.4 Example for Configuring IGP Shortcut to Direct Traffic to

an MPLS TE Tunnel
An MPLS TE tunnel does not automatically direct traffic. To direct traffic to an MPLS TE
tunnel, configure Interior Gateway Protocol (IGP) shortcut. IGP shortcut enables a device to
use a TE tunnel as a logical link for IGP route calculation. You can set a proper metric for an
MPLS TE tunnel to ensure that the route passing through the MPLS TE tunnel is preferred,
allowing traffic to be directed to the MPLS TE tunnel.
As shown in Figure 5-38, devices use OSPF to communicate with each other. An MPLS TE
tunnel is established from LSRA and LSRC. The MPLS TE tunnel passes through LSRB. The
number marked on each link indicates the link cost. If LSRA has traffic destined for LSRE
and LSRC, LSRA sends the traffic to GE0/0/2 based on the OSPF route selection result. If the
link between LSRA and LSRD has 100 Mbit/s of bandwidth and LSRA requires 50 Mbit/s
bandwidth to send traffic to LSRC and 60 Mbit/s bandwidth to send traffic to LSRE, the link
between LSRA and LSRB is congested. Congestion on the link causes traffic transmission
delay or packet loss.
To resolve this problem, configure IGP shortcut on the tunnel interface of LSRA to direct
traffic destined for LSRC to the MPLS TE tunnel. By doing this, traffic is forwarded by
GE0/0/1 and network congestion is prevented.
NOTE
After IGP shortcut is configured on the tunnel interface of LSRA, LSRA does not advertise the MPLS
TE tunnel to its peers as a route. The MPLS TE tunnel is used only for local route calculation.

NOTE
Figure 5-38 Networking of IGP shortcut

GE0/0/3 GE0/0/1
GE0/0/2 LSRD VLANIF500 VLANIF500 LSRE
VLANIF400 172.5.1.1/24 172.5.1.2/24
172.4.1.2/24 10
GE0/0/1
10 VLANIF300
LSRA GE0/0/2
172.3.1.2/24
VLANIF400
Loopback1 172.4.1.1/24 10
1.1.1.9/32 TE Metric=10
GE0/0/1 15
VLANIF100 GE0/0/2
172.1.1.1/24 VLANIF300
LSRB 172.3.1.1/24
GE0/0/1 10
VLANIF100 LSRC
GE0/0/2 GE0/0/1
172.1.1.2/24
VLANIF200 VLANIF200
Loopback1 172.2.1.1/24 172.2.1.2/24 Loopback1
2.2.2.9/32 3.3.3.9/32
1. Assign an IP address to each interface, configure OSPF to ensure that there are reachable
routes between LSRs, and configure the OSPF cost.
2. On LSRA, create an MPLS TE tunnel over the path LSRA -> LSRB -> LSRC. This
example uses RSVP-TE to establish a dynamic MPLS TE tunnel. Configure an ID for
each LSR, enable MPLS TE, RSVP-TE, and CSPF on each node and interface, and
enable OSPF TE. On the ingress node of the primary tunnel, create a tunnel interface,
and specify the IP address, tunneling protocol, destination IP address, tunnel ID, and
dynamic signaling protocol RSVP-TE for the tunnel interface.
3. Enable IGP shortcut on the TE tunnel interface of LSRA and configure an IGP metric for
the TE tunnel.
Procedure
Step 1 Assign an IP address to each interface, configure OSPF, and set the OSPF cost.
# Configure LSRA. Configure IP addresses for interfaces of LSRB, LSRC, LSRD, and LSRE
according to Figure 5-38. The configurations on LSRB, LSRC, LSRD, and LSRE are similar
to the configuration of LSRA, and are not mentioned here.

[LSRA] vlan batch 100 400

[LSRA-Vlanif100] ospf cost 15
[LSRA] ospf 1
[LSRA-ospf-1] quit
After the configurations are complete, run the display ip routing-table command on LSRA,
LSRB, and LSRC. You can see that PE1 and PE2 have learned the routes to Loopback1 of
each other.
Step 2 Configure basic MPLS functions and enable MPLS TE, RSVP-TE, and CSPF.
To set up a TE tunnel from LSRA to LSRC, perform the following configurations on LSRA,
LSRB, and LSRC.
# Configure LSRA. The configurations on LSRB and LSRC are similar to the configuration
of LSRA, and are not mentioned here. CSPF only needs to be configured on the ingress node
of the primary tunnel.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

To set up a TE tunnel from LSRA to LSRC, perform the following configurations on LSRA,
LSRB, and LSRC.
of LSRA, and are not mentioned here.
[LSRA] ospf
[LSRA-ospf-1] quit

Step 4 Create an MPLS TE tunnel.

# Specify an explicit path for a TE tunnel.
# Create a tunnel interface on LSRA.

[LSRA-Tunnel1] mpls te path explicit-path pri-path
[LSRA-Tunnel1] quit
Step 5 Configure IGP shortcut.

Enable IGP shortcut on the TE tunnel interface of LSRA and set the IGP metric to 10 for the
TE tunnel.
# Configure LSRA.
[LSRA-Tunnel1] mpls te igp shortcut ospf
[LSRA-Tunnel1] mpls te igp metric absolute 10
[LSRA-Tunnel1] quit
[LSRA] ospf 1
[LSRA-ospf-1] enable traffic-adjustment
[LSRA-ospf-1] quit

After the configurations are complete, run the display ip routing-table 3.3.3.9 command on
LSRA. You can see that the next hop address of the route destined for LSRC (3.3.3.9) is
1.1.1.9 and the outbound interface of this route is Tunnel1. The traffic destined for LSRC has
been directed to the MPLS TE tunnel.
[LSRA] display ip routing-table 3.3.3.9
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
3.3.3.9/32 OSPF 10 10 D 1.1.1.9 Tunnel1
----End
Configuration Files
#
sysname LSRA
#
vlan batch 100 400
#
mpls lsr-id
1.1.1.9
mpls

mpls
te
mpls rsvp-
te
mpls te cspf
#
explicit-path pri-
path
next hop
172.1.1.2
next hop
172.2.1.2
next hop 3.3.3.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
ospf cost 15
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
ospf cost 10
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
ip address unnumbered interface
LoopBack1
tunnel-protocol mpls
te
destination
3.3.3.9
mpls te tunnel-id
100
mpls te path explicit-path pri-
path
mpls te igp shortcut
ospf
mpls te igp metric absolute
10
mpls te commit
#
ospf
1
opaque-capability
enable
enable traffic-adjustment
area
0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255
mpls-te enable

#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
ospf cost 15
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
ospf cost 10
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
vlan batch 200 300
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
ospf cost 10
mpls
mpls te
mpls rsvp-te
#

interface Vlanif300
ip address 172.3.1.1 255.255.255.0
ospf cost 10
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0
0.0.0.255
mpls-te enable
#
return
l LSRD configuration file
#
sysname LSRD
#
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
ospf cost 10
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
ospf cost 10
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
ospf cost 10
#
#
#
#
ospf 1
area 0.0.0.0
network 172.3.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
network 172.5.1.0 0.0.0.255
#
return
#
sysname LSRE
#

vlan batch 500

#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
ospf cost 10
#
#
ospf 1
area 0.0.0.0
network 172.5.1.0 0.0.0.255
#
return
5.24.5 Example for Configuring Forwarding Adjacency to Direct

Traffic to an MPLS TE Tunnel
An MPLS TE tunnel does not automatically direct traffic. To direct traffic to an MPLS TE
tunnel, configure forwarding adjacency. Forwarding adjacency enables a device to use a TE
tunnel as a logical link for IGP route calculation. Unlike IGP shortcut, forwarding adjacency
advertises a TE tunnel to its peers as an IGP route. You can set a proper metric for an MPLS
TE tunnel to ensure that the route passing through the MPLS TE tunnel is preferred, allowing
traffic to be directed to the MPLS TE tunnel.
As shown in Figure 5-39, devices use OSPF to communicate with each other. An MPLS TE
tunnel is established from LSRA and LSRC. The MPLS TE tunnel passes through LSRB. The
number marked on each link indicates the link cost. If LSRA and LSRE have traffic destined
for LSRC, traffic from the two LSRs is forwarded by GE0/0/1 on LSRD based on the OSPF
route selection result. If LSRA requires 10 Mbit/s bandwidth to send traffic to LSRC, and
LSRE requires 100 Mbit/s bandwidth to send traffic to LSRC, but the link between LSRC and
LSRD has only 100 Mbit/s of bandwidth, the link is congested. Congestion on the link causes
traffic transmission delay or packet loss.
To resolve this problem, configure forwarding adjacency on the MPLS TE tunnel interface of
LSRA. Then all traffic from LSRA to LSRC is forwarded over the MPLS TE tunnel, whereas
only some of traffic from LSRE to LSRC is forwarded over the MPLS TE tunnel. The rest of
traffic is forwarded by LSRD. Therefore, traffic congestion is prevented over the link between
LSRC and LSRD.
NOTE
After you configure forwarding adjacency, LSRA advertises the MPLS TE tunnel to its peer as an OSPF
route. Because OSPF requires bidirectional link detection, the MPLS TE tunnel from LSRC to LSRA
must be established and forwarding adjacency must be configured on the tunnel interface.
NOTE

Figure 5-39 Networking of forwarding adjacency

LSRE GE0/0/1 GE0/0/3 LSRD
VLANIF500 VLANIF500
172.5.1.2/24 172.5.1.1/24
10 GE0/0/1
GE0/0/2 VLANIF300
10 GE0/0/2
VLANIF600 10 172.3.1.2/24
GE0/0/3 VLANIF400
172.6.1.2/24
VLANIF600 172.4.1.2/24
GE0/0/2
172.6.1.1/24
VLANIF400
Loopback1 10
172.4.1.1/24
1.1.1.9/32 TE Metric=10
LSRA
GE0/0/1 15 GE0/0/2
VLANIF100 VLANIF300
172.1.1.1/24 LSRB
172.3.1.1/24
GE0/0/1 10
VLANIF100 LSRC
GE0/0/2 GE0/0/1
172.1.1.2/24
VLANIF200 VLANIF200
172.2.1.1/24 172.2.1.2/24
Loopback1 Loopback1
2.2.2.9/32 3.3.3.9/32
1. Assign an IP address to each interface, configure OSPF to ensure that there are reachable
routes between LSRs, and configure the OSPF cost.
2. On LSRA, create an MPLS TE tunnel over the path LSRA -> LSRB -> LSRC. On
LSRC, create an MPLS TE tunnel over the path LSRC -> LSRB -> LSRA. This example
uses RSVP-TE to establish a dynamic MPLS TE tunnel. Configure an ID for each LSR,
enable MPLS TE, RSVP-TE, and CSPF on each node and interface, and enable OSPF
TE. On the ingress node of the primary tunnel, create a tunnel interface, and specify the
IP address, tunneling protocol, destination IP address, tunnel ID, and dynamic signaling
protocol RSVP-TE for the tunnel interface.
3. Enable forwarding adjacency on the TE tunnel interfaces of LSRA and LSRC, and
configure the IGP metric for the TE tunnels.
Procedure
Step 1 Assign an IP address to each interface, configure OSPF, and set the OSPF cost.
according to Figure 5-39. The configurations on LSRB, LSRC, LSRD, and LSRE are similar


[LSRA] ospf 1
[LSRA-ospf-1] quit
After the configurations are complete, run the display ip routing-table command on LSRA,
LSRB, and LSRC. You can see that PE1 and PE2 have learned the routes to Loopback1
interfaces of each other.
To create TE tunnels on LSRA and LSRC, perform the following configurations on LSRA,
LSRB, and LSRC.
of LSRA, and are not mentioned here. CSPF only needs to be configured on the ingress node
of the primary tunnel.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

To create TE tunnels on LSRA and LSRC, perform the following configurations on LSRA,
LSRB, and LSRC.
of LSRA, and are not mentioned here.
[LSRA] ospf

[LSRA-ospf-1] quit
Step 4 Create an MPLS TE tunnel.

Create MPLS TE tunnel interfaces on LSRA and LSRC, and configure explicit paths.
# Configure LSRA.
[LSRA-Tunnel1] quit
# Configure LSRC.
[LSRC] explicit-path pri-path
[LSRC-explicit-path-pri-path] next hop 172.2.1.1
[LSRC-explicit-path-pri-path] quit
[LSRC-Tunnel1] ip address unnumbered interface loopback 1
[LSRC-Tunnel1] tunnel-protocol mpls te
[LSRC-Tunnel1] destination 1.1.1.9
[LSRC-Tunnel1] mpls te tunnel-id 101
[LSRC-Tunnel1] mpls te path explicit-path pri-path
[LSRC-Tunnel1] quit
Step 5 Configure forwarding adjacency.

Enable forwarding adjacency on the TE tunnel interface of LSRA and set the IGP metric to 10
for the TE tunnel.
# Configure LSRA.
[LSRA-Tunnel1] mpls te igp advertise
[LSRA-Tunnel1] mpls te igp metric absolute 10
[LSRA-Tunnel1] quit
[LSRA] ospf 1
[LSRA-ospf-1] enable traffic-adjustment advertise
[LSRA-ospf-1] quit
# Configure LSRC.
[LSRC-Tunnel1] mpls te igp advertise
[LSRC-Tunnel1] mpls te igp metric absolute 10
[LSRC-Tunnel1] quit
[LSRC] ospf 1
[LSRC-ospf-1] enable traffic-adjustment advertise
[LSRC-ospf-1] quit

After the configurations are complete, run the display ip routing-table 3.3.3.9 command on
LSRA. You can see that the next hop address of the route destined for LSRC (3.3.3.9) is
1.1.1.9 and the outbound interface of this route is Tunnel1. The traffic destined for LSRC has
been directed to the MPLS TE tunnel.
[LSRA] display ip routing-table 3.3.3.9
------------------------------------------------------------------------------
Summary Count : 1
3.3.3.9/32 OSPF 10 10 D 1.1.1.9 Tunnel1
Run the display ip routing-table 3.3.3.9 command on LSRE. You can see that there are two
equal-cost routes to LSRC (3.3.3.9). Some traffic destined for LSRC is forwarded by LSRD
and some traffic is sent to the LSRA and forwarded over the MPLS TE tunnel.
[LSRE] display ip routing-table 3.3.3.9
------------------------------------------------------------------------------
Summary Count : 2
3.3.3.9/32 OSPF 10 20 D 172.5.1.1 Vlanif500

OSPF 10 20 D 172.6.1.1 Vlanif600
----End
Configuration Files
#
sysname LSRA
#
#
mpls lsr-id
1.1.1.9
mpls
mpls
te
mpls rsvp-
te
mpls te cspf
#
explicit-path pri-
path
next hop
172.1.1.2
next hop
172.2.1.2
next hop 3.3.3.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
ospf cost 15
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
ospf cost 10

#
interface Vlanif600
ip address 172.6.1.1 255.255.255.0
ospf cost 10
#
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
LoopBack1
te
destination
3.3.3.9
mpls te tunnel-id
100
path
mpls te igp advertise
10
mpls te commit
#
ospf
1
opaque-capability
enable
enable traffic-adjustment advertise
area
0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255
network 172.6.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
ospf cost 15
mpls
mpls te

mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
ospf cost 10
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
vlan batch 200 300
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path pri-
path
next hop
172.2.1.1
next hop
172.1.1.1
next hop 1.1.1.9
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
ospf cost 10
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
ospf cost 10
#
#


#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
interface Tunnel1
LoopBack1
te
destination
1.1.1.9
mpls te tunnel-id
101
path
mpls te igp
advertise
10
mpls te commit
#
ospf 1
enable traffic-adjustment advertise
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRD
#
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
ospf cost 10
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
ospf cost 10
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
ospf cost 10
#
#
#
#
ospf 1
area 0.0.0.0
network 172.3.1.0 0.0.0.255

network 172.4.1.0 0.0.0.255

network 172.5.1.0 0.0.0.255
#
return

#
sysname LSRE
#
vlan batch 500 600
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
ospf cost 10
#
interface Vlanif600
ip address 172.6.1.2 255.255.255.0
ospf cost 10
#
#
#
ospf 1
area 0.0.0.0
network 172.5.1.0 0.0.0.255
network 172.6.1.0 0.0.0.255
#
return
5.24.6 Example for Setting Attributes for an MPLS TE Tunnel

As shown in Figure 5-40, LSRA has two dynamic MPLS TE tunnels to LSRD: Tunnel1 and
Tunnel2. The affinity attribute and mask need to be used according to the administrative
group attribute so that Tunnel1 on LSRA uses the physical link LSRA -> LSRB -> LSRC ->
LSRD and Tunnel2 uses the physical link LSRA -> LSRB -> LSRE -> LSRC -> LSRD.
NOTE

Figure 5-40 Networking for setting MPLS TE tunnel attributes

Loopback1
4.4.4.9/32
LSRD
GE0/0/1
VLANIF300
172.3.1.2/24
Loopback1 Loopback1 GE0/0/2 Loopback1

1.1.1.9/32 GE0/0/1 2.2.2.9/32 GE0/0/2 VLANIF300 3.3.3.9/32
VLANIF100 VLANIF200
172.3.1.1/24
172.1.1.1/24 172.2.1.1/24
LSRB GE0/0/1 LSRC

GE0/0/1 VLANIF200
LSRA VLANIF100 172.2.1.2/24 GE0/0/3
172.1.1.2/24 GE0/0/3 Loopback1 VLANIF500
VLANIF400 5.5.5.9/32 172.5.1.2/24
172.4.1.1/24
GE0/0/1 GE0/0/2
Path of Tunnel 1 VLANIF400 VLANIF500
172.4.1.2/24 172.5.1.1/24
Path of Tunnel 2 LSRE
1. Assign an IP address to each interface and configure OSPF to ensure that there are
reachable routes between LSRs.
2. Configure an ID for each LSR and globally enable MPLS TE, RSVP-TE, CSPF on each
node and interface, and enable OSPF TE.
3. Configure the administrative group attribute of the outbound interface of the tunnel on
each LSR.
4. On the ingress node of the primary tunnel, create a tunnel interface, and specify the IP
address, tunneling protocol, destination IP address, tunnel ID, and dynamic signaling
5. Determine and configure the affinity attribute and mask for each tunnel according to the
administrative group attribute and networking requirements.
Procedure
Step 1 Assign an IP address to each interface and configure OSPF.
according to Figure 5-40. The configurations of LSRB, LSRC, LSRD, and LSRE are similar


[LSRA] ospf 1
[LSRA-ospf-1] quit
LSR. You can see that the LSRs have learned the routes to Loopback1 interfaces of each
other. The display on LSRA is used as an example.
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 172.1.1.2 Vlanif100
3.3.3.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
4.4.4.9/32 OSPF 10 3 D 172.1.1.2 Vlanif100
5.5.5.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.3.1.0/24 OSPF 10 3 D 172.1.1.2 Vlanif100
172.4.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.5.1.0/24 OSPF 10 3 D 172.1.1.2 Vlanif100
# Configure LSRA. The configurations of LSRB, LSRC, LSRD, and LSRE are similar to the
configuration of LSRA, and are not mentioned here. CSPF only needs to be configured on the
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

[LSRA] ospf
[LSRA-ospf-1] quit

Step 4 Set MPLS TE attributes of the outbound interface of each node.

# Configure the administrative group attribute on LSRA.
[LSRA-Vlanif100] mpls te link administrative group 10001
# Configure the administrative group attribute on LSRB.

[LSRB-Vlanif200] mpls te link administrative group 10101
[LSRB-Vlanif400] mpls te link administrative group 10011
# Configure the administrative group attribute on LSRC.

[LSRC-Vlanif300] mpls te link administrative group 10001
# Configure the administrative group attribute on LSRE.

[LSRE] interface vlanif 500
[LSRE-Vlanif500] mpls te link administrative group 10011
[LSRE-Vlanif500] quit
After the configurations are complete, check the TEDB including the Color field of each link.
The Color field indicates the administrative group attribute. The display on LSRA is used as
an example.
[LSRA] display mpls te cspf tedb node
Router ID: 1.1.1.9
IGP Type: OSPF Process ID: 1
MPLS-TE Link Count: 1
Link[1]:
OSPF Router ID: 1.1.1.9 Opaque LSA ID: 1.0.0.1
Interface IP Address: 172.1.1.1
DR Address: 172.1.1.1
IGP Area: 0
Link Type: Multi-access Link Status: Active
IGP Metric: 1 TE Metric: 1 Color: 0x10001
...
Step 5 Create MPLS TE tunnels on the ingress node.

# Create Tunnel1 on LSRA.
[LSRA-Tunnel1] mpls te record-route label
[LSRA-Tunnel1] mpls te affinity property 10101 mask 11011
[LSRA-Tunnel1] quit

[LSRA-Tunnel2] mpls te affinity property 10011 mask 11101


[LSRA-Tunnel2] quit
After the configurations are complete, run the display mpls te tunnel-interface command to
view the tunnel status on LSRA. You can see that both Tunnel1 and Tunnel2 are Up.
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------
Session ID : 100
----------------------------------------------------------------
Tunnel2
----------------------------------------------------------------
Session ID : 101
Run the display mpls te tunnel path command to view the path of the tunnel. You can see
that the affinity attribute and mask of the tunnel match the administrative group attribute of
each link.
[LSRA] display mpls te tunnel path
Lsp ID : 1.1.1.9 :100 :47
Hop Information
Hop 0 172.1.1.1
Hop 1 172.1.1.2 Label 1065
Hop 2 2.2.2.9 Label 1065
Hop 3 172.2.1.1
Hop 4 172.2.1.2 Label 1075
Hop 5 3.3.3.9 Label 1075
Hop 6 172.3.1.1
Hop 7 172.3.1.2 Label 3
Hop 8 4.4.4.9 Label 3

Lsp ID : 1.1.1.9 :101 :4
Hop Information
Hop 0 172.1.1.1
Hop 1 172.1.1.2 Label 1067
Hop 2 2.2.2.9 Label 1067
Hop 3 172.4.1.1
Hop 4 172.4.1.2 Label 1040
Hop 5 5.5.5.9 Label 1040
Hop 6 172.5.1.1
Hop 7 172.5.1.2 Label 1077
Hop 8 3.3.3.9 Label 1077
Hop 9 172.3.1.1
Hop 10 172.3.1.2 Label 3
Hop 11 4.4.4.9 Label 3
----End

Configuration Files
#
sysname LSRA
#
vlan batch 100
#
mpls lsr-id
1.1.1.9
mpls
mpls
te
mpls rsvp-
te
mpls te cspf
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls te link administrative group 10001
mpls rsvp-te
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
LoopBack1
te
destination
4.4.4.9
mpls te tunnel-id
100
label
mpls te affinity property 10101 mask
11011
mpls te
commit
#
interface Tunnel2
LoopBack1
te
destination
4.4.4.9
mpls te tunnel-id
101
label
mpls te affinity property 10011 mask
11101
mpls te
commit
#
ospf
1
opaque-capability

enable
area
0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255
mpls-te enable
#
return


#
sysname LSRC
#
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te enable
#
return

#
sysname LSRD
#
vlan batch 300
#
mpls lsr-id
4.4.4.9
mpls

mpls
te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.3.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9
0.0.0.0
network 172.4.1.0
0.0.0.255

network 172.5.1.0 0.0.0.255

mpls-te enable
#
return
5.24.7 Example for Configuring Srefresh Based on Manual TE

FRR
As shown in Figure 5-41, the primary CR-LSP is along the path LSRA -> LSRB -> LSRC ->
LSRD, and the link between LSRB and LSRC needs to be protected by FRR.
A bypass CR-LSP is set up along the path LSRB -> LSRE -> LSRC. LSRB functions as the
PLR and LSRC functions as the MP.
The primary and bypass MPLS TE tunnels are set up by using explicit paths. RSVP-TE is
used as the signaling protocol.
The Srefresh function needs to be configured on LSRB and LSRC.
NOTE
Figure 5-41 Networking for configuring Srefresh based on manual TE FRR

Loopback1
4.4.4.9/32
LSRD
GE0/0/1
VLANIF300
172.3.1.2/24

1.1.1.9/32 GE0/0/1 2.2.2.9/32 GE0/0/2 VLANIF300 3.3.3.9/32
VLANIF100 VLANIF200 172.3.1.1/24
172.1.1.1/24 172.2.1.1/24
GE0/0/1 LSRB GE0/0/1 LSRC

VLANIF100 VLANIF200
LSRA 172.2.1.2/24 GE0/0/3
VLANIF400 5.5.5.9/32 172.5.1.2/24
172.4.1.1/24
GE0/0/1 GE0/0/2
Primary CR-LSP VLANIF400 VLANIF500
172.4.1.2/24 172.5.1.1/24
Bypass CR-LSP LSRE

1. Configure manual TE FRR.

2. Configure Srefresh on the PLR and MP along a tunnel to enhance transmission reliability
of RSVP messages and improve resource use efficiency.
Procedure
Step 1 Configure manual TE FRR.
Configure the primary and bypass MPLS TE tunnels according to 5.24.13 Example for
Configuring Manual TE FRR, and then bind the two tunnels.
Step 2 Configure the Srefresh function on LSRB and LSRC.
# Configure the Srefresh function on LSRB.
[LSRB] mpls
[LSRB-mpls] mpls rsvp-te srefresh
[LSRB-mpls] quit
# Configure the Srefresh function on LSRC.

[LSRC] mpls
[LSRC-mpls] mpls rsvp-te srefresh
[LSRC-mpls] quit

# Run the display mpls rsvp-te statistics global command on LSRB. You can view the status
of the Srefresh function. If the command output shows that the values of
SendSrefreshCounter, RecSrefreshCounter, SendAckMsgCounter, and RecAckMsgCounter
are not zero, Srefresh packets are successfully transmitted.
[LSRB] display mpls rsvp-te statistics global
LSR ID: 2.2.2.9 LSP Count: 2
PSB Count: 2 RSB Count: 2
RFSB Count: 1
Total Statistics Information:

PSB CleanupTimeOutCounter: 0 RSB CleanupTimeOutCounter: 0
SendPacketCounter: 122613 RecPacketCounter: 127446
SendCreatePathCounter: 25 RecCreatePathCounter: 260
SendRefreshPathCounter: 62209 RecRefreshPathCounter: 62113
SendCreateResvCounter: 21 RecCreateResvCounter: 31
SendRefreshResvCounter: 60101 RecRefreshResvCounter: 64792
SendResvConfCounter: 0 RecResvConfCounter: 0
SendHelloCounter: 0 RecHelloCounter: 0
SendAckCounter: 0 RecAckCounter: 0
SendPathErrCounter: 242 RecPathErrCounter: 0
SendResvErrCounter: 0 RecResvErrCounter: 0
SendPathTearCounter: 11 RecPathTearCounter: 8
SendResvTearCounter: 2 RecResvTearCounter: 0
SendSrefreshCounter: 1 RecSrefreshCounter: 1
SendAckMsgCounter: 1 RecAckMsgCounter: 1
SendChallengeMsgCounter: 0 RecChallengeMsgCounter: 0
SendResponseMsgCounter: 0 RecResponseMsgCounter: 0
SendErrMsgCounter: 0 RecErrMsgCounter: 0
SendRecoveryPathMsgCounter: 0 RecRecoveryPathMsgCounter: 0
SendGRPathMsgCounter: 0 RecGRPathMsgCounter: 0
ResourceReqFaultCounter: 0 RecGRPathMsgFromLSPMCounter: 0
Bfd neighbor count: 3 Bfd session count: 0
# Shut down the protected outbound interface VLANIF200 on LSRB.

[LSRB-Vlanif200] shutdown

Run the display interface tunnel 1 command on LSRA. You can view the status of the
primary CR-LSP and that the status of the tunnel interface is still Up.
Description:
...
Run the tracert lsp te tunnel 1 command on LSRA. You can view the path that the tunnel
passes.
[LSRA] tracert lsp te tunnel 1
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C t
o break.
TTL Replier Time Type Downstream
0 Ingress 172.1.1.2/[1034 ]
1 172.1.1.2 1 ms Transit 172.4.1.2/[1042 1025 ]
2 172.4.1.2 1 ms Transit 172.5.1.2/[3 ]
3 172.5.1.2 2 ms Transit 172.3.1.2/[3 ]
4 4.4.4.9 2 ms Egress
The preceding information shows that services on the link have been switched to the bypass
CR-LSP.
Run the display mpls te tunnel name Tunnel1 verbose command on LSRB. You can see
that the bypass CR-LSP is in use.
[LSRB] display mpls te tunnel name Tunnel1 verbose
No : 1
Tunnel Interface Name : -
LSR Role : Transit
In-Interface : Vlanif100
IncludeAllAff : 0x0
ER-Hop Table Index : - AR-Hop Table Index: 0
PSB Handle : 8421
Created Time : 2013-09-16 18:27:55+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass In Use : In Use
Bypass Tunnel Id : 1225021547
BypassTunnel : Tunnel Index[Tunnel2], InnerLabel[1042]
Bypass LSP ID : 2 FrrNextHop : 172.5.1.2


IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
Run the display mpls rsvp-te statistics global command on LSRB to view Srefresh statistics.
RFSB Count: 1

Because the Srefresh function is configured globally on LSRB and LSRC, the Srefresh
function takes effect on LSRB and LSRC when the primary tunnel fails.
----End
Configuration Files
#
sysname LSRA
#
vlan batch 100
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 172.1.1.2

next hop 172.2.1.2

next hop 172.3.1.2
next hop 4.4.4.9
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 4.4.4.9
mpls te record-route label
mpls te path explicit-path pri-path
mpls te fast-reroute
mpls te commit
#
return
#
sysname LSRB
#
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls te timer fast-reroute 120
mpls rsvp-te
mpls rsvp-te srefresh
mpls te cspf
#
explicit-path by-path
next hop 172.4.1.2
next hop 172.5.1.2
next hop 3.3.3.9
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200

ip address 172.2.1.1 255.255.255.0

isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
interface Tunnel2
destination 3.3.3.9
mpls te path explicit-path by-path
mpls te bypass-tunnel
mpls te protected-interface Vlanif200
mpls te commit
#
return
#
sysname LSRC
#
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
mpls rsvp-te srefresh
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
isis enable 1

mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
#
sysname LSRD
#
vlan batch 300
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9

mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0005.00
traffic-eng level-2
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
isis enable 1
#
return
5.24.8 Example for Configuring RSVP Authentication
As shown in Figure 5-42, VLANIF100 between LSRA and LSRB contains member
interfaces GE0/0/1 and GE0/0/2. An MPLS TE tunnel from LSRA to LSRC is set up by using
RSVP.
The handshake function needs to be configured so that LSRA and LSRB perform RSPV
authentication to prevent forged Resv messages from consuming network resources. In
addition, the message window function is configured to solve the problem of RSVP packet
mis-sequencing.
Figure 5-42 Networking of RSVP authentication

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
VLANIF100 VLANIF100 GE0/0/3
172.1.1.1/24 172.1.1.2/24 VLANIF200
172.2.1.1/24
GE0/0/1
GE0/0/1
LSRA GE0/0/1 LSRB VLANIF200 LSRC
GE0/0/2 GE0/0/2 172.2.1.2/24

1. Assign an IP address to each interface on each LSR and configure OSPF to ensure that
there are reachable routes between LSRs.
2. Configure an ID for each LSR and globally enable MPLS, MPLS TE, and RSVP-TE on
each node and interface.
3. On the ingress node, create a tunnel interface, and specify the IP address, tunneling
protocol, destination IP address, tunnel ID, and dynamic signaling protocol RSVP-TE,
and enable CSPF.
4. Configure RSVP authentication on LSRA and LSRB of the tunnel.
5. Configure the Handshake function on LSRA and LSRB to prevent forged Resv messages
from consuming network resources.
6. Configure the sliding window function on LSRA and LSRB to solve the problem of
RSVP packet mis-sequencing.
NOTE
It is recommended that the window size be larger than 32. If the window size is too small, some received
RSVP messages may be discarded, which can terminate the RSVP neighbor relationships.
Procedure
# Configure LSRA. Configure IP addresses for interfaces of LSRB and LSRC according to
Figure 5-42. The configurations of LSRB and LSRC are similar to the configuration of
[LSRA] ospf 1
[LSRA-ospf-1] quit
LSR. You can see that the LSRs have learned the routes to Loopback1 interfaces of each
other.

LSRA, and are not mentioned here. CSPF only needs to be configured on the ingress node of
the primary tunnel.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

[LSRA] ospf
[LSRA-ospf-1] quit
Step 4 Create an MPLS TE tunnel on the ingress node.

[LSRA-Tunnel1] quit
Description:...
Step 5 On LSRA and LSRB, configure RSVP authentication on the interfaces on the MPLS TE link.
# Configure LSRA.
[LSRA-Vlanif100] mpls rsvp-te authentication cipher Huawei@1234
[LSRA-Vlanif100] mpls rsvp-te authentication handshake
[LSRA-Vlanif100] mpls rsvp-te authentication window-size 32
# Configure LSRB.
[LSRB-Vlanif100] mpls rsvp-te authentication cipher Huawei@1234
[LSRB-Vlanif100] mpls rsvp-te authentication handshake
[LSRB-Vlanif100] mpls rsvp-te authentication window-size 32

Run the reset mpls rsvp-te command, and then run the display interface tunnel command
on LSRA. You can see that the tunnel interface is Up.
Run the display mpls rsvp-te interface command on LSRA or LSRB to view information
about RSVP authentication.
[LSRA] display mpls rsvp-te interface vlanif 100
Interface: Vlanif100
Interface Address: 172.1.1.1
Interface state: UP Interface Index: 0x36
Total-BW: 0 Used-BW: 0
Hello configured: NO Num of Neighbors: 1
SRefresh feature: DISABLE SRefresh Interval: 30 sec
Mpls Mtu: 1500 Retransmit Interval: 5000 msec
Increment Value: 1 Authentication: ENABLE
Challenge: ENABLE WindowSize: 32
Next Seq # to be sent:2767789282 0 Key ID: 0xa4ff1cdc0000
Bfd Enabled: DISABLE Bfd Min-Tx: 1000
Bfd Min-Rx: 1000 Bfd Detect-Multi: 3
----End
Configuration Files
#
sysname LSRA
#
vlan batch 100
#
mpls lsr-id
1.1.1.9
mpls
mpls
te
mpls rsvp-
te
mpls te cspf
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
mpls rsvp-te authentication cipher %^%#P>Z{S["[&0D+~^McJ#GX~ij}D%N|y;w4*D;M!
WJE%^%#
mpls rsvp-te authentication handshake
mpls rsvp-te authentication window-size 32
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
LoopBack1
te
destination

3.3.3.9
mpls te tunnel-id
101
mpls te
commit
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id
2.2.2.9
mpls
mpls
te
mpls rsvp-
te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
mpls rsvp-te authentication cipher %^%#DbqR!4[#1)#D0,Gv*|
(<^`B>1},"k2[QT}T)*C5+%^%#
mpls rsvp-te authentication window-size 32
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf
1

opaque-capability
enable
area
0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return

#
sysname LSRC
#
vlan batch 200
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return
5.24.9 Example for Configuring RSVP Authentication Based on

Manual TE FRR
LSRD, and the link between LSRB and LSRC needs to be protected by TE FRR.
The primary and bypass MPLS TE tunnels are set up by using explicit paths. RSVP-TE is
used as the signaling protocol.
RSVP authentication needs to be configured on LSRB and LSRC.

NOTE
Figure 5-43 Networking of RSVP authentication based on manual TE FRR

Loopback1
4.4.4.9/32
LSRD
GE0/0/1
VLANIF300
172.3.1.2/24

1.1.1.9/32 GE0/0/1 2.2.2.9/32 GE0/0/2 VLANIF300 3.3.3.9/32
VLANIF100 VLANIF200 172.3.1.1/24
172.1.1.1/24 172.2.1.1/24

VLANIF100 VLANIF200
LSRA 172.2.1.2/24 GE0/0/3
VLANIF400 5.5.5.9/32 172.5.1.2/24
172.4.1.1/24
GE0/0/1 GE0/0/2
172.4.1.2/24 172.5.1.1/24
Bypass CR-LSP LSRE
1. Configure manual TE FRR.
2. Configure RSVP authentication on LSRB and LSRC to prevent forged Resv messages
from consuming network resources.
Procedure
Step 1 Configure MPLS TE FRR.
Configure the primary and bypass MPLS TE tunnels according to 5.24.13 Example for
Configuring Manual TE FRR, and then bind the two tunnels.
Step 2 Configure RSVP authentication on LSRB and LSRC.
The Handshake function and local password are configured to check whether RSVP
authentication is configured successfully.
NOTE
The neighbor node is identified by its LSR-ID, therefore, you must enable CSPF on two neighboring devices
where RSVP authentication is required.

# Configure RSVP authentication on LSRB.

[LSRB] mpls rsvp-te peer 3.3.3.9
[LSRB-mpls-rsvp-te-peer-3.3.3.9] mpls rsvp-te authentication cipher Huawei@1234
[LSRB-mpls-rsvp-te-peer-3.3.3.9] mpls rsvp-te authentication handshake
[LSRB-mpls-rsvp-te-peer-3.3.3.9] quit
# Configure RSVP authentication on LSRC.

[LSRC] mpls
[LSRC-mpls] mpls te cspf
[LSRC-mpls] quit
[LSRC] mpls rsvp-te peer 2.2.2.9
[LSRC-mpls-rsvp-te-peer-2.2.2.9] mpls rsvp-te authentication cipher Huawei@1234
[LSRC-mpls-rsvp-te-peer-2.2.2.9] mpls rsvp-te authentication handshake
[LSRC-mpls-rsvp-te-peer-2.2.2.9] quit

Run the display mpls rsvp-te statistics global command on LSRB. You can view the status
of RSVP authentication. If the command output shows that the values of
SendChallengeMsgCounter, RecChallengeMsgCounter, SendResponseMsgCounter, and
RecResponseMsgCounter are not zero, the PLR and the MP successfully shake hands with
each other and RSVP authentication is configured successfully.
RFSB Count: 1

# Shut down the protected outbound interface on the LSRB.

Description:
...

passes.
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C t
o break.
0 Ingress 172.1.1.2/[1037 ]
1 172.1.1.2 1 ms Transit 172.4.1.2/[1045 1027 ]
2 172.4.1.2 1 ms Transit 172.5.1.2/[3 ]
3 172.5.1.2 2 ms Transit 172.3.1.2/[3 ]
4 4.4.4.9 2 ms Egress
CR-LSP.
No : 1
LSR Role : Transit
IncludeAllAff : 0x0
PSB Handle : 8562
Created Time : 2013-09-16
19:14:37+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
IncludeAllGroup : -


--------------------------------
BFD Information
--------------------------------
# Run the display mpls rsvp-te peer command to check whether the bypass CR-LSP is
successfully set up.
[LSRB] display mpls rsvp-te peer
Remote Node id Neighbor
Neighbor Addr: -----
SrcInstance: 0x60128590 NbrSrcInstance: 0x0
Hello Type Sent: NONE
SRefresh Enable: NO
Last valid seq # rcvd: NULL
Remote Node id Neighbor

Neighbor Addr: 3.3.3.9
SRefresh Enable: NO
SRefresh Enable: NO
SRefresh Enable: NO
The command output shows that the number of RSBs on neighbor of LSRB is not zero. This
indicates that RSVP authentication is successful on LSRB and its neighbor LSRC, and
resources are successfully reserved.
----End
Configuration Files
#
sysname LSRA
#
vlan batch 100
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 172.1.1.2
next hop 172.2.1.2

next hop 172.3.1.2

next hop 4.4.4.9
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 4.4.4.9
mpls te commit
#
return
#
sysname LSRB
#
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 172.4.1.2
next hop 172.5.1.2
next hop 3.3.3.9
#
mpls rsvp-te peer 3.3.3.9
mpls rsvp-te authentication cipher %^%#P>Z{S["[&0D+~^McJ#GX~ij}D%N|y;w4*D;M!
WJE%^%#
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te

mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
interface Tunnel2
destination 3.3.3.9
mpls te commit
#
return
#
sysname LSRC
#
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls rsvp-te peer 2.2.2.9
mpls rsvp-te authentication cipher %^%#ro:\V)kWU-"TK!'1!SZH&}Lv~B3:".zv!'R;!
JyC%^%#
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0

isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
#
sysname LSRD
#
vlan batch 300
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return


#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0005.00
traffic-eng level-2
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
isis enable 1
#
return
5.24.10 Example for Configuring SRLG Based on Auto TE FRR

As shown in Figure 5-44, An MPLS TE tunnel is set up between LSRA and LSRC, with the
path LSRA -> LSRB -> LSRC.
The link LSRA -> LSRB and link LSRA -> LSRE belong to the same SRLG (SRLG1 is used
here).
To improve reliability, auto TE FRR needs to be configured and the links of the bypass CR-
LSP and primary tunnel must be in different SRLGs. If no path is available, SRLG attributes
can be ignored.
NOTE

Figure 5-44 Networking for configuring SRLG based on auto TE FRR

Loopback1
6.6.6.9/32
GE0/0/1 GE0/0/2
VLANIF600 VLANIF700
172.6.1.2/24 172.7.1.1/24
LSRF
GE0/0/2 GE0/0/3
VLANIF600 VLANIF700
172.6.1.1/24 Loopback1 172.7.1.2/24
GE0/0/1 GE0/0/2
1.1.1.9/32 VLANIF100 VLANIF200 3.3.3.9/32
172.1.1.2/24 172.2.1.1/24
LSRA LSRC
GE0/0/1 GE0/0/1
VLANIF100 VLANIF200
172.1.1.1/24 172.2.1.2/24
VLANIF400 VLANIF500
172.4.1.1/24 172.5.1.2/24
Loopback1
5.5.5.9/32
GE0/0/1 GE0/0/2
VLANIF400 VLANIF500
172.4.1.2/24 172.5.1.1/24
LSRE
Primary CR-LSP
2. Configure an ID for each LSR and globally enable MPLS, MPLS TE, RSVP-TE, CSPF
on each node and interface, and enable OSPF TE.
protocol RSVP-TE for the tunnel interface. The explicit path is LSRA -> LSRB ->
LSRC.
4. Configure SRLG numbers for SRLG member interfaces.
5. Configure the SRLG path calculation mode on the ingress node of the primary tunnel.
6. Configure auto TE FRR on the ingress node of the primary tunnel to protect LSRB.
Procedure
# Configure LSRA. Configure IP addresses for interfaces of LSRB, LSRC, LSRE, and LSRF
according to Figure 5-44. The configurations of LSRB, LSRC, LSRE, and LSRF are similar


[LSRA] ospf 1
[LSRA-ospf-1] quit
LSR. You can see that the LSRs learn the routes to Loopback1 of each other. The display on
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 172.1.1.2 Vlanif100
3.3.3.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
OSPF 10 2 D 172.4.1.2 Vlanif400
OSPF 10 2 D 172.6.1.2 Vlanif600
5.5.5.9/32 OSPF 10 1 D 172.4.1.2 Vlanif400
6.6.6.9/32 OSPF 10 1 D 172.6.1.2 Vlanif600
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.4.1.0/24 Direct 0 0 D 172.4.1.1 Vlanif400
172.4.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif400
172.5.1.0/24 OSPF 10 2 D 172.4.1.2 Vlanif400
172.6.1.0/24 Direct 0 0 D 172.6.1.1 Vlanif600
172.6.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif600
172.7.1.0/24 OSPF 10 2 D 172.6.1.2 Vlanif600
# Configure LSRA. The configurations of LSRB, LSRC, LSRE, and LSRF are similar to the


[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

[LSRA] ospf
[LSRA-ospf-1] quit
Step 4 On LSRA, create an MPLS TE tunnel for the primary CR-LSP.

# Configure the explicit path of the primary CR-LSP.
# Configure the MPLS TE tunnel interface of the primary CR-LSP.

[LSRA-Tunnel1] quit
Run the display interface tunnel 1 command on LSRA. You can see that the tunnel status is
Up.
Description:
...
Step 5 Configure SRLG.

Add links LSRA -> LSRB and LSRA -> LSRE to SRLG1, and configure the SRLG path
calculation mode on the ingress node LSRA of the primary tunnel.

# Configure LSRA.
[LSRA-Vlanif100] mpls te srlg 1
# Configure the SRLG path calculation mode on LSRA.

[LSRA] mpls
[LSRA-mpls] mpls te srlg path-calculation preferred
[LSRA-mpls] quit
Run the display mpls te srlg all command to view SRLG information and the interfaces that
belong to the SRLG. The display on LSRA is used as an example.
[LSRA] display mpls te srlg all
Total SRLG supported : 1024
Total SRLG configured : 2
SRLG 1: Vlanif100
Vlanif400
Run the display mpls te link-administration srlg-information to view SRLGs to which the
interfaces belong. The display on LSRA is used as an example.
[LSRA] display mpls te link-administration srlg-information
SRLGs on Vlanif100 :
1
1
Run the display mpls te cspf tedb srlg command to view TEDB information of the specified
SRLG.
[LSRA] display mpls te cspf tedb srlg 1
Interface-Address IGP-Type Area
172.1.1.1 OSPF 0
172.4.1.1 OSPF 0
Step 6 Configure auto TE FRR.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te auto-frr
[LSRA-mpls] quit
[LSRA-Tunnel1] mpls te fast-reroute
[LSRA-Tunnel1] quit
Run the display mpls te tunnel command on LSRA. You can see that the bypass CR-LSP has
been established.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 3.3.3.9 1 --/1024 I Tunnel1
1.1.1.9 3.3.3.9 4 --/1025 I Tunnel2048
Run the display mpls te tunnel path Tunnel1 command on LSRA. You can see that local
protection is enabled on the outbound interface (172.1.1.1) of the primary tunnel on LSRA.

[LSRA] display mpls te tunnel path Tunnel1

Lsp ID : 1.1.1.9 :100 :1
Hop Information
Hop 0 172.1.1.1 Local-Protection available | node
Hop 1 172.1.1.2 Label 1024
Hop 2 2.2.2.9 Label 1024
Hop 3 172.2.1.1
Hop 4 172.2.1.2 Label 3
Hop 5 3.3.3.9 Label 3
After the configurations are complete, run the display mpls te tunnel name Tunnel1 verbose
command on LSRA. You can see that the primary tunnel is bound to a bypass CR-LSP
(Tunnel2048) and the FRR next hop is 172.7.1.2.
[LSRA] display mpls te tunnel name Tunnel1 verbose
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 8198
Created Time : 2013-09-16 15:20:42+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass In Use : Not Used
IncludeAllGroup : -
--------------------------------

BFD Information
--------------------------------
# Run the display mpls te tunnel path Tunnel2048 command on LSRA to check the path of
the bypass CR-LSP. You can see that the path of the bypass CR-LSP is LSRA -> LSRF ->
LSRC.
Lsp ID : 1.1.1.9 :1025 :4
Hop Information
Hop 0 172.6.1.1
Hop 1 172.6.1.2 Label 1025
Hop 2 6.6.6.9 Label 1025
Hop 3 172.7.1.1
Hop 4 172.7.1.2 Label 3
Hop 5 3.3.3.9 Label 3
# Run the shutdown command on GE0/0/2 of LSRA.

# Run the display mpls te tunnel name Tunnel1 verbose command on LSRA. You can see
that the primary tunnel is bound to Tunnel2049 and the FRR next hop is 172.5.1.2.
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 8198
Created Time : 2013-09-16 15:20:42+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info

IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# Run the display mpls te tunnel path Tunnel2049 command to check the path of the bypass
CR-LSP.
Lsp ID : 1.1.1.9 :1026 :4
Hop Information
Hop 0 172.4.1.1
Hop 1 172.4.1.2 Label 1026
Hop 2 5.5.5.9 Label 1026
Hop 3 172.5.1.1
Hop 4 172.5.1.2 Label 3
Hop 5 3.3.3.9 Label 3
You can see that the path of the bypass CR-LSP is LSRA -> LSRE -> LSRC. This is because
the SRLG path calculation mode is configured as preferred. CSPF tries to calculate the path
of the bypass tunnel to avoid the links in the same SRLG as the protected interface(s). If
calculation fails, CSPF does not take the SRLG as a constraint.
----End
Configuration Files
#
sysname LSRA
#
#
mpls lsr-id
1.1.1.9
mpls
mpls
te
mpls te auto-frr
mpls te srlg path-calculation preferred
mpls rsvp-
te
mpls te cspf
#
explicit-path pri-
path
next hop
172.1.1.2
next hop
172.2.1.2
next hop 3.3.3.9

#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls te srlg 1
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls te srlg 1
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
destination 3.3.3.9
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255
network 172.6.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#

interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#


#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9
0.0.0.0
network 172.4.1.0
0.0.0.255
network 172.5.1.0 0.0.0.255
mpls-te enable
#
return


#
sysname LSRF
#
vlan batch 600 700
#
mpls lsr-id 6.6.6.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 6.6.6.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 6.6.6.9
0.0.0.0
network 172.6.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255
mpls-te enable
#
return
5.24.11 Example for Configuring SRLG Based on CR-LSP Hot

Standby
As shown in Figure 5-45, An MPLS TE tunnel is set up between LSRA and LSRC, with the
path LSRA -> LSRB -> LSRC.
The link LSRA -> LSRB and the link LSRA -> LSRE are in the same SRLG (SRLG1 for
example); the link LSRC -> LSRB and the link LSRC -> LSRE are in the same SLRG
(SRLG2 for example).
To improve reliability, a hot-standby CR-LSP needs to be established and the links of the
bypass CR-LSP and primary tunnel must be in different SRLGs.

NOTE
Figure 5-45 Networking for configuring SRLG based on CR-LSP hot standby
Loopback1
6.6.6.9/32
GE0/0/1 GE0/0/2
VLANIF600 VLANIF700
172.6.1.2/24 172.7.1.1/24
LSRF
GE0/0/2 GE0/0/3
VLANIF600 VLANIF700
172.6.1.1/24 Loopback1 172.7.1.2/24
GE0/0/1 GE0/0/2
1.1.1.9/32 VLANIF100 VLANIF200 3.3.3.9/32
172.1.1.2/24 172.2.1.1/24
LSRA LSRC
GE0/0/1 GE0/0/1
VLANIF100 VLANIF200
172.1.1.1/24 172.2.1.2/24
VLANIF400 VLANIF500
172.4.1.1/24 172.5.1.2/24
Loopback1
5.5.5.9/32
GE0/0/1 GE0/0/2
VLANIF400 VLANIF500
172.4.1.2/24 172.5.1.1/24
LSRE
Primary CR-LSP
protocol RSVP-TE for the tunnel interface. The explicit path is LSRA -> LSRB ->
LSRC.
4. Configure SRLG numbers for SRLG member interfaces.
5. Configure the SRLG path calculation mode on the ingress node of the primary tunnel.
6. Configure a hot-standby CR-LSP on the ingress node of the primary tunnel.
Procedure

# Configure LSRA. Configure IP addresses for interfaces of LSRB, LSRC, LSRE, and LSRF
according to Figure 5-45. The configurations of LSRB, LSRC, LSRE, and LSRF are similar
[LSRA] ospf 1
[LSRA-ospf-1] quit
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 172.1.1.2 Vlanif100
3.3.3.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
OSPF 10 2 D 172.4.1.2 Vlanif400
OSPF 10 2 D 172.6.1.2 Vlanif600
5.5.5.9/32 OSPF 10 1 D 172.4.1.2 Vlanif400
6.6.6.9/32 OSPF 10 1 D 172.6.1.2 Vlanif600
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.4.1.0/24 Direct 0 0 D 172.4.1.1 Vlanif400
172.4.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif400
172.5.1.0/24 OSPF 10 2 D 172.4.1.2 Vlanif400
172.6.1.0/24 Direct 0 0 D 172.6.1.1 Vlanif600

172.6.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif600

172.7.1.0/24 OSPF 10 2 D 172.6.1.2 Vlanif600
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

[LSRA] ospf
[LSRA-ospf-1] quit


[LSRA-Tunnel1] quit
Run the display interface tunnel 1 command on LSRA. You can see that the tunnel status is
Up.


Description:
...
Step 5 Configure SRLG.

Configure SRLG1 for links LSRA -> LSRB and LSRA -> LSRE, and SRLG2 for links LSRC
-> LSRB and LSRC -> LSRE. Configure the SRLG path calculation mode on the ingress
node LSRA of the primary tunnel.
# Configure LSRA.
# Configure LSRB.
[LSRB-Vlanif200] mpls te srlg 2
# Configure LSRE.
[LSRE] interface vlanif 500
[LSRE-Vlanif500] mpls te srlg 2
[LSRE-Vlanif500] quit
# Configure the SRLG path calculation mode on LSRA.

[LSRA] mpls
[LSRA-mpls] mpls te srlg path-calculation strict
[LSRA-mpls] quit
Run the display mpls te srlg all command to view SRLG information and the interfaces that
belong to the SRLG. The display on LSRA is used as an example.
[LSRA] display mpls te srlg all
Total SRLG supported : 1024
Total SRLG configured : 2
SRLG 1: Vlanif100
Vlanif400
Run the display mpls te link-administration srlg-information to view SRLGs to which the
interfaces belong. The display on LSRA is used as an example.
[LSRA] display mpls te link-administration srlg-information
1
1
Run the display mpls te cspf tedb srlg command to view TEDB information of the specified
SRLG.
172.1.1.1 OSPF 0
172.4.1.1 OSPF 0
172.2.1.1 OSPF 0
172.5.1.1 OSPF 0

Step 6 Configure a hot-standby CR-LSP on the ingress node.

# Configure LSRA.
[LSRA-Tunnel1] mpls te backup hot-standby
[LSRA-Tunnel1] quit
Run the display mpls te tunnel-interface command on LSRA. You can see that the hot-
standby CR-LSP has been established.
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------
Session ID : 100
Run the display mpls te hot-standby state interface tunnel 1 command on LSRA to view
the hot-standby CR-LSP.
[LSRA] display mpls te hot-standby state interface tunnel 1
(s): same path
---------------------------------------------------------------------
Verbose information about the Tunnel1 hot-standby state
---------------------------------------------------------------------
session id : 100
main LSP token : 0x51
hot-standby LSP token : 0x4f
HSB switch result : Primary LSP
HSB switch reason : -
WTR config time : 10s
WTR remain time : -
using overlapped path : no

After the configurations are complete, run the display mpls te tunnel path command on
LSRA to view nodes that the primary CR-LSP and backup CR-LSP pass.
Lsp ID : 1.1.1.9 :100 :54
Hop Information
Hop 0 172.1.1.1
Hop 1 172.1.1.2
Hop 2 2.2.2.9
Hop 3 172.2.1.1
Hop 4 172.2.1.2
Hop 5 3.3.3.9

Lsp ID : 1.1.1.9 :100 :32780
Hop Information
Hop 0 172.6.1.1
Hop 1 172.6.1.2
Hop 2 6.6.6.9
Hop 3 172.7.1.1
Hop 4 172.7.1.2
Hop 5 3.3.3.9

# Run the shutdown command on GE0/0/2 of LSRA.

Run the display mpls te hot-standby state interface tunnel 1 command on LSRA. You can
see that the hot-standby LSP token is 0x0. This means that the hot-standby LSP is not set up
even though there are paths for setting up the hot-standby LSP.
[LSRA] display mpls te hot-standby state interface tunnel 1
(s): same path
---------------------------------------------------------------------
---------------------------------------------------------------------
session id : 100
main LSP token : 0x51
hot-standby LSP token : 0x0
WTR remain time : -
using overlapped path : -
----End
Configuration Files
#
sysname LSRA
#
#
mpls lsr-id
1.1.1.9
mpls
mpls
te
mpls te srlg path-calculation strict
mpls rsvp-
te
mpls te cspf
#
explicit-path pri-
path
next hop
172.1.1.2
next hop
172.2.1.2
next hop 3.3.3.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls te srlg 1
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls te srlg 1
mpls rsvp-te
#
interface Vlanif600

ip address 172.6.1.1 255.255.255.0

mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
destination 3.3.3.9
mpls te backup hot-
standby
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255
network 172.6.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls te srlg 2
mpls rsvp-te
#


#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9

0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls te srlg 2
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9
0.0.0.0
network 172.4.1.0
0.0.0.255
network 172.5.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRF
#
vlan batch 600 700
#
mpls lsr-id 6.6.6.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.2 255.255.255.0

mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 6.6.6.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 6.6.6.9
0.0.0.0
network 172.6.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255
mpls-te enable
#
return
5.24.12 Example for Configuring CR-LSP Hot Standby

Figure 5-46 shows an MPLS VPN. A TE tunnel with LSRA as the ingress node and LSRC as
the egress node needs to be established on LSRA. A hot-standby CR-LSP and best-effort path
also need to be configured.
l The path of the primary CR-LSP is LSRA -> LSRB -> LSRC.
l The path of the backup CR-LSP is LSRA -> LSRD -> LSRC.
l The best-effort path is LSRA -> LSRD -> LSRB -> LSRC.
When the primary CR-LSP fails, traffic switches to the backup CR-LSP. After the primary
CR-LSP recovers, traffic switches back to the primary CR-LSP in 15 seconds. If both the
primary CR-LSP and backup CR-LSP fail, traffic switches to the best-effort path.
NOTE

Figure 5-46 Networking of CR-LSP hot standby

Loopback1 Loopback1
2.2.2.9/32 GE0/0/3 GE0/0/3 4.4.4.9/32
VLANIF400 VLANIF400
172.4.1.1/24 172.4.1.2/24
LSRB LSRD
GE0/0/2 GE0/0/2
GE0/0/1 VLANIF200 VLANIF500 GE0/0/1
VLANIF100 172.2.1.1/24 172.5.1.2/24 VLANIF300
172.1.1.2/24 172.3.1.2/24
GE0/0/1 GE0/0/1
VLANIF100 VLANIF300
172.1.1.1/24 172.3.1.1 /24
GE0/0/2 GE0/0/2
LSRA VLANIF500 VLANIF200 LSRC
172.5.1.1/24 172.2.1.2/24
Loopback1 Loopback1
1.1.1.9/32 3.3.3.9/32
Path of Primary CR-LSP

Path of Backup CR-LSP
Path of Best-effort CR-LSP
3. Specify explicit paths for the primary and backup CR-LSPs on LSRA.
4. Create a tunnel interface with LSRC as the egress node on LSRA, specify an explicit
path, configure the hot-standby CR-LSP and best-effort path, and set the WTR time to 15
seconds.
Procedure
# Configure LSRA. Configure IP addresses for interfaces of LSRB, LSRC, and LSRD
according to Figure 5-46. The configurations on LSRB, LSRC, and LSRD are similar to the


[LSRA] ospf 1
[LSRA-ospf-1] quit
LSRs. You can see that the LSRs learn the routes to Loopback1 of each other.
On each node, enable MPLS TE and RSVP-TE in the MPLS view and in the interface view.
Enable CSPF on the ingress node.
# Configure LSRA. The configurations on LSRB, LSRC, and LSRD are similar to the
ingress nodes of the primary tunnel and bypass tunnel. That is, CSPF needs to be enabled on
only LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

# Configure LSRA. The configurations on LSRB, LSRC, and LSRD are similar to the
[LSRA] ospf
[LSRA-ospf-1] quit
Step 4 Configure the explicit paths for the primary and backup CR-LSPs.
# Configure the explicit path of the primary CR-LSP on LSRA.


# Configure the explicit path of the backup CR-LSP on LSRA.

[LSRA] explicit-path backup-path
[LSRA-explicit-path-backup-path] next hop 172.5.1.2
[LSRA-explicit-path-backup-path] quit
After the configurations are complete, you can view explicit paths through commands.
[LSRA] display explicit-path pri-path
Path Name : pri-path Path Status : Enabled
1 172.1.1.2 Strict Include
[LSRA] display explicit-path backup-path
Path Name : backup-path Path Status : Enabled
Step 5 Configure a tunnel interface.

# Configure a tunnel interface on LSRA and specify an explicit path.
# Configure CR-LSP hot standby on the tunnel interface, set the WTR time to 15 seconds,
specify an explicit path, and configure the best-effort path.
[LSRA-Tunnel1] mpls te backup hot-standby wtr 15
[LSRA-Tunnel1] mpls te path explicit-path backup-path secondary
[LSRA-Tunnel1] mpls te backup ordinary best-effort
[LSRA-Tunnel1] quit
After the configurations are complete, run the display mpls te tunnel-interface tunnel 1
command on LSRA. You can see that the primary and backup CR-LSPs are successfully
established.
[LSRA] display mpls te tunnel-interface tunnel 1
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------
Session ID : 100
Run the display mpls te hot-standby state interface tunnel 1 command on LSRA to view
CR-LSP hot standby information.
[LSRA] display mpls te hot-standby state interface Tunnel 1
(s): same path

---------------------------------------------------------------------
---------------------------------------------------------------------
session id : 100
main LSP token : 0xc
hot-standby LSP token : 0xb
WTR remain time : -
using overlapped path : no
Run the ping lsp te command on LSRA to detect connectivity of the hot-standby CR-LSP.
[LSRA] ping lsp te tunnel 1 hot-standby
LSP PING FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 : 100 data bytes, press
CTRL_C to break
Reply from 3.3.3.9: bytes=100 Sequence=1 time=11 ms
--- FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 2/3/11 ms
Run the tracert lsp te command on LSRA to check the path of the hot-standby CR-LSP.
[LSRA] tracert lsp te tunnel 1 hot-standby
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C to
break.
0 Ingress 172.5.1.2/[1027 ]
1 172.5.1.2 9 ms Transit 172.3.1.1/[3 ]
2 3.3.3.9 10 ms Egress

Connect two interfaces, Port 1 and Port 2, on a tester to LSRA and LSRC respectively. On
Port 1, inject MPLS traffic and send traffic to Port 2. After the cable attached to GE0/0/1 on
LSRA or LSRC is removed, traffic fast switches to the backup CR-LSP at the millisecond
level.
# Run the shutdown command on GE0/0/1 of LSRA to simulate cable removal.
Run the display mpls te tunnel-interface tunnel 1 command on LSRA. You can see that
traffic switches to the backup CR-LSP.
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------
Active LSP : Hot-Standby LSP
Session ID : 100
Primary LSP State : DOWN
Main LSP State : SETTING UP
After attaching the cable into GE0/0/1 (running the undo shutdown command on GE0/0/1 of
LSRA), you can see that traffic switches back to the primary CR-LSP in 15 seconds.

After you remove the cable from GE0/0/1 on LSRA or LSRB and the cable from GE0/0/1 on
LSRC or LSRD, the tunnel interface goes Down and then Up. This means that the best-effort
path has been set up successfully, allowing traffic to switch to the best-effort path.
# Run the shutdown command on GE0/0/1 of LSRA, and then run the shutdown command
on GE0/0/1 of LSRC.
[LSRC] interface gigabitethernet 0/0/1
[LSRC-GigabitEthernet0/0/1] shutdown
[LSRC-GigabitEthernet0/0/1] quit
After 5 seconds, run the display mpls te tunnel-interface tunnel 1 command on LSRA. You
can see that the tunnel interface is Up and the best-effort path is successfully established.
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------
Active LSP : Best-Effort LSP
Session ID : 100
Primary LSP State : DOWN
Hot-Standby LSP State : DOWN
Best-Effort LSP State : UP
Lsp ID : 1.1.1.9 :100 :32776
Hop Information
Hop 0 172.5.1.1
Hop 1 172.5.1.2
Hop 2 4.4.4.9
Hop 3 172.4.1.2
Hop 4 172.4.1.1
Hop 5 2.2.2.9
Hop 6 172.2.1.1
Hop 7 172.2.1.2
Hop 8 3.3.3.9
----End
Configuration Files
#
sysname LSRA
#
vlan batch 100 500
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path backup-path
next hop 172.5.1.2
next hop 172.3.1.1
next hop 3.3.3.9
#

next hop 172.1.1.2
next hop 172.2.1.2
next hop 3.3.3.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
te
destination
3.3.3.9
mpls te tunnel-id
100
mpls te record-
route
path
mpls te path explicit-path backup-path
secondary
mpls te backup hot-standby mode revertive wtr
15
mpls te backup ordinary best-
effort
mpls te commit
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
#

mpls lsr-id 2.2.2.9

mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
vlan batch 200 300
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
mpls
mpls te

mpls rsvp-te
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0
0.0.0.255
mpls-te
enable
#
return
#
sysname LSRD
#
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#

#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.3.1.0
0.0.0.255
network 172.4.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te
enable
#
return
5.24.13 Example for Configuring Manual TE FRR

LSRD, and the link between LSRB and LSRC needs to be protected by FRR.
The primary and bypass MPLS TE tunnels need to be set up by using explicit paths. RSVP-
TE is used as the signaling protocol.
NOTE

Figure 5-47 Networking for configuring manual TE FRR

Loopback1
4.4.4.9/32
LSRD
GE0/0/1
VLANIF300
172.3.1.2/24

1.1.1.9/32 GE0/0/1 2.2.2.9/32 GE0/0/2 VLANIF300 3.3.3.9/32
VLANIF100 VLANIF200 172.3.1.1/24
172.1.1.1/24 172.2.1.1/24

VLANIF100 VLANIF200
LSRA 172.2.1.2/24 GE0/0/3
VLANIF400 5.5.5.9/32 172.5.1.2/24
172.4.1.1/24
GE0/0/1 GE0/0/2
172.4.1.2/24 172.5.1.1/24
Bypass CR-LSP LSRE
1. Assign an IP address to each interface, enable IS-IS globally, configure the NET, and
enable IS-IS on each interface including the loopback interface.
2. Configure an ID for each LSR and globally enable MPLS, MPLS TE, RSVP-TE, and
CSPF on each node and interface. Enable IS-IS TE and change the cost type.
4. Enable TE FRR on the interface of the primary tunnel on the ingress node.
5. Create a tunnel interface on the ingress node LSRB of the bypass tunnel of the protected
link, set the IP address, tunnel protocol, destination IP address, tunnel ID, and RSVP-TE
for the tunnel interface, and specify the interface of the protected link.
Procedure
according to Figure 5-47. The configurations of LSRB, LSRC, LSRD, and LSRE are similar



[LSRA] isis 1
[LSRA-isis-1] quit
LSR. You can see that the LSRs learn the routes from each other. The display on LSRA is
used as an example.
------------------------------------------------------------------------------

2.2.2.9/32 ISIS-L2 15 10 D 172.1.1.2 Vlanif100
3.3.3.9/32 ISIS-L2 15 20 D 172.1.1.2 Vlanif100
4.4.4.9/32 ISIS-L2 15 30 D 172.1.1.2 Vlanif100
5.5.5.9/32 ISIS-L2 15 20 D 172.1.1.2 Vlanif100
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 ISIS-L2 15 20 D 172.1.1.2 Vlanif100
172.3.1.0/24 ISIS-L2 15 30 D 172.1.1.2 Vlanif100
172.4.1.0/24 ISIS-L2 15 20 D 172.1.1.2 Vlanif100
172.5.1.0/24 ISIS-L2 15 30 D 172.1.1.2 Vlanif100
Step 3 Configure basic MPLS functions and enable MPLS TE, CSPF, RSVP-TE, and IS-IS TE.
configuration of LSRA, and are not mentioned here. CSPF needs to be enabled only on the
ingress node of the primary tunnel (LSRA) and the ingress node LSRB of the bypass tunnel
(LSRB); CSPF does not need to be enabled on LSRC, LSRD, or LSRE.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

[LSRA] isis
[LSRA-isis-1] quit


# Enable TE FRR.
[LSRA-Tunnel1] quit
You can see that the status of Tunnel1 is Up.
Description:
...
Run the display mpls te tunnel verbose command on LSRA. You can view detailed
information about the tunnel interface.
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 8253
Created Time : 2013-09-16 17:57:06+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------


--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
Step 5 Configure a bypass CR-LSP on LSRB that functions as the PLR.

# Configure the explicit path of the bypass CR-LSP.
[LSRB] explicit-path by-path
[LSRB-explicit-path-by-path] next hop 172.4.1.2
[LSRB-explicit-path-by-path] quit
# Configure a tunnel interface of the bypass CR-LSP.

[LSRB] interface tunnel 2
[LSRB-Tunnel2] ip address unnumbered interface loopback 1
[LSRB-Tunnel2] tunnel-protocol mpls te
[LSRB-Tunnel2] destination 3.3.3.9
[LSRB-Tunnel2] mpls te tunnel-id 300
[LSRB-Tunnel2] mpls te path explicit-path by-path
[LSRB-Tunnel2] mpls te bypass-tunnel
# Bind the bypass CR-LSP to the protected interface.

[LSRB-Tunnel2] mpls te protected-interface vlanif 200
[LSRB-Tunnel2] mpls te commit
[LSRB-Tunnel2] quit
After the configurations are complete, run the display interface tunnel command on LSRB.
Run the display mpls lsp command on all the LSRs. You can view the LSP entry and that two
LSPs pass through LSRB and LSRC.
[LSRA] display mpls lsp
-------------------------------------------------------------------------------
LSP Information: RSVP LSP
-------------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
4.4.4.9/32 NULL/1032 -/Vlanif100

Run the display mpls te tunnel command on all the LSRs. You can view tunnel
establishment and that two tunnels pass through LSRB and LSRC.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 3 --/1032 I Tunnel1
[LSRB] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 3 1032/1040 T Tunnel1
2.2.2.9 3.3.3.9 2 --/1025 I Tunnel2
[LSRC] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 3 1040/3 T Tunnel1
2.2.2.9 3.3.3.9 2 3/-- E Tunnel2
[LSRD] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 3 3/-- E Tunnel1
[LSRE] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.9 3.3.3.9 2 1025/3 T Tunnel2
that the bypass tunnel is bound to the outbound interface VLANIF200 and not in use.
No : 1
LSR Role : Transit
IncludeAllAff : 0x0
PSB Handle : 8247
Created Time : 2013-09-16 17:59:06+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info


IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------

# Shut down the protected outbound interface on the PLR.
Description:
...
passes.
break.
0 Ingress 172.1.1.2/[1032 ]
1 172.1.1.2 2 ms Transit 172.4.1.2/[1040 1025 ]
2 172.4.1.2 2 ms Transit 172.5.1.2/[3 ]
3 172.5.1.2 1 ms Transit 172.3.1.2/[3 ]
4 4.4.4.9 11 ms Egress
CR-LSP.
NOTE
Run the display mpls te tunnel-interface command to view detailed information about tunnel
interfaces. You can view two CR-LSPs in Up state. This is because FRR establishes a new LSP by using
the make-before-break mechanism. The original LSP is deleted only after the new LSP is established
successfully.
No : 1


LSR Role : Transit
IncludeAllAff : 0x0
PSB Handle : 8247
Created Time : 2013-09-16 18:17:06+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# On the PLR, set theTE FRR scanning interval to 120.

[LSRB] mpls
[LSRB-mpls] mpls te timer fast-reroute 120
[LSRB-mpls] quit
# Start the protected outbound interface on the PLR.

[LSRB-Vlanif200] undo shutdown
Run the display interface tunnel 1 command on LSRA. You can view the primary CR-LSP
status and that the tunnel interface status is Up.
After a period of time, run the display mpls te tunnel name Tunnel1 verbose command on
LSRB. You can see that Tunnel1 is bound to VLANIF200 and remains unused.
----End

Configuration Files
#
sysname LSRA
#
vlan batch 100
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 172.1.1.2
next hop 172.2.1.2
next hop 172.3.1.2
next hop 4.4.4.9
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 4.4.4.9
mpls te commit
#
return

#
sysname LSRB
#
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 172.4.1.2
next hop 172.5.1.2

next hop 3.3.3.9

#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
interface Tunnel2
destination 3.3.3.9
mpls te commit
#
return
#
sysname LSRC
#
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
isis 1

is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
#
sysname LSRD
#
vlan batch 300
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#


#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return

#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0005.00
traffic-eng level-2
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
isis enable 1
#
return
5.24.14 Example for Configuring Auto TE FRR

As shown in Figure 5-48, a primary tunnel is set up by using the explicit path LSRA ->
LSRB -> LSRC -> LSRD. A bypass tunnel is set up on the ingress node LSRA to protect
LSRB, and a bypass tunnel is set up on the transit node LSRB to protect the link between
LSRB and LSRC.

NOTE
Figure 5-48 Networking for configuring auto TE FRR

Loopback1 Loopback1
6.6.6.9/32 4.4.4.9/32
GE0/0/1
VLANIF600 LSRF LSRD
172.6.1.2/24
GE0/0/2 GE0/0/1
VLANIF700 VLANIF300
GE0/0/2 172.7.1.1/24
VLANIF600 172.3.1.2/24
GE0/0/2
172.6.1.1/24 VLANIF300
Loopback1 Loopback1 172.3.1.1/24 Loopback1
1.1.1.9/32 GE0/0/1 2.2.2.9/32 GE0/0/2 GE0/0/4 3.3.3.9/32
VLANIF100 VLANIF200 VLANIF700
172.1.1.2/24 172.2.1.1/24 172.7.1.2/24

VLANIF100 VLANIF200
LSRA GE0/0/3 172.2.1.2/24 GE0/0/3
172.1.1.1/24 VLANIF400 VLANIF500
Loopback1
172.4.1.1/24 5.5.5.9/32 172.5.1.2/24
GE0/0/1 GE0/0/2
VLANIF400 VLANIF500
172.4.1.2/24 172.5.1.1/24
Primary CR-LSP LSRE
3. Enable auto TE FRR in the MPLS view of the ingress node of the primary tunnel and
configure node protection. Enable auto TE FRR in the MPLS view of the ingress node of
the bypass tunnel and configure link protection.
address, tunneling protocol, destination IP address, tunnel ID, and RSVP-TE for the
tunnel interface.
5. Enable TE FRR on the tunnel interface of the ingress node of the primary tunnel.
Procedure

# Configure LSRA. Configure IP addresses for interfaces on LSRB, LSRC, LSRD, LSRE,
and LSRF according to Figure 5-48. The configurations of LSRB, LSRC, LSRD, LSRE, and
LSRF are similar to the configuration of LSRA, and are not mentioned here.
[LSRA] ospf 1
[LSRA-ospf-1] quit
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 172.1.1.2 Vlanif100
3.3.3.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
OSPF 10 2 D 172.6.1.2 Vlanif600
4.4.4.9/32 OSPF 10 3 D 172.1.1.2 Vlanif100
OSPF 10 3 D 172.6.1.2 Vlanif600
5.5.5.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
6.6.6.9/32 OSPF 10 1 D 172.6.1.2 Vlanif600
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.3.1.0/24 OSPF 10 3 D 172.1.1.2 Vlanif100
OSPF 10 3 D 172.6.1.2 Vlanif600
172.4.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.5.1.0/24 OSPF 10 3 D 172.1.1.2 Vlanif100
OSPF 10 3 D 172.6.1.2 Vlanif600
172.6.1.0/24 Direct 0 0 D 172.6.1.1 Vlanif600
172.6.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif600
172.7.1.0/24 OSPF 10 2 D 172.6.1.2 Vlanif600

# Configure LSRA. The configurations of LSRB, LSRC, LSRD, LSRE, and LSRF are similar
to the configuration of LSRA, and are not mentioned here. CSPF only needs to be configured
on the ingress nodes of the primary tunnel and bypass tunnel. That is, CSPF needs to be
enabled on only LSRA and LSRB.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

[LSRA] ospf
[LSRA-ospf-1] quit
Step 4 Enable auto TE FRR.

# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te auto-frr
[LSRA-mpls] quit
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] mpls te auto-frr
[LSRB-mpls] quit
[LSRB-Vlanif200] mpls te auto-frr link




[LSRA-Tunnel1] mpls te priority 4 3
[LSRA-Tunnel1] quit

establishment, and that two tunnels pass through LSRB and LSRC and three tunnels (one
primary tunnel and two bypass tunnels) pass through LSRC.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 34 --/1055 I Tunnel1
1.1.1.9 3.3.3.9 3 --/1024 I Tunnel2048
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 34 1055/1063 T Tunnel1
2.2.2.9 3.3.3.9 1 --/1033 I Tunnel2048
[LSRC] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 34 1063/3 T Tunnel1
1.1.1.9 3.3.3.9 3 3/-- E Tunnel2048
2.2.2.9 3.3.3.9 1 3/-- E Tunnel2048
[LSRD] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 34 3/-- E Tunnel1
[LSRE] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.9 3.3.3.9 1 1033/3 T Tunnel2048
[LSRF] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 3.3.3.9 3 1024/3 T Tunnel2048
Run the display mpls te tunnel name Tunnel1 verbose command on LSRA and LSRB to
view LSP information. You can view information about the primary tunnel and bound bypass
tunnels.
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -


PSB Handle : 8205
Created Time : 2013-09-16 16:11:50+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass Tunnel Id :
1200144821
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------

No : 1
LSR Role : Transit
IncludeAllAff : 0x0
PSB Handle : 8198
Created Time : 2013-09-16 16:12:50+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------


--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass Tunnel Id :
1210141221
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
You can see that the primary tunnel on LSRA is bound to Tunnel2048 and the primary tunnel
on LSRB is bound to Tunnel2048.
Run the display mpls te tunnel name Tunnel2048 verbose command on LSRA and the
display mpls te tunnel name Tunnel2048 verbose command on LSRB. You can view details
of auto bypass tunnels.
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 8206
Created Time : 2013-09-16
16:11:50+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------

FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 8199
Created Time : 2013-09-16 16:12:50+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -

IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
You can see that the outbound interface VLANIF100 is protected by the auto bypass tunnel on
LSRA, and LSRB is protected. You can see that the outbound interface VLANIF200 is
protected by the auto bypass tunnel on LSRB, and the link between LSRB and LSRC is
protected.
Run the display mpls te tunnel path command on LSRA and LSRB. You can view path
information of the primary tunnel and the auto bypass tunnel, and view that node protection
and link protection are provided for the outbound interface on the primary tunnel.
Lsp ID : 1.1.1.9 :100 :34
Hop Information
Hop 1 172.1.1.2 Label 1055
Hop 2 2.2.2.9 Label 1055
Hop 3 172.2.1.1 Local-Protection available
Hop 4 172.2.1.2 Label 1063
Hop 5 3.3.3.9 Label 1063
Hop 6 172.3.1.1
Hop 7 172.3.1.2 Label 3
Hop 8 4.4.4.9 Label 3

Lsp ID : 1.1.1.9 :1025 :3
Hop Information
Hop 0 172.6.1.1
Hop 1 172.6.1.2 Label 1024
Hop 2 6.6.6.9 Label 1024
Hop 3 172.7.1.1
Hop 4 172.7.1.2 Label 3
Hop 5 3.3.3.9 Label 3
[LSRB] display mpls te tunnel path
Lsp ID : 1.1.1.9 :100 :34
Hop Information
Hop 0 1.1.1.9
Hop 2 172.1.1.2 Label 1055
Hop 3 2.2.2.9
Hop 4 172.2.1.1 Local-Protection available
Hop 5 172.2.1.2 Label 1063
Hop 6 3.3.3.9 Label 1063
Hop 7 172.3.1.1
Hop 8 172.3.1.2 Label 3
Hop 9 4.4.4.9 Label 3

Lsp ID : 2.2.2.9 :1026 :1
Hop Information
Hop 0 172.4.1.1
Hop 1 172.4.1.2 Label 1033
Hop 2 5.5.5.9 Label 1033
Hop 3 172.5.1.1

Hop 4 172.5.1.2 Label 3

Hop 5 3.3.3.9 Label 3
----End
Configuration Files
#
sysname LSRA
#
vlan batch 100 600
#
mpls lsr-id
1.1.1.9
mpls
mpls
te
mpls te auto-
frr
mpls rsvp-
te
mpls te cspf
#
explicit-path pri-
path
next hop
172.1.1.2
next hop
172.2.1.2
next hop
172.3.1.2
next hop 4.4.4.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
destination 4.4.4.9
mpls te priority 4 3
mpls te commit

#
ospf 1
area 0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.6.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls te auto-frr link
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255

mpls-te enable
#
return
#
sysname LSRC
#
vlan batch 200 300 500 700
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255

mpls-te enable
#
return
#
sysname LSRD
#
vlan batch 300
#
mpls lsr-id
4.4.4.9
mpls
mpls
te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.3.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#


#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9
0.0.0.0
network 172.4.1.0
0.0.0.255
network 172.5.1.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRF
#
vlan batch 600 700
#
mpls lsr-id 6.6.6.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 6.6.6.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 6.6.6.9
0.0.0.0
network 172.6.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255
mpls-te enable
#
return

5.24.15 Example for Configuring Association Between TE FRR

and CR-LSP Backup
As shown in Figure 5-49, a primary tunnel is set up by using the explicit path LSRA ->
LSRB -> LSRC -> LSRD. A bypass tunnel is set up on the transit node LSRB along the path
LSRB -> LSRE -> LSRC; an ordinary backup CR-LSP is set up on the ingress node LSRA
along the path LSRA -> LSRF -> LSRC -> LSRD.
When the link between LSRB and LSRC is faulty, the device starts the bypass tunnel (that is,
the primary CR-LSP is in FRR-in-use state) and tries to restore the primary CR-LSP. At the
same time, the system attempts to set up a backup CR-LSP.
NOTE
Figure 5-49 Networking of association between TE FRR and CR-LSP backup

Loopback1 Loopback1
6.6.6.9/32 4.4.4.9/32
GE0/0/1
VLANIF600 LSRF LSRD
172.6.1.2/24
GE0/0/2 GE0/0/1
VLANIF700 VLANIF300
GE0/0/2 172.7.1.1/24
VLANIF600 172.3.1.2/24
GE0/0/2
172.6.1.1/24 VLANIF300
Loopback1 Loopback1 172.3.1.1/24 Loopback1
1.1.1.9/32 GE0/0/1 2.2.2.9/32 GE0/0/2 GE0/0/4 3.3.3.9/32
VLANIF100 VLANIF200 VLANIF700
172.1.1.2/24 172.2.1.1/24 172.7.1.2/24

VLANIF100 VLANIF200
LSRA GE0/0/3 172.2.1.2/24 GE0/0/3
172.1.1.1/24 VLANIF400 VLANIF500
Loopback1
172.4.1.1/24 5.5.5.9/32 172.5.1.2/24
GE0/0/1 GE0/0/2
VLANIF400 VLANIF500
172.4.1.2/24 172.5.1.1/24
Primary CR-LSP LSRE

4. Enable TE FRR on the interface of the primary tunnel on the ingress node.
5. On the ingress node LSRB, configure a bypass tunnel along the path LSRB -> LSRE ->
LSRC to protect the link between LSRB and LSRC.
6. On the ingress node, set up an ordinary backup CR-LSP along the path LSRA -> LSRF -
> LSRC -> LSRD.
7. On the ingress node, configure association between the bypass tunnel and the backup
CR-LSP in the view of the interface of the primary tunnel.
Procedure
# Configure LSRA. Configure IP addresses for interfaces on LSRB, LSRC, LSRD, LSRE,
and LSRF according to Figure 5-49. The configurations of LSRB, LSRC, LSRD, LSRE, and
LSRF are similar to the configuration of LSRA, and are not mentioned here.
[LSRA] ospf 1
[LSRA-ospf-1] quit
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 172.1.1.2 Vlanif100
3.3.3.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
OSPF 10 2 D 172.6.1.2 Vlanif600

4.4.4.9/32 OSPF 10 3 D 172.1.1.2 Vlanif100

OSPF 10 3 D 172.6.1.2 Vlanif600
5.5.5.9/32 OSPF 10 2 D 172.1.1.2 Vlanif100
6.6.6.9/32 OSPF 10 1 D 172.6.1.2 Vlanif600
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.3.1.0/24 OSPF 10 3 D 172.1.1.2 Vlanif100
OSPF 10 3 D 172.6.1.2 Vlanif600
172.4.1.0/24 OSPF 10 2 D 172.1.1.2 Vlanif100
172.5.1.0/24 OSPF 10 3 D 172.1.1.2 Vlanif100
OSPF 10 3 D 172.6.1.2 Vlanif600
172.6.1.0/24 Direct 0 0 D 172.6.1.1 Vlanif600
172.6.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif600
172.7.1.0/24 OSPF 10 2 D 172.6.1.2 Vlanif600
to the configuration of LSRA, and are not mentioned here. CSPF only needs to be configured
on the ingress nodes of the primary tunnel and bypass tunnel. That is, CSPF needs to be
enabled on only LSRA and LSRB.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

[LSRA] ospf
[LSRA-ospf-1] quit




# Enable TE FRR.
[LSRA-Tunnel1] quit
Description:
...
Step 5 Configure a bypass CR-LSP on LSRB that functions as the PLR.
# Configure the explicit path of the bypass CR-LSP.

[LSRB] explicit-path by-path
[LSRB-explicit-path-by-path] quit
# Configure a tunnel interface of the bypass CR-LSP.

[LSRB] interface tunnel 2
[LSRB-Tunnel2] ip address unnumbered interface loopback 1
[LSRB-Tunnel2] tunnel-protocol mpls te
[LSRB-Tunnel2] destination 3.3.3.9
[LSRB-Tunnel2] mpls te tunnel-id 300
[LSRB-Tunnel2] mpls te path explicit-path by-path
[LSRB-Tunnel2] mpls te bypass-tunnel
# Bind the bypass CR-LSP to the protected interface.

[LSRB-Tunnel2] mpls te protected-interface vlanif 200
[LSRB-Tunnel2] mpls te commit
[LSRB-Tunnel2] quit
Run the display mpls lsp command on all the LSRs. You can view the LSP entry and that two
LSPs pass through LSRB and LSRC. The display on LSRB is used as an example.
[LSRB] display mpls lsp
-------------------------------------------------------------------------------
LSP Information: RSVP LSP
-------------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
4.4.4.9/32 1059/1068 Vlanif100/Vlanif200
3.3.3.9/32 NULL/1036 -/Vlanif400
establishment and that two tunnels pass through LSRB and LSRC. The display on LSRB is
used as an example.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.9 4.4.4.9 40 1059/1068 T Tunnel1
2.2.2.9 3.3.3.9 4 --/1036 I Tunnel2

that the bypass tunnel is bound to the outbound interface VLANIF200 and not in use.
No : 1
LSR Role : Transit
IncludeAllAff : 0x0
PSB Handle : 8200
Created Time : 2013-09-16 12:52:03+00:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
Step 6 On LSRA, create an MPLS TE tunnel for the ordinary backup CR-LSP.
# Configure the explicit path of the backup CR-LSP.


# Configure the backup CR-LSP on LSRA.

[LSRA-Tunnel1] mpls te backup ordinary
[LSRA-Tunnel1] mpls te path explicit-path backup-path secondary
[LSRA-Tunnel1] quit
Step 7 Configure association between TE FRR and CR-LSP on the ingress node of the primary CR-
LSP.
# Configure LSRA.
[LSRA-Tunnel1] mpls te backup frr-in-use
[LSRA-Tunnel1] quit
Run the display mpls te tunnel-interface Tunnel 1 command on the ingress node LSRA to
view information about the primary CR-LSR.
[LSRA] display mpls te tunnel-interface Tunnel 1
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------
Session ID : 100
# Shut down the protected outbound interface on the LSRB.

[LSRB] interface gigabitethernet 0/0/2
[LSRB-GigabitEthernet0/0/2] shutdown
[LSRB-GigabitEthernet0/0/2] quit
Run the display mpls te tunnel-interface command on the ingress node LSRA. You can see
that the tunnel status is Up. That is, the primary is in FRR in-use state and the ordinary CR-
LSP is being set up.
----------------------------------------------------------------
Tunnel1
----------------------------------------------------------------
Active LSP : Ordinary LSP
Session ID : 100
Modify LSP State : SETTING UP
Ordinary LSP State : UP
When the primary CR-LSP is faulty (that is, the primary CR-LSP is in FRR in-use state), the
system uses the TE FRR bypass tunnel and attempts to restore the primary CR-LSP. At the
same time, the system attempts to set up a backup CR-LSP.
----End

Configuration Files
#
sysname LSRA
#
vlan batch 100 600
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path backup-
path
next hop
172.6.1.2
next hop
172.7.1.2
next hop
172.3.1.2
next hop
4.4.4.9
#
explicit-path pri-
path
next hop
172.1.1.2
next hop
172.2.1.2
next hop
172.3.1.2
next hop 4.4.4.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
LoopBack1
te
destination
4.4.4.9
mpls te tunnel-id
100

label
path
secondary
mpls te fast-
reroute
mpls te backup
ordinary
mpls te backup frr-in-
use
mpls te commit
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.6.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
#
mpls lsr-id
2.2.2.9
mpls
mpls
te
mpls rsvp-
te
mpls te
cspf
#
explicit-path by-
path
next hop
172.4.1.2
next hop
172.5.1.2
next hop
3.3.3.9
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls

mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
interface Tunnel2
LoopBack1
te
destination
3.3.3.9
mpls te tunnel-id
300
mpls te record-
route
mpls te path explicit-path by-
path
mpls te bypass-
tunnel
mpls te commit
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
network 172.4.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
vlan batch 200 300 500 700
#
mpls lsr-id
3.3.3.9
mpls
mpls
te
mpls rsvp-te
#
interface Vlanif200

ip address 172.2.1.2 255.255.255.0

mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
network 172.7.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRD
#
vlan batch 300
#
mpls lsr-id
4.4.4.9

mpls
mpls
te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.3.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9
0.0.0.0
network 172.4.1.0
0.0.0.255

network 172.5.1.0 0.0.0.255

mpls-te enable
#
return
#
sysname LSRF
#
vlan batch 600 700
#
mpls lsr-id 6.6.6.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif600
ip address 172.6.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif700
ip address 172.7.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 6.6.6.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 6.6.6.9
0.0.0.0
network 172.6.1.0
0.0.0.255
network 172.7.1.0 0.0.0.255
mpls-te enable
#
return
5.24.16 Example for Configuring an MPLS TE Tunnel Protection

Group
As shown in Figure 5-50, two MPLS TE tunnels are set up between LSRA and LSRC. An
MPLS TE tunnel protection group needs to be configured for the working tunnel. The MPLS
TE mechanism is used to detect tunnel failures.
NOTE

Figure 5-50 Networking of MPLS TE tunnel protection group

Loopback1
5.5.5.9/32
GE0/0/1 GE0/0/2
VLANIF400 VLANIF500
172.4.1.2/24 LSRE 172.5.1.1/24
GE0/0/3 GE0/0/2
VLANIF400 VLANIF500
172.4.1.1/24 Loopback1 172.5.1.2/24
Loopback1 GE0/0/1 2.2.2.9/32 GE0/0/2 Loopback1
1.1.1.9/32 VLANIF100 VLANIF200 3.3.3.9/32
172.1.1.2/24 172.2.1.1/24
LSRA LSRC
GE0/0/1 GE0/0/1
VLANIF100 VLANIF200
172.1.1.1/24 LSRB 172.2.1.2/24
Primary CR-LSP
1. Assign IP addresses to interfaces and configure OSPF to ensure that public network
routes between the nodes are reachable.
2. Configure two MPLS TE tunnels for tunnel protection.
3. Configure an MPLS TE tunnel protection group. Specify the working tunnel and
protection tunnel.
Procedure
Step 1 Assign IP addresses to interfaces and configure OSPF on the LSRs.
# Configure LSRA. Assign IP addresses to interfaces of LSRB, LSRC, and LSRE according
to Figure 5-50. The configurations on these LSRs are similar to the configuration on LSRA,
and are not mentioned here.

[LSRA] ospf 1
[LSRA-ospf-1] quit
LSRs. You can see that the LSRs learn the routes of Loopback1 from each other.
Step 2 Configure basic MPLS capabilities and enable MPLS TE, RSVP-TE, and CSPF.
# Configure LSRA. The configurations on LSRB, LSRC, and LSRE are similar to the
configuration on LSRA, and are not mentioned here. CSPF needs to be enabled only on the
ingress of the working tunnel.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

# Configure LSRA. The configurations on LSRB, LSRC, and LSRE are similar to the
configuration on LSRA, and are not mentioned here.
[LSRA] ospf
[LSRA-ospf-1] quit
Step 4 Create two MPLS TE tunnels on the ingress node LSRA.

# Specify explicit paths for the two tunnels.
# Configure MPLS TE tunnel interfaces.



[LSRA-Tunnel1] quit
[LSRA-Tunnel2] mpls te path explicit-path backup-path
[LSRA-Tunnel2] quit
Run the display interface tunnel command on LSRA to check the tunnel status. The tunnel is
in Up state.
Description:
...
Step 5 Configure an MPLS TE tunnel protection group.

# On LSRA, configure Tunnel1 as a working tunnel and Tunnel2 as a protection tunnel.
Configure the two tunnels to work in revertive mode and set the WTR time to 2 minutes.
[LSRA-Tunnel1] mpls te protection tunnel 101 mode revertive wtr 4
[LSRA-Tunnel1] quit

Run the display mpls te protection tunnel 100 verbose command on LSRA to check
detailed information about the tunnel protection group.
[LSRA] display mpls te protection tunnel 100 verbose
----------------------------------------------------------------
Verbose information about the No.1 protection-group
----------------------------------------------------------------
Work-tunnel id : 100
Protect-tunnel id : 101
Work-tunnel name : Tunnel1
Protect-tunnel name : Tunnel2
Work-tunnel reverse-lsp : -
Protect-tunnel reverse-lsp : -
Bridge type : 1:1
Switch type : unidirectional
Switch result : work-tunnel
Tunnel using Best-Effort : none
Tunnel using Ordinary : none
Work-tunnel frr in use : none
Work-tunnel defect state : non-defect
Protect-tunnel defect state : non-defect
Work-tunnel forward-lsp defect state : non-defect
Protect-tunnel forward-lsp defect state : non-defect
Work-tunnel reverse-lsp defect state : non-defect
Protect-tunnel reverse-lsp defect state : non-defect
HoldOff config time : 0ms
HoldOff remain time : -
WTR remain time : -
Mode : revertive
Using same path : -
Local state : no request
Far end request : no request
# Run the tracert lsp te tunnel 1 command on LSRA to check the path of the working tunnel.


break.
0 Ingress 172.1.1.2/[4101 ]
1 172.1.1.2 7 ms Transit 172.2.1.2/[3 ]
2 3.3.3.9 3 ms Egress
Run the display mpls te protection tunnel all command on LSRA to check information
about the tunnel protection group.
[LSRA] display mpls te protection tunnel all
------------------------------------------------------------------------
No. Work-tunnel status /id Protect-tunnel status /id Switch-Result
------------------------------------------------------------------------
1 non-defect /100 non-defect /101 work-tunnel
# Run the shutdown command on GE0/0/1 of LSRA to simulate a failure of the working
tunnel.
After 5 seconds, run the tracert lsp te tunnel 1 command on LSRA again. You can see that
traffic has been switched to the protection tunnel.
break.
0 Ingress 172.4.1.2/[1028 ]
1 172.4.1.2 4 ms Transit 172.5.1.2/[3 ]
2 3.3.3.9 3 ms Egress
------------------------------------------------------------------------
------------------------------------------------------------------------
1 in defect /100 non-defect /101 protect-tunnel
----End
Configuration File
#
sysname LSRA
#
vlan batch 100 400
#
mpls lsr-id
1.1.1.9
mpls
mpls
te
mpls rsvp-
te
mpls te cspf
#
path
next hop

172.4.1.2
next hop
172.5.1.2
next hop 3.3.3.9
#
explicit-path pri-
path
next hop
172.1.1.2
next hop
172.2.1.2
next hop 3.3.3.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
LoopBack1
te
destination
3.3.3.9
mpls te tunnel-id
100
mpls te protection tunnel 101 mode revertive wtr
4
path
mpls te commit
#
interface
Tunnel2
LoopBack1
te
destination
3.3.3.9
mpls te tunnel-id
101
mpls te path explicit-path backup-
path
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.9

0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
vlan batch 200 500
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te

mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9

0.0.0.0
network 172.4.1.0
0.0.0.255
network 172.5.1.0 0.0.0.255
mpls-te enable
#
return
5.24.17 Example for Configuring Dynamic BFD for an MPLS TE

Tunnel Protection Group
As shown in Figure 5-51, two MPLS TE tunnels are set up between LSRA and LSRC. An
MPLS TE tunnel protection group needs to be configured for the working tunnel. Dynamic
BFD is used to detect CR-LSP failures.
NOTE
Figure 5-51 Networking of dynamic BFD for an MPLS TE tunnel protection group
Loopback1
5.5.5.9/32
GE0/0/1 GE0/0/2
VLANIF400 VLANIF500
172.4.1.2/24 LSRE 172.5.1.1/24
GE0/0/3 GE0/0/2
VLANIF400 VLANIF500
172.4.1.1/24 Loopback1 172.5.1.2/24
Loopback1 GE0/0/1 2.2.2.9/32 GE0/0/2 Loopback1
1.1.1.9/32 VLANIF100 VLANIF200 3.3.3.9/32
172.1.1.2/24 172.2.1.1/24
LSRA LSRC
GE0/0/1 GE0/0/1
VLANIF100 VLANIF200
172.1.1.1/24 LSRB 172.2.1.2/24
Primary CR-LSP
1. Configure an MPLS TE tunnel protection group.
2. On the ingress node of the working tunnel, enable active BFD session setup on the
tunnel interface. On the egress node of the working tunnel, enable passive BFD session
setup in the MPLS view.

Procedure
Step 1 Configure an MPLS TE tunnel protection group.
Configure an MPLS TE tunnel protection group by referring to 5.24.16 Example for
Configuring an MPLS TE Tunnel Protection Group.
Step 2 Configure dynamic BFD for the MPLS TE tunnel protection group.
# Configure LSRA.
[LSRA] bfd
[LSRA-bfd] quit
[LSRA-Tunnel1] mpls te bfd enable
[LSRA-Tunnel1] mpls te bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 3
[LSRA-Tunnel1] quit
# Configure LSRC.
[LSRC] bfd
[LSRC-bfd] mpls-passive
[LSRC-bfd] quit

Run the display mpls te protection tunnel 100 verbose command on LSRA to check
detailed information about the tunnel protection group.
[LSRA] display mpls te protection tunnel 100 verbose
----------------------------------------------------------------
Verbose information about the No.1 protection-group
----------------------------------------------------------------
Work-tunnel id : 100
Protect-tunnel id : 101
Work-tunnel name : Tunnel1
Protect-tunnel name : Tunnel2
Work-tunnel reverse-lsp : -
Protect-tunnel reverse-lsp : -
Bridge type : 1:1
Switch type : unidirectional
Switch result : work-tunnel
Tunnel using Best-Effort : none
Tunnel using Ordinary : none
Work-tunnel frr in use : none
Work-tunnel defect state : non-defect
Protect-tunnel defect state : non-defect
Work-tunnel forward-lsp defect state : non-defect
Protect-tunnel forward-lsp defect state : non-defect
Work-tunnel reverse-lsp defect state : non-defect
Protect-tunnel reverse-lsp defect state : non-defect
HoldOff config time : 0ms
HoldOff remain time : -
WTR remain time : -
Mode : revertive
Using same path : -
Local state : no request
Far end request : no request
# Run the tracert lsp te tunnel 1 command on LSRA to check the path of the working tunnel.
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C to br
eak.

0 Ingress 172.1.1.2/[4101 ]
1 172.1.1.2 7 ms Transit 172.2.1.2/[3 ]
2 3.3.3.9 3 ms Egress
------------------------------------------------------------------------
------------------------------------------------------------------------
1 non-defect /100 non-defect /101 work-tunnel
Run the display bfd session all command on LSRA. You can see that the BFD session is in
Up state.
[LSRA] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
8252 8245 3.3.3.9 Up D_TE_LSP Tunnel1
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
# Run the shutdown command on GE0/0/1 of LSRA to simulate a failure of the working
tunnel.
Run the tracert lsp te tunnel 1 command on LSRA again. You can see that traffic has been
switched to the protection tunnel.
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C to br
eak.
0 Ingress 172.4.1.2/[1028 ]
1 172.4.1.2 4 ms Transit 172.5.1.2/[3 ]
2 3.3.3.9 3 ms Egress
------------------------------------------------------------------------
------------------------------------------------------------------------
1 in defect /100 non-defect /101 protect-tunnel
----End
Configuration File
#
sysname LSRA
#
vlan batch 100 400
#
bfd
#
mpls lsr-id
1.1.1.9
mpls

mpls
te
mpls rsvp-
te
mpls te cspf
#
path
next hop
172.4.1.2
next hop
172.5.1.2
next hop 3.3.3.9
#
explicit-path pri-
path
next hop
172.1.1.2
next hop
172.2.1.2
next hop 3.3.3.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
LoopBack1
te
destination
3.3.3.9
mpls te tunnel-id
100
mpls te protection tunnel 101 mode revertive wtr
4
mpls te bfd
enable
mpls te bfd min-tx-interval 100 min-rx-interval 100
path
mpls te commit
#
interface
Tunnel2
LoopBack1
te

destination
3.3.3.9
mpls te tunnel-id
101
mpls te path explicit-path backup-
path
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.4.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.2.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRC

#
vlan batch 200 500
#
bfd
mpls-
passive
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRE
#
vlan batch 400 500
#
mpls lsr-id 5.5.5.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te

mpls te srlg 2
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9
0.0.0.0
network 172.4.1.0
0.0.0.255
network 172.5.1.0 0.0.0.255
mpls-te enable
#
return
5.24.18 Example for Configuring Static BFD for CR-LSPs

Figure 5-52 shows an MPLS network. A TE tunnel with LSRA as the ingress node and LSRC
as the egress node needs to be established on LSRA. A hot-standby CR-LSP and best-effort
path also need to be configured.
primary CR-LSP and backup CR-LSP fail, traffic switches to the best-effort path. Explicit
paths can be configured for the primary and backup CR-LSPs. A best-effort path can be
generated automatically. In this example, the best-effort path is LSRA -> LSRD -> LSRB ->
LSRC. The calculated best-effort path varies according to the faulty node.
Two static BFD sessions need to be configured to detect primary and backup CR-LSPs:
l When the primary CR-LSP fails, traffic fast switches to the backup CR-LSP.
l When the backup CR-LSP fails within 15 seconds after the primary CR-LSP recovers,
traffic switches back to the primary CR-LSP.
NOTE

Figure 5-52 Networking of static BFD for CR-LSPs

Loopback1 Loopback1
2.2.2.9/32 GE0/0/3 GE0/0/3 4.4.4.9/32
VLANIF400 VLANIF400
172.4.1.1/24 172.4.1.2/24
LSRB LSRD
GE0/0/2 GE0/0/2
VLANIF100 172.2.1.1/24 172.5.1.2/24 VLANIF300
172.1.1.2/24 172.3.1.2/24
GE0/0/1 GE0/0/1
VLANIF100 VLANIF300
172.1.1.1/24 172.3.1.1 /24
GE0/0/2 GE0/0/2
172.5.1.1/24 172.2.1.2/24
Loopback1 Loopback1
1.1.1.9/32 3.3.3.9/32

1. Configure a hot-standby CR-LSP and best-effort path.
2. Create two BFD sessions on the ingress node and bind them to CR-LSPs to detect
primary and backup CR-LSPs. Configure two BFD sessions on the egress node and bind
them to IP addresses (ensure that the route from LSRC to LSRA is reachable).
Procedure
Step 1 Configure a hot-standby CR-LSP and best-effort path.
Configure the primary CR-LSP, backup CR-LSP, and best-effort path according to 5.24.12
Example for Configuring CR-LSP Hot Standby.
Step 2 Configure static BFD for CR-LSPs.
Establish BFD sessions between LSRA and LSRC to detect faults on primary and backup CR-
LSPs. Bind the BFD session on LSRA to the CR-LSP and BFD session on LSRC to the IP
address. Set the intervals for sending and receiving BFD packets to 500 ms and the local
detection multiplier of BFD to 3.
# Configure LSRA.
[LSRA] bfd
[LSRA-bfd] quit
[LSRA] bfd prilsp2lsrc bind mpls-te interface tunnel 1 te-lsp

[LSRA-bfd-lsp-session-prilsp2lsrc] discriminator local 139

[LSRA-bfd-lsp-session-prilsp2lsrc] discriminator remote 239
[LSRA-bfd-lsp-session-prilsp2lsrc] min-tx-interval 500
[LSRA-bfd-lsp-session-prilsp2lsrc] min-rx-interval 500
[LSRA-bfd-lsp-session-prilsp2lsrc] detect-multiplier 3
[LSRA-bfd-lsp-session-prilsp2lsrc] process-pst
[LSRA-bfd-lsp-session-prilsp2lsrc] notify neighbor-down
[LSRA-bfd-lsp-session-prilsp2lsrc] commit
[LSRA-bfd-lsp-session-prilsp2lsrc] quit
[LSRA] bfd backuplsp2lsrc bind mpls-te interface tunnel 1 te-lsp backup
[LSRA-bfd-lsp-session-backuplsp2lsrc] discriminator local 339
[LSRA-bfd-lsp-session-backuplsp2lsrc] discriminator remote 439
[LSRA-bfd-lsp-session-backuplsp2lsrc] min-tx-interval 500
[LSRA-bfd-lsp-session-backuplsp2lsrc] min-rx-interval 500
[LSRA-bfd-lsp-session-backuplsp2lsrc] detect-multiplier 3
[LSRA-bfd-lsp-session-backuplsp2lsrc] process-pst
[LSRA-bfd-lsp-session-backuplsp2lsrc] notify neighbor-down
[LSRA-bfd-lsp-session-backuplsp2lsrc] commit
[LSRA-bfd-lsp-session-backuplsp2lsrc] quit
# Configure LSRC.
[LSRC] bfd
[LSRC-bfd] quit
[LSRC] bfd reversepri2lsra bind peer-ip 1.1.1.9
[LSRC-bfd-session-reversepri2lsra] discriminator local 239
[LSRC-bfd-session-reversepri2lsra] discriminator remote 139
[LSRC-bfd-session-reversepri2lsra] min-tx-interval 500
[LSRC-bfd-session-reversepri2lsra] min-rx-interval 500
[LSRC-bfd-session-reversepri2lsra] detect-multiplier 3
[LSRC-bfd-session-reversepri2lsra] commit
[LSRC-bfd-session-reversepri2lsra] quit
[LSRC] bfd reversebac2lsra bind peer-ip 1.1.1.9
[LSRC-bfd-session-reversebac2lsra] discriminator local 439
[LSRC-bfd-session-reversebac2lsra] discriminator remote 339
[LSRC-bfd-session-reversebac2lsra] min-tx-interval 500
[LSRC-bfd-session-reversebac2lsra] min-rx-interval 500
[LSRC-bfd-session-reversebac2lsra] detect-multiplier 3
[LSRC-bfd-session-reversebac2lsra] commit
[LSRC-bfd-session-reversebac2lsra] quit
After the configurations are complete, run the display bfd session discriminator command
on LSRA and LSRC. You can see that the BFD session status is Up.
[LSRA] display bfd session discriminator 139
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
139 239 3.3.3.9 Up S_TE_LSP Tunnel1
--------------------------------------------------------------------------------
[LSRA] display bfd session discriminator 339

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
339 439 3.3.3.9 Up S_TE_LSP Tunnel1
--------------------------------------------------------------------------------

LSRA or LSRB is removed, traffic fast switches to the backup CR-LSP at the millisecond
level.
After the cable is inserted into GE0/0/1, run the display mpls te tunnel-interface tunnel 1
command to view tunnel information until the primary CR-LSP is set up. Then remove the

cable from GE0/0/2 on LSRA or LSRD within 15s. You can see that traffic switches back to
the primary CR-LSP at the millisecond level.
----End
Configuration Files
#
sysname LSRA
#
vlan batch 100 500
#
bfd
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 172.5.1.2
next hop 172.3.1.1
next hop 3.3.3.9
#
next hop 172.1.1.2
next hop 172.2.1.2
next hop 3.3.3.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
te
destination
3.3.3.9
mpls te tunnel-id
100
mpls te record-
route
path
secondary


15
effort
mpls te commit
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te enable
#
bfd backuplsp2lsrc bind mpls-te interface Tunnel1 te-lsp backup
discriminator local
339
discriminator remote
439
min-tx-interval
500
min-rx-interval
500
process-
pst
notify neighbor-down
commit
bfd prilsp2lsrc bind mpls-te interface Tunnel1 te-lsp

discriminator local
139
239
min-tx-interval
500
min-rx-interval
500
process-
pst
notify neighbor-down
commit
#
return
#
sysname LSRB
#
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#

interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
vlan batch 200 300
#
bfd
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#

#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bfd reversebac2lsra bind peer-ip
1.1.1.9
discriminator local
439
339
min-tx-interval
500
min-rx-interval
500
commit
bfd reversepri2lsra bind peer-ip

1.1.1.9
discriminator local
239
139
min-tx-interval
500
min-rx-interval
500
commit
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0
0.0.0.255
mpls-te
enable
#
return
#
sysname LSRD
#
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls

mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.3.1.0
0.0.0.255
network 172.4.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te
enable
#
return
5.24.19 Example for Configuring Dynamic BFD for CR-LSPs
Figure 5-53 shows an MPLS network. A TE tunnel with LSRA as the ingress node and LSRC
as the egress node needs to be established on LSRA. A hot-standby CR-LSP and best-effort
path also need to be configured.
primary CR-LSP and backup CR-LSP fail, traffic switches to the best-effort path. Explicit
paths can be configured for the primary and backup CR-LSPs. A best-effort path can be
generated automatically. In this example, the best-effort path is LSRA -> LSRD -> LSRB ->
LSRC. The calculated best-effort path varies according to the faulty node.
Dynamic BFD for CR-LSPs needs to be configured to detect primary and backup CR-LSPs:
l When the primary CR-LSP fails, traffic fast switches to the backup CR-LSP.

l When the backup CR-LSP fails within 15 seconds after the primary CR-LSP recovers,
traffic switches back to the primary CR-LSP.
NOTE
Figure 5-53 Networking of dynamic BFD for CR-LSPs

Loopback1 Loopback1
2.2.2.9/32 GE0/0/3 GE0/0/3 4.4.4.9/32
VLANIF400 VLANIF400
172.4.1.1/24 172.4.1.2/24
LSRB LSRD
GE0/0/2 GE0/0/2
VLANIF100 172.2.1.1/24 172.5.1.2/24 VLANIF300
172.1.1.2/24 172.3.1.2/24
GE0/0/1 GE0/0/1
VLANIF100 VLANIF300
172.1.1.1/24 172.3.1.1 /24
GE0/0/2 GE0/0/2
172.5.1.1/24 172.2.1.2/24
Loopback1 Loopback1
1.1.1.9/32 3.3.3.9/32

NOTE
Compared with static BFD, dynamic BFD is much easier to configure. In addition, dynamic BFD can
reduce the number of BFD sessions, and use less network resources because only one BFD session can
be created on a tunnel interface.
1. Configure a hot-standby CR-LSP and best-effort path.
2. Enable BFD on the ingress node, configure dynamic BFD for CR-LSPs, and set the
intervals for sending and receiving BFD packets and local BFD detection multiplier.
3. Enable the capability to passively create BFD sessions on the egress node.

Procedure
Step 1 Configure a hot-standby CR-LSP and best-effort path.
Configure the primary CR-LSP, backup CR-LSP, and best-effort path according to 5.24.12
Example for Configuring CR-LSP Hot Standby.
Step 2 Configure dynamic BFD for CR-LSPs on the ingress node.
Configure dynamic BFD for CR-LSPs, and set the intervals for sending and receiving BFD
packets to 500 ms and local BFD detection multiplier to 3.
# Configure LSRA.
[LSRA] bfd
[LSRA-bfd] quit
[LSRA-Tunnel1] mpls te bfd enable
[LSRA-Tunnel1] mpls te bfd min-tx-interval 500 min-rx-interval 500 detect-
multiplier 3
Step 3 Enable the capability to passively create BFD sessions on the egress node.
# Configure LSRC.
[LSRC] bfd
[LSRC-bfd] mpls-passive
[LSRC-bfd] quit
After the configurations are complete, run the display bfd session mpls-te interface Tunnel
1 te-lsp command on LSRA. You can see that the BFD session status is Up.
[LSRA] display bfd session mpls-te interface Tunnel 1 te-lsp
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
8192 8192 3.3.3.9 Up D_TE_LSP Tunnel1
--------------------------------------------------------------------------------
Run the display bfd session passive-dynamic command on LSRC. You can see that a BFD
session is created passively.
[LSRC] display bfd session passive-dynamic
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
8192 8192 1.1.1.9 Up E_Dynamic -
--------------------------------------------------------------------------------

LSRA or LSRB is removed, traffic fast switches to the backup CR-LSP at the millisecond
level.
After the cable is inserted into GE0/0/1, run the display mpls te tunnel-interface tunnel 1
command to view tunnel information until the primary CR-LSP is set up. Then remove the
cable from GE0/0/2 on LSRA or LSRD within 15s. You can see that traffic switches back to
the primary CR-LSP at the millisecond level.
----End

Configuration Files
#
sysname LSRA
#
vlan batch 100 500
#
bfd
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 172.5.1.2
next hop 172.3.1.1
next hop 3.3.3.9
#
next hop 172.1.1.2
next hop 172.2.1.2
next hop 3.3.3.9
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel1
te
destination
3.3.3.9
mpls te tunnel-id
100
mpls te bfd
enable
mpls te bfd min-tx-interval 500 min-rx-interval 500
mpls te record-
route
path
secondary
15

effort
mpls te commit
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te enable
#
return
#
sysname LSRB
#
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255

mpls-te enable
#
return
#
sysname LSRC
#
vlan batch 200 300
#
bfd
mpls-passive
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300
ip address 172.3.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0
0.0.0.255
mpls-te
enable
#
return
#
sysname LSRD
#
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
#
interface Vlanif300

ip address 172.3.1.2 255.255.255.0

mpls
mpls te
mpls rsvp-te
#
interface Vlanif400
ip address 172.4.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Vlanif500
ip address 172.5.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
#
#
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.3.1.0
0.0.0.255
network 172.4.1.0
0.0.0.255
network 172.5.1.0
0.0.0.255
mpls-te
enable
#
return
5.24.20 Example for Configuring RSVP GR

As shown in Figure 5-54, an enterprise has its own MPLS backbone network. LSRA, LSRB,
and LSRC are devices on the backbone network.Each LSR is a stack system. The IS-IS
protocol is used to implement IP interworking. A TE tunnel from LSRA to LSRC is set up on
the network.
The enterprise wants to ensure uninterrupted data forwarding during an active/standby
switchover on LSRA, LSRB, or LSRC.

Figure 5-54 Networking of RSVP GR

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE0/0/1 GE0/0/1 GE0/0/2 GE0/0/1
172.1.1.1/24 172.1.1.2/24 172.2.1.1/24 172.2.1.2/24
LSRA LSRB LSRC
RSVP GR can be configured on the network to ensure uninterrupted data forwarding during
an active/standby switchover.
1. Configure IS-IS to ensure that routes between backbone nodes are reachable.
2. Enable MPLS TE and RSVP TE on the backbone nodes so that they can set up MPLS
TE tunnels.
3. Enable IS-IS TE and change the cost type to enable the nodes to advertise TE
information using IS-IS.
4. On the ingress node, create a tunnel interface and configure tunnel attributes on the
tunnel interface. Enable MPLS TE CSPF to dynamically set up MPLS TE tunnels.
5. Configure IS-IS GR and RSVP GR on each node to ensure uninterrupted data
forwarding during an active/standby switchover.
Procedure
# Configure LSRA. Assign IP addresses to interfaces of LSRB and LSRC according to
Figure 5-54. The configurations on LSRB and LSRC are similar to the configuration on

# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] quit


# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] network-entity 00.0005.0000.0000.0002.00
[LSRB-isis-1] is-level level-2
[LSRB-isis-1] quit
[LSRB] interface loopback 1
[LSRB-LoopBack1] isis enable 1
[LSRB-LoopBack1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] network-entity 00.0005.0000.0000.0003.00
[LSRC-isis-1] is-level level-2
[LSRC-isis-1] quit
[LSRC-Vlanif200] isis enable 1
[LSRC] interface loopback 1
[LSRC-LoopBack1] isis enable 1
[LSRC-LoopBack1] quit
Run the display ip routing-table command on the LSRs, and you can see that they learn the
routes from each other. The command output on LSRA is provided as an example:
------------------------------------------------------------------------------

2.2.2.9/32 ISIS-L2 15 10 D 172.1.1.2 Vlanif100
3.3.3.9/32 ISIS-L2 15 20 D 172.1.1.2 Vlanif100
172.1.1.0/24 Direct 0 0 D 172.1.1.1 Vlanif100
172.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif100
172.2.1.0/24 ISIS-L2 15 20 D 172.1.1.2 Vlanif100
Step 3 Configure basic MPLS capabilities, enable MPLS TE and RSVP TE.
Enable MPLS, MPLS TE, RSVP-TE globally on the LSRs and on the interfaces that the
tunnel passes through.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit


Step 4 Configure IS-IS TE and enable IS-IS GR.

[LSRA] isis 1
[LSRA-isis-1] graceful-restart
[LSRA-isis-1] quit
Step 5 Configure an MPLS TE tunnel interface and enable MPLS TE CSPF.

On the ingress of the tunnel, create a tunnel interface and set the IP address, tunneling
protocol, destination IP address, tunnel ID, and dynamic signaling protocol for the tunnel
interface. Then, run the mpls te commit command to commit the configuration.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] quit
[LSRA-Tunnel1] quit
Run the display interface tunnel command on LSRA. You can see that the tunnel interface is
Up.
[LSRA] display interface tunnel
Description:
...
Step 6 Configure RSVP GR.

[LSRA] mpls
[LSRA-mpls] mpls rsvp-te hello
[LSRA-mpls] mpls rsvp-te hello full-gr
[LSRA-mpls] quit
[LSRA-Vlanif100] mpls rsvp-te hello

After the configurations are complete, run the display mpls rsvp-te graceful-restart
command on LSRA to view the local GR status, restart time, and recovery time.
[LSRA] display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 1.1.1.9

Graceful-Restart Capability: GR-Self GR-Support

Restart Time: 90060 Milli Second
Recovery Time: 0 Milli Second
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr Path message count: 0
Send Gr Path message count: 0
Received RecoveryPath message count: 0
Send RecoveryPath message count: 0
Run the display mpls rsvp-te graceful-restart peer command on LSRA to view the GR
status of the neighboring node.
[LSRA] display mpls rsvp-te graceful-restart peer
Neighbor on Interface Vlanif100
Neighbor Addr: 172.1.1.2 Last Attribute: Added Usually
SrcInstance: 0x7C832B3D NbrSrcInstance: 0x6A48E0F5
Neighbor Capability:
Can Do Self GR
Can Support GR
GR Status: Normal
Restart Time: 90015 Millisecond
Recovery Time: 0 Millisecond
Stored GR message number: 0
Total to be Recover PSB Count: 0 Recovered PSB Count: 0
Total to be Recover RSB Count: 0 Recovered RSB Count: 0
P2MP PSB Count: 0 P2MP RSB Count: 0
Total to be Recover P2MP PSB Count: 0 Recovered P2MP PSB Count: 0
Total to be Recover P2MP RSB Count: 0 Recovered P2MP RSB Count: 0
----End
Configuration File
#
sysname LSRA
#
vlan batch 100
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls rsvp-te hello full-gr
mpls te cspf
#
isis 1
graceful-restart
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#

#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.9
mpls te commit
#
return
#
sysname LSRB
#
vlan batch 100 200
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
isis 1
graceful-restart
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
interface Vlanif100
ip address 172.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface Vlanif200
ip address 172.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
#
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname LSRC
#
vlan batch 200
#

mpls lsr-id 3.3.3.9

mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
isis 1
graceful-restart
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
interface Vlanif200
ip address 172.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
5.25 References for MPLS TE

The following table lists the references for MPLS TE.
Document Description
No.
RFC 2205 Resource ReSerVation Protocol
RFC 2209 Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing

Rules
RFC 2370 The OSPF Opaque LSA Option
RFC 2547 BGP/MPLS VPNs
RFC 2702 Requirements for Traffic Engineering Over MPLS
RFC 2747 RSVP Cryptographic Authentication
RFC 2961 RSVP Refresh Overhead Reduction Extensions
RFC 3031 Multiprotocol Label Switching Architecture
RFC 3032 MPLS Label Stack Encoding
RFC 3034 Use of Label Switching on Frame Relay Networks Specification
RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels

Document Description
No.
RFC 3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling

Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions
RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2
RFC 3784 Intermediate System to Intermediate System (IS-IS) Extensions for

Traffic Engineering (TE)
RFC 4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic

Engineering
RFC 4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS
Traffic Engineering
RFC 4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-

aware MPLS Traffic Engineering: Performance Evaluation
RFC 4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and
Extensions for Automatically Switched Optical Network (ASON)
RFC 4090 Fast Reroute Extensions t o RSVP-TE for LSP Tunnels
draft-ietf-mpls- Definition of an RRO node-id subobject

nodeid-
subobject-01
draft-ietf-tewg- Protocol extensions for support of Diff-Serv-aware MPLS Traffic

diff-te-proto-02 Engineering
draft-ietf-mpls- Requirements for support of Diff-Serv-aware MPLS Traffic Engineering

diff-te-reqts-00
draft-ietf-mpls- MPLS Support of Differentiated Services

diff-ext-07

01-05 MPLS TE Configuration

Uploaded by

Copyright:

Available Formats

01-05 MPLS TE Configuration

Uploaded by

Document Information

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

01-05 MPLS TE Configuration

Uploaded by

Copyright:

Available Formats

S5700 and S6720 Series Ethernet Switches

Configuration Guide - MPLS 5 MPLS TE Configuration

About This Chapter

5.1 Overview of MPLS TE

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 271

5.20 Configuring Dynamic BFD for CR-LSPs

5.1 Overview of MPLS TE

Figure 5-1 Traditional routing mechanism

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 272

Figure 5-2 MPLS TE

Switch_7 Switch_3 Path 1

Switch_5 Path 2 Switch_6

5.2 Understanding MPLS TE

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 273

Figure 5-3 MPLS TE tunnel and LSP

LSRF LSRG LSRH

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 274

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 275

Figure 5-4 Strict explicit path

Figure 5-5 Loose explicit path

LSRA LSRB LSRD LSRF

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 276

Figure 5-6 Before a link failure occurs

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 277

Figure 5-7 After preemption is triggered

A new path is set up for Tunnel 1 as follows:

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 278

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 279

Figure 5-8 MPLS TE framework

IGP route LSP route

Protocol packet exchanging

MPLS TE is implemented based on four functions:

Table 5-1 describes the four functions.

Table 5-1 Functions for MPLS TE implementation

1 Informatio Collects network load information in addition to routing information.

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 280

3 Path setup Sets up a static or dynamic CR-LSP.

5.2.3 Information Advertisement

What Information Is Advertised

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 281

l Bandwidth information: includes the maximum link bandwidth, maximum reservable

How Information Is Advertised

Figure 5-9 Opaque LSA format

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 282

Figure 5-10 TLV structure

– Type: indicates the type of information carried in the TLV.

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 283

Figure 5-11 TE LSA structure

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 284

Table 5-2 Sub-TLVs in a Link TLV

Type 1: Link Type (with a 1-byte Carries a link type.

Type 3: Local IP Address (with a Carries one or more local interface IP

Type 4: Remote IP Address (with a Carries one or more remote interface IP

Type 5: Traffic Engineering Metric Carries the TE metric configured on a TE link.

Type 6: Maximum Bandwidth (with Carries the maximum bandwidth of a link.

Type 7: Maximum Reservable Carries the maximum reservable bandwidth of

Type 9: Administrative Group (with Carries the administrative group attribute of a

If an OSPF-capable link that has established an OSPF neighbor relationship is identified

Issue 05 (2018-12-17) Copyright © Huawei Technologies Co., Ltd. 285

IS-IS TE defines two new TLV types: