01-03 MPLS TE Configuration

HUAWEI NetEngine40E Universal Service Router
Configuration Guide - MPLS 3 MPLS TE Configuration
3 MPLS TE Configuration
About This Chapter
This chapter describes the principles for Multiprotocol Label Switching Traffic Engineering
(MPLS TE), Resource Reservation Protocol (RSVP) TE tunnels, RSVP signaling parameter
adjustment, RSVP authentication, tunnel parameter adjustment, measures for adjusting TE
forwarding, the bandwidth flood threshold, tunnel re-optimization, MPLS TE fast reroute
(FRR), MPLS TE Auto FRR, constraints-routed label switched path (CR-LSP) backup,
isolated LSP computation, RSVP graceful restart (GR), static bidirectional forwarding
detection (BFD) for CR-LSP, dynamic BFD for CR-LSP, MPLS TE distribution, and how to
configure MPLS TE, and provides configuration examples.
3.1 Overview of MPLS TE

The Multiprotocol Label Switching Traffic Engineering (MPLS TE) technology integrates the
MPLS technology with TE. It reserves resources by establishing label switched paths (LSPs)
over a specified path in an attempt to prevent network congestion and balance network traffic.
3.2 Licensing Requirements and Limitations for MPLS TE
3.3 Configuring Static CR-LSP
This section describes how to configure a static CR-LSP. The configuration of a static CR-
LSP is simple, and label allocation is performed manually, not by using a signaling protocol to
exchange control packets, which consumes a few resources.
3.4 Configuring a Static Bidirectional Co-routed LSP
A static bidirectional co-routed label switched path (LSP) is composed of two static
constraint-based routed (CR) LSPs in opposite directions. Multiprotocol Label Switching
(MPLS) Traffic Engineering (TE) supports MPLS forwarding in both directions along such an
LSP.
3.5 Configuring an Associated Bidirectional CR-LSP
Associated bidirectional CR-LSPs provide bandwidth protection for bidirectional services.
Bidirectional switching can be performed for associated bidirectional CR-LSPs if faults occur.
3.6 Configuring an RSVP-TE Tunnel
MPLS TE reserves resources for RSVP-TE tunnels. These tunnels are established along
specified paths, not passing through congested nodes, balancing traffic on a network.
3.7 Configuring an Automatic RSVP-TE Tunnel
Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 22

Automatic RSVP-TE tunnels are generated using the PCE Initiated LSP protocol. Such
tunnels do not need to be manually configured.
3.8 Configuring PCE+ to Calculate Paths for MPLS TE Tunnels
The PCE function is used to calculate a path over which an MPLS TE tunnel is established,
which more efficiently uses network resources than constrained shortest path first (CSPF).
3.9 Configuring the IP-Prefix Tunnel Function
The ip-prefix tunnel function can be configured and used to establish P2P TE tunnels in a
batch, which simplifies the configuration.
3.10 Configuring Dynamic Bandwidth Reservation
This section describes how to configure dynamic bandwidth reservation on an MPLS TE
interface. This configuration enables the MPLS TE interface dynamically reserve bandwidth
for an MPLS TE tunnel to account for the fact that physical bandwidth is variable.
3.11 Configuring P2MP TE Tunnels
A P2MP TE tunnel provides sufficient network bandwidth and high reliability for multicast
service transmission on an IP/MPLS backbone network.
3.12 Adjusting RSVP Signaling Parameters
RSVP-TE supports various signaling parameters, which meet requirements for reliability and
network resources, and requirements of MPLS TE advanced functions.
3.13 Configuring RSVP Authentication
RSVP authentication is configured to protect a node from attacks and improve network
security. By default, no authentication mode is configured. Configuring RSVP authentication
is recommended to improve device security.
3.14 Adjusting Parameters for Establishing an MPLS TE Tunnel
Multiple attributes are used to establish MPLS TE tunnels flexibly.
3.15 Importing Traffic to an MPLS TE Tunnel
Before importing traffic to an MPLS TE tunnel, familiarize yourself with the usage scenario,
complete the pre-configuration tasks for the configuration.
3.16 Configuring the Limit Rate of MPLS TE Traffic
This section describes how to configure the limit rate of MPLS TE traffic to limit TE tunnel
traffic within the bandwidth range that is actually configured.
3.17 Configuring Bandwidth Information Flooding for MPLS TE
If the link bandwidth changes slightly, the threshold for flooding bandwidth information is set
on the ingress or a transit node of a CR-LSP, which reduces flooding attempts and saves
network resources.
3.18 Configuring Tunnel Re-optimization
Tunnel re-optimization is configured to allow a device to dynamically adjust paths for tunnels.
3.19 Configuring Automatic Tunnel Bandwidth Adjustment
This section describes how to configure the automatic adjustment of the tunnel bandwidth.
3.20 Locking the Tunnel Configuration
Tunnel configurations can be locked by the controller when the configurations are sent to a
NE40E.
3.21 Configuring DS-TE
This feature combines traditional TE tunnels with the DiffServ model to provide QoS
guarantee based on service types.

3.22 Configuring MPLS TE Manual FRR

MPLS TE manual FRR is a local protection mechanism that protects traffic on a link or a
node on a CR-LSP.
3.23 Configuring MPLS TE Auto FRR
MPLS TE Auto FRR is a local protection mechanism that protects traffic on a link or a node
on a CR-LSP.
3.24 Configuring MPLS Detour FRR
MPLS detour FRR automatically creates a detour LSP on each eligible node along primary
CR-LSP to protect downstream links or nodes.
3.25 Configuring P2MP TE FRR
P2MP TE fast reroute (FRR) provides local link protection for a P2MP TE tunnel. It
establishes a bypass tunnel to protect sub-LSPs. If a link fails on the P2MP TE tunnel, traffic
switches to the bypass tunnel within 50 milliseconds, which increases tunnel reliability.
3.26 Configuring P2MP TE Auto FRR
Auto fast reroute (FRR) is a local protection mechanism in MPLS TE. Auto FRR deployment
is easier than manual FRR deployment.
3.27 Configuring CR-LSP Backup
CR-LSP backup is configured to provide end-to-end protection for a CR-LSP.
3.28 Configuring a Tunnel Protection Group
This section describes how to configure a tunnel protection group. A 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.
3.29 Configuring Isolated LSP Computation
To improve label switched path (LSP) reliability on a network that has the constraint-based
routed label switched path (CR-LSP) hot standby feature, you can configure the isolated LSP
computation feature so that the device uses both the disjoint algorithm and the constrained
shortest path first (CSPF) algorithm to compute isolated primary and hot-standby LSPs.
3.30 Configuring an RSVP GR Helper
An RSVP GR Helper is configured to allow devices along an RSVP-TE tunnel to retain
RSVP sessions during a master/backup switchover.
3.31 Configuring the Entropy Label for Tunnels
The entropy label can be used to improve load balancing in traffic forwarding.
3.32 Configuring Static BFD for CR-LSP
By configuring static BFD for CR-LSP, you can monitor a static CR-LSP or an RSVP CR-
LSP.
3.33 Configuring Dynamic BFD for CR-LSP
Static BFD for CR-LSP can be configured to monitor an RSVP CR-LSP and protect traffic
along a CR-LSP.
3.34 Configuring Static BFD for TE
This section describes how to configure static BFD for TE to detect faults in a TE tunnel.
3.35 Configuring BFD for P2MP TE
BFD for P2MP TE rapidly monitors P2MP TE tunnels, which helps speed up responses to
faults and improve network reliability.
3.36 Configuring Dynamic BFD for RSVP

This section describes how to configure a dynamic BFD session to detect faults in links
between RSVP neighbors.
3.37 Maintaining MPLS TE
This section describes how to delete MPLS TE information and debug MPLS TE.
3.38 Configuration Examples for MPLS TE
This section provides MPLS TE configuration examples.
3.1 Overview of MPLS TE

The Multiprotocol Label Switching Traffic Engineering (MPLS TE) technology integrates the
MPLS technology with TE. It reserves resources by establishing label switched paths (LSPs)
over a specified path in an attempt to prevent network congestion and balance network traffic.
TE
Network congestion is a major cause for backbone network performance deterioration. The
network congestion is resulted from insufficient resources or locally induced by incorrect
resource allocation. For the former, network device expansion can prevent the problem. For
the later, TE is used to allocate some traffic to idle link so that traffic allocation is improved.
TE dynamically monitors network traffic and loads on network elements and adjusts the
parameters for traffic management, routing, and resource constraints in real time, which
prevents network congestion induced by load imbalance.
MPLS TE
MPLS TE establishes label switched paths (LSPs) based on constraints and conducts traffic to
specific LSPs so that network traffic is transmitted along the specified path. The constraints
include controllable paths and sufficient link bandwidth reserved for services transmitted over
the LSPs. If resources are insufficient, higher-priority LSPs preempt resources, such as
bandwidth, of lower-priority LSPs so that higher-priority services' requirements can be
fulfilled preferentially. In addition, if an LSP fails or a node is congested, MPLS TE protects
network communication using a backup path and the fast reroute (FRR) function. Using
MPLS TE allows a network administrator to deploy LSPs to properly allocate network
resources, which prevents network congestion. If the number of LSPs increases, a specific
offline tool can be used to analyze traffic.
3.2 Licensing Requirements and Limitations for MPLS TE

Licensing Requirements
This feature is a basic feature and is not under license control.

Restrictions and Guidelines

Restrictions Guidelines Impact
A loopback interface None If an LSR ID is not set to a

address must be used in the loopback address, an IGP
mpls lsr-id command. floods the LSR ID and a
path is successfully
computed. After a TE tunnel
is established, application
nor protocol packets that
depend on the loopback
address cannot be handled.
For example, in VPN
iteration, the peer BGP
address is used as a next-
hop IP address (which
should have been a loopback
interface address), and the
local end is iterated to the
tunnel destined for the peer
BGP address. Since the
loopback interface address
is not used, the iteration
fails.
The destination IP address None If an LSR ID is not set to a

of the tunnel must be set to loopback address, a path is
the MPLS LSR ID successfully computed.
configured on the After a TE tunnel is
destination router. established, application nor
protocol packets that depend
on the loopback address
cannot be handled. For
example, in VPN iteration,
the peer BGP address is
used as a next-hop IP
address (which should have
been a loopback interface
address), and the local end is
iterated to the tunnel
destined for the peer BGP
address. Since the loopback
interface address is not used,
the iteration fails.
If a TE tunnel group and None If a TE tunnel group is

dynamic load balancing configured, the dynamic
(load-balance dynamic- load balancing function does
adjust enable) are not take effect.
configured, and dynamic
load-balancing does not take
effect.

The TE group feature None Non-LPUF-50/LPUF-50-L/

requires that the inbound LPUI-21-L/LPUI-51-L/
interface reside on a LPUF-51/LPUF-51-B/
LPUF-50/LPUF-50-L/ LPUI-51/LPUI-51-B/
LPUI-21-L/LPUI-51-L/ LPUI-51-S/LPUS-51/
LPUF-51/LPUF-51-B/ LPUF-101/LPUF-101-B/
LPUI-51/LPUI-51-B/ LPUI-101/LPUI-101-B/
LPUI-51-S/LPUS-51/ LPUS-101/LPUF-51-E/
LPUF-101/LPUF-101-B/ LPUI-51-E/LPUI-51-CM/
LPUI-101/LPUI-101-B/ LPUF-120/LPUF-120-B/
LPUS-101/LPUF-51-E/ LPUF-120-E/LPUI-102-E/
LPUI-51-E/LPUI-51-CM/ LPUI-120/LPUI-120-B/
LPUF-120/LPUF-120-B/ LPUI-120-L/LPUI-52-E/
LPUF-120-E/LPUI-102-E/ LPUI-120-E/LPUI-120-CM/
LPUI-120/LPUI-120-B/ LPUF-240/LPUF-240-B/
LPUI-120-L/LPUI-52-E/ LPUF-240-E/LPUI-240/
LPUI-120-E/LPUI-120-CM/ LPUI-240-B/LPUI-240-CM/
LPUF-240/LPUF-240-B/ LPUI-240-L/LPUF-480/
LPUF-240-E/LPUI-240/ LPUF-480-B/LPUI-480/
LPUI-240-B/LPUI-240-CM/ LPUI-480-B/LPUI-480-L/
LPUI-240-L/LPUF-480/ LPUF-480-E/LPUI-480-
LPUF-480-B/LPUI-480/ CM/LPUI-200/LPUI-200-L/
LPUI-480-B/LPUI-480-L/ LPUF-200/LPUF-200-B/
LPUF-480-E/LPUI-480- LPUI-1T/LPUI-1T-B/
CM/LPUI-200/LPUI-200-L/ LPUI-1T-L/LPUI-1T-CM/
LPUF-200/LPUF-200-B/ LPUI-2T/LPUI-2T-B/
LPUI-1T/LPUI-1T-B/ LPUI-2T-CM boards do not
LPUI-1T-L/LPUI-1T-CM/ support TE tunnel groups.
LPUI-2T/LPUI-2T-B/
LPUI-2T-CM board.
After re-marking is After re-marking is In a TE tunnel group

performed in MF traffic performed in MF traffic scenario, after CAR and re-
classification, packets with classification, packets with marking are performed in
the same priority are added the same priority are added MF traffic classification,
to the same TE group. to the same TE group. packets may be out of order.
In a TE tunnel group None In a TE tunnel group

scenario, if TE tunnels work scenario, if TE tunnels work
with physical interfaces or with physical interfaces or
LDP LSPs to balance traffic, LDP LSPs to balance traffic,
although the bandwidth or although the bandwidth or
weight is configured for weight is configured for
tunnels of each priority, tunnels of each priority,
unequal load balancing unequal load balancing
based on the bandwidth or based on the bandwidth or
weight is not supported. weight is not supported.
Equal cost load balancing is Equal cost load balancing is
performed among tunnels of performed among tunnels of
each priority. each priority.

P2MP TE does not support Run the mpls te p2mp-te Traffic over a tunnel fails to
the following outbound disable command on the be forwarded through the
interfaces:serial interface, interface to prevent MPLS outbound interface.
MP-group interface, Eth- traffic from traveling
Trunk dot1q sub-interface through it.
for VLAN tag termination,
Eth-Trunk QinQ sub-
interface for VLAN tag
termination, Trunk-Serial
interfaces, Global-MP-
Group, and POS-Trunk
interface.
An inter-IGP area P2MP TE Plan all P2MP TE tunnels An S2L cannot be created
tunnel is no supported. within the same IGP area. on a leaf node that is in a
different IGP area than the
ingress of a P2MP TE
tunnel.
VPN QoS is not supported None When VLL/VPLS traffic is

when VLL/VPLS traffic is iterated to DS-TE tunnels
iterated to DS-TE tunnels. and VPN QoS is configured,
traffic is balanced among
common TE tunnels.
When the standard DS-TE The mpls te service-class The bandwidth of the
mode is configured, if the default command is service with the lowest
mpls te service-class recommended in standard priority is preempted.
default command is not run, DS-TE mode.
a TE tunnel without a
priority is selected for the
service that is not associated
with a priority. If no such
TE tunnel exists, the service
is forwarded through the TE
tunnel with the lowest
priority. As a result, the
bandwidth of the services
with the lowest priority is
preempted.
When VPN traffic is iterated VPN-based BFD is Protocol convergence is

to DS-TE tunnels, TE fault configured to trigger fast only supported when VPN
cannot be associated with VPN FRR switching. traffic is iterated to DS-TE
fast VPN FRR switching. tunnels.

DS-TE: None None

l The DS-TE mode and
FRR bandwidth
protection cannot be
configured
simultaneously.
l The DS-TE mode and
tunnel delegation cannot
be configured
simultaneously.
l DS-TE tunnels do not
support soft preemption.
l CT1 through CT7
bandwidth can only be
configured for P2P
RSVP tunnels.
When a Huawei forwarder Do not specify an initiated The forwarder cannot

runs PCEP to communicate LSP name carrying the execute a parameter
with a non-Huawei special characters. carrying the special
controller, the non-Huawei characters.
controller may deliver an
initiated LSP name carrying
special characters, such as a
question mark (?), a colon
(;), or %, to the forwarder.
The forwarder, however,
does not support such
characters. When a Huawei
forwarder runs PCEP to
communicate with a Huawei
controller, this problem does
not occur.
PCEP is used only to If both PCEP and The Huawei controller

connect to a Huawei NETCONF are used to incorrectly remains the
controller. PCEP and modify a stitching label due stitching label.
NETCONF cannot be used to mal-operation, on the
together to modify a forwarder, run the undo
stitching label. mpls te pce delegate
command to cancel tunnel
delegation and the mpls te
pce delegate command to
delegate the tunnel to the
controller again.

Entropy label feature: None None

RSVP P2P LSPs and LDP
P2P LSPs support entropy
label negotiation. Other
types of LSPs do not
support this function.
A neighbor node supports None If the RSVP-TE Hello

GR. If a local node capability is not configured
functions as the GR Helper, on the RSVP-TE tunnel, the
the mpls rsvp-te hello mpls rsvp-te hello support-
command must be run on an peer-gr command
RSVP-TE tunnel after the functioNonelity fails. When
mpls rsvp-te hello support- the RSVP node performs a
peer-gr command is run in master/slave main control
the MPLS view. board swithocver, the RSVP
adjacency between the local
ndoe and its neighbor node
is torn down because of the
sigNoneling protocol
timeout. As a result, a CR-
LSP is torn down, and
services transmitted over teh
CR-LSP are interrupted.
When multiple MPLS TE- l Solution: An explicit TE tunnels and multiple IGP
enabled IGP processes are path is configured in the processes are configured on
deployed on a device, CSPF system view and used in the ingress and egress. The
cannot compute an optimal the TE tunnel interface paths of the TE tunnels are
path among these IGP view. automatically computed
processes. An optimal path l AlterNonetive solution: based on IGP paths. No
computed within a single The mpls te cspf explicit paths or the other
process may be different preferred-igp command constraints are configured.
than the expected one. As a is run in the MPLS view As a result, the TE tunnels
result, services are to enable CSPF to pass through paths different
congested or interrupted on compute a path within a than the expected ones,
a TE tunnel. selected IGP process. causing service congestion
or interruptions.
In an LDP over TE scenario, In the preceding scenario, a If no remote LDP session is

after the mpls te igp remote LDP session must be established, no LDP LSP is
advertise or mpls te igp established based on the established, which interrupts
advertise shortcut command tunnel destiNonetion. services.
is run in the view of a TE
tunnel interface, a remote
LDP session must be
established based on the
tunnel destination address
after the route advertisement
function is enabled.

If a TE tunnel passes Plan all TE tunnels within A tunnel fails to be

through multiple IGP areas, the same IGP area. established or forward data
an explicit path with inter- packets.
node IP addresses included
needs to be configured for
the tunnel, and CSPF must
be configured on the ingress
and inter-area nodes.
When you configure a split None None

tunnel, not that:
A split tunnel cannot be
used as an outbound
interface of a route. The
mpls te igp mpls te igp
shortcut and mpls te
reserved-for-binding
commands cannot be run
simultaneously for a split
tunnel.
If the mpls te timer auto- None Automatic bandwidth

bandwidth command must adjustment does not take
be run in the MPLS view effect.
when automatic bandwidth
adjustment is configured on
a tunnel.
The include and exclude None The configuration fails.

attributes cannot be
simultaneously configured
for an affinity on a tunnel.
When the bidirectional None The configuration fails.

attribute is enabled for a
tunnel, the tunnel cannot be
bound to a static
bidirectional co-routed
CRLSP on the egress.
The bidirectional co-routed None The configuration fails.

attribute is mutually
exclusive with the dynamic
reverse LSP attribute.
A primary tunnel cannot be None The configuration fails.

configured as a protection
tunnel. A primary tunnel
cannot configure itself as a
protection tunnel.

The bandwidth configured None The configuration fails.

in the bypass-attribute
command must be lower
than or equal to the
bandwidth of the primary
tunnel. The priority
configured in this command
cannot be greater than the
priority of the primary
tunnel.
The FF style is mutually None The configuration fails.

exclusive with FRR.
The FF style is mutually
exclusive with backup.
exclusive with automatic
bandwidth adjustment.
exclusive with soft
preemption.
The FF style is mutually None The configuration fails.

exclusive with PCE
delegation.
Bit error-triggered switching None The configuration fails.

is mutually exclusive with
the protection group
function.
Hot standby is mutually None The latest configuration

exclusive with ordinary overrides the previous one.
backup.
Hot standby is mutually None The configuration fails.

exclusive with the offload
function.
Hot standby is mutually
exclusive with the bypass
tunnel function.
exclusive with a protected
interface.
exclusive with the FF style.
exclusive with the reroute
disable command.

Ordinary backup is mutually None The configuration fails.

exclusive with the off-load
function.
Ordinary backup is mutually
exclusive with the best-
effort path function.
disable command.
exclusive with reverse LSPs.
Fast reroute is mutually None The configuration fails.

exclusive with the offload
function.
Fast reroute is mutually
exclusive with a bypass
tunnel.
exclusive with a protected
interface.
exclusive with FF style.
exclusive with reverse LSPs.
disable command.
A bypass tunnel is mutually None The configuration fails.

exclusive with FRR.
A bypass tunnel is mutually
exclusive with the detour
LSP function.
disable command.

A protected interface is None The configuration fails.

mutually exclusive with
FRR.
A protected interface is
mutually exclusive with the
detour LSP function.
backup.
ordinary backup and best-
effort functions.
The best-effort path function None The configuration fails.

is mutually exclusive with a
bypass tunnel.
The best-effort path function
is mutually exclusive with a
protected interface.
the FF style.
the offload function.
ordinary backup.
the reroute disable
command.
Soft preemption is mutually None The configuration fails.

Soft preemption is mutually
disable command.
The bypass attribute is None The configuration fails.


The include-all and include- None A later configuration takes

any attributes cannot be effect.
simultaneously configured
for an affinity. The latest
configuration overrides the
previous one.
When the reverse LSP Modify the global label Reverse LSPs do not take
function is used, the global allocation mode to the non- effect.
label allocation mode must null mode
be set to the non-null mode.
The reverse LSP function is None The configuration fails.

backup.
The reverse LSP function is
FRR.
The reverse LSP function is None The configuration fails.

A label and an IP address None The configuration fails.

cannot be configured in a
mixed way for an explicit
path.
PCE delegation is mutually None The configuration fails.

LSP function.
PCE delegation is mutually
disable command.

The detour LSP function is None The configuration fails.

offload function.
The detour LSP function is
mutually exclusive with a
bypass tunnel.
mutually exclusive with a
protected interface.
FF style.
bypass attribute.
reverse LSPs.The detour
LSP function is mutually
exclusive with the bypass
attribute.The detour LSP
function is mutually
disable command.The
detour LSP function is
PCE delegation.

The reroute disable None The configuration fails.

command is mutually
exclusive with PCE
delegation.
The reroute disable
command is mutually
exclusive with tunnel re-
optimization.
The reroute disable
command is mutually
exclusive with soft
preemption.
The reroute disable
command is mutually
LSP function.
The reroute disable
command is mutually
exclusive with ordinary
backup.
The reroute disable
command is mutually
exclusive with the best-
effort path.
The reroute disable
command is mutually
exclusive with FRR.
The reroute disable
command is mutually
The reroute disable
command is mutually
exclusive with a bypass
tunnel.
The reroute disable
command is mutually
exclusive with automatic
bandwidth adjustment.
When a GMPLS tunnel is None The configuration fails.

bound to a GMPLS-UNI
interface and the switch-
type is EVPL, the process-
pst parameter cannot be
configured.

When BFD monitors a None The configuration fails.

GMPLS-UNI, the process-
pst parameter is configured,
and the GMPLS tunnel is
bound to the GMPLS-UNI,
the switch-type parameter
cannot be set to EVPL.
A static tunnel or a static CR None The configuration fails.

tunnel cannot be bound to a
reverse RSVP-TE LSP.
LSP loopback is supported None The configuration fails.

only on a transit node of a
static bidirectional co-routed
LSP.
The name of a reverse LSP None The configuration fails.

in a static bidirectional co-
routed tunnel must be the
same as that of a forward
LSP.
If the TP OAM lock None The configuration fails.

function is enabled on an
interface, the interface
cannot be used as the
outbound or inbound
interface of a static tunnel.
BFD and MPLS OAM None The configuration fails.

cannot be configured
simultaneously for a tunnel.
The bandwidth of the None The configuration fails.

primary tunnel cannot be
greater than that of a backup
tunnel.
After the reverse LSP in a None The configuration fails.

working tunnel must be
different from that in a
protection tunnel.
A dynamic tunnel cannot be None The configuration fails.

bound to a reverse LSP of a
static protocol.

The hard pipe is mutually None The configuration fails.

exclusive with bandwidth
attributes.
The hard pipe attribute is
diffserv-mode command.
An inbound interface must
be configured for a hard
pipe LSP.
An outbound interface must
be configured for a hard
pipe LSP.
An inter-area auto bypass Do not use Auto FRR in an A cross-IGP area node
tunnel is not supported inter-area scenario. cannot create an Auto
because LSP cannot be bypass tunnel to protect
bound to an FRR path in an nodes or links on a primary
inter-area scenario. tunnel.
An inter-area detour LSP is Do not use Detour FRR in A cross-IGP area node
not supported. an inter-area scenario. The cannot create a detour LSP
primary LSP cannot be to protect nodes or links on
bound to a Detour FRR LSP a primary tunnel.
in the inter-area scenarios.
Inter-IGP-area re- None If an LSP is established

optimization is not across IGP areas, the LSP
supported. cannot be re-optimized.
An Segment Routing MPLS An Segment Routing MPLS Without a detection protocol

tunnel must be used together tunnel must be used together enabled, Segment Routing
with detection function. with detection function. MPLS LSPs cannot detect
Segment Routing MPLS link faults or switch traffic,
tunnels do not use signaling resulting in traffic loss.
protocols. BFD for TE LSP
must be configured to
monitor the connectivity of
the primary and backup
LSPs before HSB protection
is performed.
An Segment Routing MPLS An Segment Routing MPLS Without a detection protocol

tunnel must be used together tunnel must be used together enabled, Segment Routing
with detection function. with detection function. MPLS LSPs cannot detect
Segment Routing MPLS link faults or notify an App
tunnels do not use signaling of the tunnel fault. As a
protocols. BFD for tunnel result, services iterated to an
must be configured to Segment Routing MPLS
associate the BFD status LSP cannot be switched to a
with the tunnel status. protection LSP, resulting in
traffic loss.

After a labeled explicit path None An Segment Routing MPLS

is configured for an tunnel established over a
Segment Routing MPLS labeled explicit path does
tunnel, there is no response not respond to messages of
to label stack packets the other label stacks or to
delivered by the schema or the make-before-break
PCEP path information mechanism. Path re-
messages. optimization is not
performed, and the
origiNonel LSP and traffic
are not affected.
If static and dynamic BFD None If static and dynamic BFD

for TE LSP is for TE LSP is
simultaneously configured, simultaneously configured,
the static BFD session takes the static BFD session takes
effect. effect.
Re-optimization can be Re-optimization and CSPF If CSPF is not enabled, pre-

performed only after CSPF are used together. computation cannot be
is enabled globally. performed, and re-
optimization does not take
effect.
Automatic bandwidth Automatic bandwidth If CSPF is not enabled, pre-

adjustment can be adjustment and CSPF are computation cannot be
performed only after CSPF used together. performed, and automatic
is enabled globally. bandwidth adjustment does
not take effect.
Diabling the automatic None The automatic configuration

configuration of global of physical interface
physical interface bandwidth bandwidth is not supported
is supported only in the PTN and does not take effect in
mode. the CX mode.
3.3 Configuring Static CR-LSP

This section describes how to configure a static CR-LSP. The configuration of a static CR-
LSP is simple, and label allocation is performed manually, not by using a signaling protocol to
exchange control packets, which consumes a few resources.
Usage Scenario
The configuration of a static CR-LSP is a simple process. Labels are manually allocated, and
no signaling protocol or exchange of control packets is needed. The setup of a static CR-LSP
consumes a few resources. In addition, neither IGP TE nor CSPF needs to be configured for
the static CR-LSP.

The static CR-LSP cannot dynamically adapt to a changing network. Therefore, its
application is very limited.
The static CR-LSP configurations involve the operations on the following types of nodes:
l Ingress: An LSP forwarding entry is configured, and an LSP configured on the ingress is
bound to the TE tunnel interface.
l Transit node: An LSP forwarding entry is configured.
l Egress: An LSP forwarding entry is configured.
Pre-configuration Tasks
Before configuring a static CR-LSP, complete the following tasks:
l Configure the static route or IGP to implement the reachability between LSRs.
l Configure an LSR ID on each LSR.
l Enable basic MPLS functions on each LSR globally and on each interface.
Configuration Procedures
Figure 3-1 Flowchart for configuring a static CR-LSP
Enabling MPLS TE
Configuring Link Bandwidth
Configuring the MPLS TE

Tunnel Interface
Configuring Global Dynamic

Bandwidth Pre-verification
Configuring the Ingress of the

Static CR-LSP
Configuring the Transit of the

Static CR-LSP
Configuring the Egress of the

Static CR-LSP
Mandatory procedure
Optional procedure

3.3.1 Enabling MPLS TE

Before you set up a static CR-LSP, enable MPLS TE.
Context
Perform the following steps on each node along a static CR-LSP:
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.
Before you enable MPLS TE on each interface, enable MPLS TE globally in the MPLS view.
Step 4 Run quit
Return to the system view.
Step 5 Run interface interface-type interface-number
The interface view is displayed.
Step 6 Run mpls
The MPLS is enabled on the interface.
Step 7 Run mpls te
The MPLS TE is enabled on the interface.
NOTE
When the MPLS TE is disabled in the interface view, all CR-LSPs on the current interface go Down.
When the MPLS TE is disabled in the MPLS view, the MPLS TE on each interface is disabled, and all
CR-LSPs are torn down.
Step 8 Run commit
The configurations are committed.
----End
3.3.2 (Optional) Configuring Link Bandwidth

By configuring the link bandwidth, you can constrain the bandwidth of a CR-LSP.
Context
Perform the following steps on each node along the CR-LSP:

Procedure
The MPLS-TE-enabled interface view is displayed.
Step 3 Run mpls te bandwidth max-reservable-bandwidth bw-value
The maximum available bandwidth of the link is configured.
Step 4 Run mpls te bandwidth bc0 bc0-bw-value
The BC bandwidth of the link is configured.
NOTE
l The maximum reservable bandwidth of a link cannot be higher 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 The BC0 bandwidth cannot be higher than the maximum reservable bandwidth of the link.
Step 5 Run commit

----End
3.3.3 Configuring the MPLS TE Tunnel Interface

This section describes how to configure the MPLS TE tunnel interface. You must create a
tunnel interface before setting up an MPLS TE tunnel.
Context
Perform the following steps on the ingress of a static CR-LSP:
Procedure
Step 2 Run interface tunnel interface-number
The 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 To specify the IP address of the tunnel interface, run ip address ip-address { mask |
mask-length } [ sub ]
The secondary IP address of the tunnel interface can be configured only after the primary
IP address is configured.
l To borrow an IP address from 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; therefore, its peer address is irrelevant to traffic forwarding. A tunnel

interface does not need to be assigned an IP address but uses the ingress LSR ID as its IP
address.
Step 4 Run tunnel-protocol mpls te
MPLS TE is configured to be the tunnel protocol.
Step 5 Run destination ip-address
The destination address of the tunnel is configured, which is usually the LSR ID of the egress
node.
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 Run commit
----End
3.3.4 (Optional) Configuring Global Dynamic Bandwidth Pre-

verification
Global dynamic bandwidth pre-verification enables a device to check dynamic bandwidth
usage before a static CR-LSP, or a static bidirectional co-routed LSP is established.
Context
When dynamic services or both static and dynamic services are configured, a device only
checks static bandwidth usage when a static CR-LSP or a static bidirectional co-routed LSP is
configured. The configuration is successful even if the interface bandwidth is insufficient, and
the interface status is Down. To percent such an issue, global dynamic bandwidth pre-
verification can be configured. With this function enable, the device can prompt a message
indicating that the configuration fails in the preceding situation.
Procedure
Step 2 Run mpls
MPLS is enabled globally, and the MPLS view is displayed.
Step 3 Run mpls te
MPLS TE is enabled globally.
Global dynamic bandwidth pre-verification can only be configured after MPLS TE is enabled
globally.

Step 4 Run mpls te static-cr-lsp bandwidth-check deduct-rsvp-bandwidth
Global dynamic bandwidth pre-verification is enabled.
Step 5 Run commit
The configuration is committed.
----End
3.3.5 Configuring the Ingress of the Static CR-LSP

This section describes how to configure the ingress of a static CR-LSP. Before you establish a
static CR-LSP, specify the ingress of the CR-LSP.
Context
Perform the following steps on the ingress of a static CR-LSP:
Procedure
Step 2 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 ] bandwidth ]
The LSR is set as the ingress of the specified static CR-LSP.
To modify the destination destination-address, nexthop next-hop-address, outgoing-

interface interface-type interface-number, or out-label out-label, run the static-cr-lsp ingress
command to set a new value. There is no need to run the undo static-cr-lsp ingress command
before changing a configured value.
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.
The next hop or outgoing interface is determined by the route from the ingress to the egress.
For the difference between the next hop and outbound interface, see "Static Route
Configuration" in HUAWEI NetEngine40E Universal Service Router Configuration Guide -
IP Routing.
If an Ethernet interface is used as an outbound interface, the nexthop next-hop-address

parameter must be configured.
Step 3 Run commit
----End

3.3.6 (Optional) Configuring the Transit Node of the Static CR-

LSP
This section describes how to configure the transit nodes of a static CR-LSP. Before you set
up a static CR-LSP, specify the transit nodes of the CR-LSP. This procedure is optional
because the CR-LSP may have no transit node.
Context
If the static CR-LSP has only the ingress and egress, configuring a transit node is not needed.
If the static CR-LSP has one or more transit nodes, perform the following steps on each
transit node:
Procedure
Step 2 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 [ ingress-lsrid ingress-lsrid egress-lsrid egress-lsrid tunnel-
id tunnel-id ] [ bandwidth [ ct0 ] bandwidth ]
The LSR is set as the transit node of the specified static CR-LSP.
To modify all the parameters except lsp-name, run the static-cr-lsp transit command to set a
new value. There is no need to run the undo static-cr-lsp transit command before changing a
configured value.
On the transit and egress nodes, the lsp-name parameter must be unique locally.
If an Ethernet interface is used as an outbound interface, the nexthop next-hop-address
parameter must be configured.
Step 3 Run commit
----End
3.3.7 Configuring the Egress of the Static CR-LSP

This section describes how to configure the egress of a static CR-LSP. Before you set up a
static CR-LSP, specify the egress of the CR-LSP.
Context
Perform the following steps on the egress of the static CR-LSP:
Procedure

Step 2 Run static-cr-lsp egress lsp-name incoming-interface interface-type interface-number in-

label in-label [ lsrid ingress-lsr-id tunnel-id tunnel-id ]
The LSR is configured as the egress of the specified static CR-LSP.
To modify the incoming-interface interface-type interface-number or in-label in-label-value,
run the static-cr-lsp egress command to set a new value. There is no need to run the undo
static-cr-lsp egress command before changing a configured value.
Step 3 Run commit
----End
3.3.8 (Optional) Configuring a Device to Check the Inbound

Interface of a Static CR-LSP
A device uses the static CR-LSP's source interface check function to check whether the
inbound interface of labeled packets is the same as that of a configured static CR-LSP. If the
inbound interfaces match, the device forwards the packets. If the inbound interfaces do not
match, the device discards the packets.
Context
A static CR-LSP is established using manually configured forwarding and resource
information. Signaling protocols and path calculation are not used during the setup of CR-
LSPs. Setting up a static CR-LSP consumes few resources because the two ends of the CR-
LSP do not need to exchange MPLS control packets. The static CR-LSP cannot be adjusted
dynamically in a changeable network topology. A static CR-LSP configuration error may
cause protocol packets of different NEs and statuses interfere one another, which adversely
affects services. To address the preceding problem, a device can be enabled to check source
interfaces of static CR-LSPs. With this function configured, the device can only forward
packets if both labels and inbound interfaces are correct.
Procedure
l Perform the following steps on the P node of a static CR-LSP:
a. Run system-view
b. Run mpls
c. Run mpls te
MPLS TE is globally enable.d
d. Run quit
e. Run static-cr-lsp transit lsp-name incoming-interface interface-type interface-
number in-label in-label outgoing-interface interface-type interface-number out-
label out-label
An incoming label value, inbound interface name, outgoing label value, and
outbound interface name are specified for a static CR-LSP.

f. Run undo static-cr-lsp rpf disable

The device is enabled to check the inbound interface of the static CR-LSP.
This function is enabled by default. To disable the command, run the static-cr-lsp
rpf disable command. To enable this function again, run the undo static-cr-lsp rpf
disable command.
l Perform the following steps on the egress of the static CR-LSP:
a. Run system-view
b. Run mpls
c. Run mpls te
d. Run quit
e. Run static-cr-lsp egress lsp-name incoming-interface interface-type interface-
number in-label in-label
An incoming label value and inbound interface name are specified for the static CR-
LSP.
f. The device is enabled to check the inbound interface of the static CR-LSP.
This function is enabled by default. To disable the command, run the static-cr-lsp
rpf disable command. To enable this function again, run the undo static-cr-lsp rpf
disable command.
----End
3.3.9 Verifying the Static CR-LSP Configuration

After the configuration of a static CR-LSP, you can view the static CR-LSP status.
Prerequisites
The static CR-LSP has been configured.
Procedure
l Run the display mpls static-cr-lsp [ lsp-name ] [ 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 information about the tunnel.
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 command to check information about the
tunnel interface on the ingress.
----End

Example
If the configurations are successful, run the preceding commands to view the following
information:
l Information about the static CR-LSP name, the incoming and outgoing labels, and the
incoming and outgoing interfaces. The status of CR-LSP is Up.
<HUAWEI> 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
Tunnel10 3.3.3.3/32 NULL/20 -/
GE1/0/6 Up
Tunnel20 -/32 130/NULL
GE1/0/6/- Up
l Statistics about the tunnel status on the LSR.

<HUAWEI> display mpls lsp statistics
Lsp Type Total Ingress Transit
Egress
STATIC LSP 0 0 0 0
STATIC CRLSP 1 1 0 0
LDP LSP 7 3 3 1
LDP IPV6 LSP 0 0 0 0
RSVP CRLSP 2 2 0 0
BGP LSP 0 0 0 0
ASBR LSP 0 0 0 0
BGP IPV6 LSP 0 0 0 0
L3VPN IPV6 LSP 0 0 0 0
----------------------------------------------------------------------
LSP 8 4 3 1
CRLSP 3 3 0 0
----------------------------------------------------------------------
Lsp Type IngressLspBypassState

TransitLspBypassState
ExistNotUsed InUse ExistNotUsed
InUse
RSVP CRLSP 0 0 0 0
----------------------------------------------------------------------
l Detailed information about the tunnel interface, including the tunnel name, state
description, and attributes. The tunnel attributes include the LSP ID, ingress, egress, and
signaling protocol.
<HUAWEI> display mpls te tunnel-interface
Tunnel Name : Tunnel1
Signalled Tunnel Name: -
Tunnel State Desc : CR-LSP is Up
Tunnel Attributes :
Active LSP : Primary LSP
Traffic Switch : -
Session ID : 1
Ingress LSR ID : 1.1.1.9 Egress LSR ID: 4.4.4.9
Admin State : UP Oper State : UP
Signaling Protocol : RSVP
FTid : 1
Tie-Breaking Policy : None Metric Type : None
Bfd Cap : None
Reopt : Disabled Reopt Freq : -
Inter-area Reopt : Disabled
Auto BW : Disabled Threshold : 0 percent
Current Collected BW: 0 kbps Auto BW Freq : 0
Min BW : 0 kbps Max BW : 0 kbps
Offload : Disabled Offload Freq : -

Low Value : - High Value : -

Readjust Value : -
Offload Explicit Path Name:
Tunnel Group : -
Interfaces Protected: -
Excluded IP Address : -
Referred LSP Count : 0
Primary Tunnel : - Pri Tunn Sum : -
Backup Tunnel :
-
Group Status : - Oam Status : -
IPTN InLabel : - Tunnel BFD Status :
-
BackUp LSP Type : None BestEffort : Disabled
Secondary HopLimit : -
BestEffort HopLimit : -
Secondary Explicit Path Name: -
Secondary Affinity Prop/Mask: 0x0/0x0
BestEffort Affinity Prop/Mask: 0x0/0x0
IsConfigLspConstraint: -
Hot-Standby Revertive Mode: Revertive
Hot-Standby Overlap-path: Disabled
Hot-Standby Switch State: CLEAR
Bit Error Detection: Disabled
Bit Error Detection Switch Threshold: -
Bit Error Detection Resume Threshold: -
Ip-Prefix Name : -
P2p-Template Name : -
PCE Delegate : Only status report LSP Control Status : Local
control
Entropy Label :None
Associated Tunnel Group ID: - Associated Tunnel Group
Type: -
Auto BW Remain Time : 200 s Reopt Remain Time : 100 s
Primary LSP ID : 1.1.1.9:19

LSP State : UP LSP Type : Primary
Setup Priority : 7 Hold Priority: 7
IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Affinity Prop/Mask : 0x0/0x0 Resv Style : SE
Configured Bandwidth Information:
CT0 Bandwidth(Kbit/sec): 20000 CT1 Bandwidth(Kbit/sec): 0
Actual Bandwidth Information:
Explicit Path Name : - Hop Limit: -
Record Route : Disabled Record Label : Disabled
Route Pinning : Disabled
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Soft Preemption : Enabled
Reroute Flag : Disabled
Pce Flag : Normal
Path Setup Type : EXPLICIT
3.4 Configuring a Static Bidirectional Co-routed LSP

A static bidirectional co-routed label switched path (LSP) is composed of two static
constraint-based routed (CR) LSPs in opposite directions. Multiprotocol Label Switching

(MPLS) Traffic Engineering (TE) supports MPLS forwarding in both directions along such an
LSP.
Usage Scenario
A static CR-LSP is easy to configure because its labels are manually assigned, and no
signaling protocol is used to exchange control packets. The setup of a static CR-LSP
consumes only a few resources, and you do not need to configure IGP TE or CSPF for the
static CR-LSP. As a static CR-LSP cannot dynamically adapt to network changes.
NOTE
l The value of the outgoing label on each node is the value of the incoming label on its next hop.
l The destination address of a static bidirectional co-routed LSP is the destination address specified
on the tunnel interface.
Before configuring a static bidirectional co-routed LSP, complete the following tasks:
l Configure unicast static routes or an IGP to implement connectivity between LSRs.

l Configure an LSR ID for each LSR.
l Enable MPLS globally and on interfaces on all LSRs.
3.4.1 Enabling MPLS TE

Before setting up a static bidirectional co-routed LSP, you must enable MPLS TE.
Context
Perform the following steps on each node along the CR-LSP:
Procedure
Step 2 Run mpls
Step 3 Run mpls te
MPLS TE is enabled on the node globally.
To enable MPLS TE on each interface, you must first enable MPLS TE globally in the MPLS
view.
Step 4 Run quit

Step 6 Run mpls
The MPLS is enabled on the interface.
Step 7 Run mpls te
MPLS TE is enabled on the interface.
NOTE
When the MPLS TE is disabled in the interface view, all CR-LSPs on the current interface go Down.
When the MPLS TE is disabled in the MPLS view, the MPLS TE on each interface is disabled, and all
CR-LSPs are deleted.
Step 8 Run commit
----End
3.4.2 (Optional) Configuring Link Bandwidth

This section describes how to configure link bandwidth so that nodes can reserve the
configured link bandwidth for a CR-LSP to be established.
Context
Plan bandwidths on links before you perform this procedure. The reserved bandwidth must be
higher than or equal to the bandwidth required by MPLS TE traffic. Perform the following
steps on each node along the CR-LSP to be established:
Procedure
The MPLS-TE-enabled interface view is displayed.
The maximum available link bandwidth is configured.
Step 4 Run mpls te bandwidth bc0 bc0-bw-value
The BC0 link bandwidth is configured.
Step 5 Run commit
----End
3.4.3 Configuring a Tunnel Interface on the Ingress

A tunnel interface must be created before an MPLS TE tunnel is established on an ingress.

Context
Perform the following steps on the ingress of a static bidirectional co-routed LSP:
Procedure
A tunnel interface is created, and the tunnel interface view is displayed.
Step 3 To configure an IP address for the tunnel interface, run either of the following commands:
l To assign an IP address to the tunnel interface, run ip address ip-address { mask | mask-
length } [ sub ]
The primary IP address must be configured prior to the secondary IP address for the
tunnel interface.
l To configure the tunnel interface to borrow the IP address of another interface, run ip
address unnumbered interface interface-type interface-number
Although an IP address on a tunnel interface enables an MPLS TE tunnel to forward traffic,

the MPLS TE tunnel does not need to be assigned a separate IP address because it is
unidirectional. Therefore, a tunnel interface usually borrows a loopback address, which is
used as the LSR ID of the ingress.
MPLS TE is configured as a tunnel protocol.
The destination address is configured for the tunnel. It is usually the LSR ID of the egress.
Various types of tunnels have different requirements for destination addresses. If a tunnel
protocol is changed to MPLS TE, the destination address configured using the destination
command is automatically deleted and needs to be reconfigured.
Static CR-LSP signaling is configured.
Step 8 Run mpls te bidirectional
The bidirectional LSP attribute is configured.
Step 9 Run commit
----End

3.4.4 (Optional) Configuring Global Dynamic Bandwidth Pre-

verification
Global dynamic bandwidth pre-verification enables a device to check dynamic bandwidth
usage before a static CR-LSP, or a static bidirectional co-routed LSP is established.
Context
When dynamic services or both static and dynamic services are configured, a device only
checks static bandwidth usage when a static CR-LSP or a static bidirectional co-routed LSP is
configured. The configuration is successful even if the interface bandwidth is insufficient, and
the interface status is Down. To percent such an issue, global dynamic bandwidth pre-
verification can be configured. With this function enable, the device can prompt a message
indicating that the configuration fails in the preceding situation.
Procedure
Step 2 Run mpls
MPLS is enabled globally, and the MPLS view is displayed.
Step 3 Run mpls te
Global dynamic bandwidth pre-verification can only be configured after MPLS TE is enabled
globally.
Step 4 Run mpls te static-cr-lsp bandwidth-check deduct-rsvp-bandwidth
Global dynamic bandwidth pre-verification is enabled.
Step 5 Run commit
----End
3.4.5 Configuring the Ingress of a Static Bidirectional Co-routed

LSP
The ingress of a static bidirectional co-routed LSP needs to be manually specified.
Context
Perform the following steps on the ingress of a static bidirectional co-routed LSP:
Procedure

Step 2 Run bidirectionalstatic-cr-lsp ingress tunnel-name

A static bidirectional co-routed LSP is created, and the static bidirectional LSP view is
displayed.
Step 3 Run forward { nexthop next-hop-address | outgoing-interface interface-type interface-
number } * out-label out-label-value [ bandwidth ct0 bandwidth ]
A CR-LSP is configured on the ingress.
The bandwidth parameter specifies the reserved bandwidth for a forward CR-LSP. The
bandwidth value cannot be higher than the maximum reservable link bandwidth. If the
specified bandwidth is higher than the maximum reservable link bandwidth, the forward CR-
LSP cannot go Up.
Step 4 Run backward in-label in-label-value [ lsrid ingress-lsr-id tunnel-id ingress-tunnel-id ]
A reverse CR-LSP is specified on the ingress.
Step 5 (Optional) Run description text
A description is configured for the static bidirectional co-routed CR-LSP.
Step 6 Run commit
----End
3.4.6 (Optional) Configuring a Transit Node of a Static

Bidirectional Co-routed LSP
The transit node of a static bidirectional co-routed LSP needs to be manually specified. This
configuration is optional because a static bidirectional co-routed LSP may have no transit
node.
Context
Skip this procedure if a static bidirectional co-routed LSP has only an ingress and an egress. If
a static bidirectional co-routed LSP has a transit node, perform the following steps on this
transit node:
Procedure
Step 2 Run bidirectionalstatic-cr-lsp transit lsp-name
A static bidirectional co-routed LSP is created, and the static bidirectional LSP view is
displayed.
lsp-name specified on a transit node or an egress cannot be the same as the existing tunnel
name on the transit node or the egress.
Step 3 Run forward in-label in-label-value { nexthop next-hop-address | outgoing-interface
interface-type interface-number } * out-label out-label-value [ ingress-lsrid ingress-lsrid
egress-lsrid egress-lsrid tunnel-id tunnel-id ] [ bandwidth ct0 bandwidth ]

A CR-LSP is configured on the transit node.
Step 4 Run backward in-label in-label-value { nexthop next-hop-address | outgoing-interface

interface-type interface-number } * out-label out-label-value [ bandwidth ct0 bandwidth ]
A reverse CR-LSP is configured on the transit node.
Step 6 Run commit
----End
3.4.7 Configuring the Egress of a Static Bidirectional Co-routed

CR-LSP
The egress of a static bidirectional co-routed CR-LSP needs to be manually specified.
Context
Perform the following steps on the egress of a static bidirectional co-routed CR-LSP:
Procedure
Step 2 Run bidirectionalstatic-cr-lsp egress tunnel-name
A static bidirectional co-routed LSP is created, and the static bidirectional CR-LSP view is
displayed.
The tunnel-name value must be the name of an established tunnel.
Step 3 Run forward in-label in-label-value [ lsrid ingress-lsr-id tunnel-id ingress-tunnel-id ]
A forward CR-LSP is configured on the egress.
If lsrid ingress-lsr-id tunnel-id ingress-tunnel-id is specified in this command, the system

checks whether the tunnel destination IP address on the egress and the specified value of
ingress-lsr-id are consistent. If the specified value of ingress-lsr-id is different from the tunnel
destination IP address on the egress, the tunnel cannot go Up. As a result, the forward and
reverse CR-LSPs configured on the egress cannot go Up.
Step 4 Run backward { nexthop next-hop-address | outgoing-interface interface-type interface-

number } * out-label out-label-value [ bandwidth ct0 bandwidth ]
A reverse CR-LSP is configured on the egress.
The bandwidth parameter specifies the reserved bandwidth for a reverse CR-LSP. The
bandwidth value cannot be higher than the maximum reservable link bandwidth. If the
specified bandwidth is higher than the maximum reservable link bandwidth, the forward CR-
LSP cannot go Up.


Step 6 Run commit
----End
3.4.8 Configuring the Tunnel Interface on the Egress

The reverse tunnel attribute is configured, and the tunnel interface is bound to a static
bidirectional co-routed LSP on the egress.
Context
Perform the following steps on the egress of a static bidirectional co-routed LSP:
Procedure
MPLS TE is configured as a tunnel protocol to create an MPLS TE tunnel.
The destination address is configured for the tunnel. It is usually the LSR ID of the ingress.
Various types of tunnels have different requirements for destination addresses. If a tunnel
protocol is changed to MPLS TE, the destination address configured using the destination
command is automatically deleted and needs to be reconfigured.
A static CR-LSP is configured.
Step 7 Run mpls te passive-tunnel
The reverse tunnel attribute is configured.
Step 8 Run mpls te binding bidirectional static-cr-lsp egress tunnel-name
The tunnel interface is bound to the specified static bidirectional co-routed LSP.
Step 9 Run commit
----End

3.4.9 Verifying the Configuration of a Static Bidirectional Co-

routed LSP
After configuring a static bidirectional co-routed LSP, you can view its status.
Prerequisites
A static bidirectional co-routed LSP has been established.
Procedure
l Run the display mpls te bidirectional static-cr-lsp [ lsp-name ] [ verbose ] command to
check the specified static bidirectional co-routed LSP.
----End
Example
Run the display mpls te bidirectional command to view information about the specified
static bidirectional co-routed LSP.
<HUAWEI> display mpls te bidirectional static-cr-lsp
Name FEC I/O Label I/O If Status
Tunnel10 3.3.3.3/32 NULL/20 -/GE1/0/6
20/NULL GE/1/6/- Up
Tunnel11 3.3.3.3/32 NULL/21 -/GE1/0/1
21/NULL GE1/0/1/- Up
3.5 Configuring an Associated Bidirectional CR-LSP

Associated bidirectional CR-LSPs provide bandwidth protection for bidirectional services.
Bidirectional switching can be performed for associated bidirectional CR-LSPs if faults occur.
Usage Scenario
MPLS networks face the following challenges:
l MPLS TE tunnels that transmit services are unidirectional. The ingress forwards services
to the egress along an MPLS TE tunnel. The egress forwards services to the ingress over
IP routes. As a result, the services may be congested because IP links do not reserve
bandwidth for these services.
l Two MPLS TE tunnels in opposite directions are established between the ingress and
egress. If a fault occurs on an MPLS TE tunnel, a traffic switchover can only be
performed for the faulty tunnel, but not for the reverse tunnel. As a result, traffic is
interrupted.
A forward CR-LSP and a reverse CR-LSP between two nodes are established. Each CR-LSP
is bound to the ingress of its reverse CR-LSP. The two CR-LSPs then form an associated
bidirectional CR-LSP. The associated bidirectional CR-LSP is primarily used to prevent
traffic congestion. If a fault occurs on one end, the other end is notified of the fault so that
both ends trigger traffic switchovers, which ensures that traffic transmission is uninterrupted.
The configurations in this section must be performed on tunnel interfaces of both the forward
and reverse CR-LSPs. Each CR-LSP is bound to the ingress of its reverse CR-LSP.

Before configuring an associated bidirectional CR-LSP, complete either of the following
tasks:
l Create RSVP-TE tunnels in opposite directions for an associated bidirectional dynamic
CR-LSP to be established.
l Create static CR-LSPs in opposite directions for an associated bidirectional static CR-
LSP to be established.
Procedure
Step 3 Run mpls te reverse-lsp protocol { rsvp-te ingress-lsr-id ingress-lsr-id tunnel-id tunnel-id |
static lsp-name lsp-name }
A reverse CR-LSP is configured on the tunnel interface.
Either of the following associated bidirectional CR-LSPs can be established:
l Associated bidirectional static CR-LSP: Two static unidirectional CR-LSPs in opposite
directions are bound to each other to form an associated bidirectional static CR-LSP. The
static lsp-name lsp-name parameters are configured in the mpls te reverse-lsp
command.
l Associated bidirectional dynamic CR-LSP: Two RSVP-TE tunnels in opposite directions
are bound to each other to form an associated bidirectional dynamic CR-LSP. The rsvp-
te ingress-lsr-id ingress-lsr-id tunnel-id tunnel-id parameters are configured in the mpls
te reverse-lsp command.
Step 4 Run commit
----End
Checking the Configurations

Run the display mpls te reverse-lsp command to view brief information about reverse CR-
LSPs.
<HUAWEI> display mpls te reverse-lsp
-------------------------------------------------------------------------------
LSP Information: STATIC LSP
-------------------------------------------------------------------------------
ReverseLSPName InLabel State ObverseTunnel
-------------------------------------------------------------------------------
Tunnel20 130 Up Tunnel10
-------------------------------------------------------------------------------
LSP Information: RSVP LSP
-------------------------------------------------------------------------------
IngressLsrID SessionID InLabel State SignalledTunnelName ObverseTunnel
-------------------------------------------------------------------------------
3.3.3.3 101 - Up Tunnel11 Tunnel11

Run the display mpls te reverse-lsp verbose command to view detailed information about
reverse CR-LSPs.
<HUAWEI> display mpls te reverse-lsp verbose
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Obverse Tunnel : Tunnel10
Reverse LSP Name : Tunnel20
Reverse LSP State : Up
Incoming Label : 130
Incoming Interface : GE1/0/6
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Obverse Tunnel : Tunnel11
Reverse LSP IngressLsrID : 2.2.2.2
Reverse LSP SessionID : 100
Signalled Tunnel Name : Tunnel11
Reverse LSP State : Up
LSP-id : 10
LSP-id : 11
3.6 Configuring an RSVP-TE Tunnel

MPLS TE reserves resources for RSVP-TE tunnels. These tunnels are established along
specified paths, not passing through congested nodes, balancing traffic on a network.
Usage Scenario
The dynamic RSVP-TE signaling protocol adjusts a path of a TE tunnel to adapt to network
topology changes. To help implement advanced functions, such as TE FRR or CR-LSP
backup, use the RSVP-TE signaling protocol to set up an MPLS TE tunnel.
Before configuring an RSVP-TE tunnel, complete the following tasks:
l Configure OSPF or IS-IS to implement connectivity between label switching routers
(LSRs).
l Set the LSR ID for every LSR.
l Enable MPLS in the system and interface views on every LSR.

Figure 3-2 RSVP-TE tunnel configuration
Enable MPLS TE and RSVP TE.
Configure CSPF.
Configure IGP TE (OSPF or IS-IS).
Configure link TE attributes.
Configure an MPLS TE explicit path.
Configure an MPLS TE tunnel interface.
Mandatory
Optional
3.6.1 Enabling MPLS TE and RSVP-TE

MPLS TE and RSVP-TE must be enabled on each LSR in an MPLS domain before TE
functions are configured.
Context
NOTE
l If MPLS TE is disabled in the MPLS view, MPLS TE enabled in the interface view is also disabled.
As a result, all CR-LSPs configured on this interface go Down, and all configurations associated
with these CR-LSPs are deleted.
l If MPLS TE is disabled in the interface view, all CR-LSPs on the interface go Down.
l If RSVP-TE is disabled on an LSR, RSVP-TE is also disabled on all interfaces on this LSR.

Procedure
Step 2 Run mpls lsr-id lsr-id
The LSR ID of the local node is configured.
When configuring an LSR ID, note the following:

l Configuring an LSR ID is the prerequisite of all MPLS configurations.
l An LSR ID must be manually configured because no default LSR ID is available.
l Use the IP address of a loopback interface on an LSR as an LSR ID.
The undo mpls command deletes all MPLS configurations, including the established
LDP sessions and LSPs.
Step 3 Run mpls
Step 4 Run mpls te
Step 5 Run mpls rsvp-te
RSVP-TE is enabled.
Step 6 Run quit
The view of the interface on which the MPLS TE tunnel is established is displayed.
Step 8 Run mpls
MPLS is enabled on an interface.
Step 9 Run mpls te
MPLS TE is enabled on the interface.
RSVP-TE is enabled on the interface.
Step 11 Run commit
----End

3.6.2 Configuring CSPF

Constrained Shortest Path First (CSPF) is configured to calculate the shortest path destined
for a specified node.
Context
CSPF is configured on all nodes along a path to enable the ingress to calculate a complete
path.
CSPF calculates only the shortest path to the specified tunnel destination. During path
computation, if there are multiple paths with the same weight, the optimal path is selected
using the tie-breaking function.
The tie-breaking function is performed in one of the following modes:
l Most-fill: The device selects a link with the largest ratio of used bandwidth to maximum
reservable bandwidth. This mode enables the device to effectively use bandwidth
resources.
l Least-fill: The device selects a link with the smallest ratio of used bandwidth to
maximum reservable bandwidth. This mode enables the device to evenly use bandwidth
resources on links.
l Random: The device selects a link at random. This mode allows CR-LSPs to distribute
evenly over links, regardless of bandwidth.
NOTE
CSPF uses tie-breaking to select a link based on a bandwidth ratio. If ratios are the same in when no
reservable bandwidth is available or when the same bandwidth is used on every link, the link discovered
first is used, even if least-fill or most-fill is configured.
Procedure
Step 2 Run mpls
Step 3 Run mpls te cspf
CSPF is enabled on the local node.
Step 4 (Optional) Run mpls te cspf preferred-igp { isis [ process-id [ level-1 | level-2 ] ] | ospf
[ process-id [ area area-id ] ] }
A preferred IGP is configured. Its process and area or level can also be configured.
Step 5 (Optional) Run mpls te cspf multi-instance shortest-path [ preferred-igp { isis | ospf }
[ process-id ] ]
CSPF is configured to calculate shortest paths among all IGP processes and areas.

The mpls te cspf multi-instance shortest-path command is mutually exclusive with the
mpls te cspf preferred-igp command. If the mpls te cspf multi-instance shortest-path
command is run, this command overrides the mpls te cspf preferred-igp command.
Step 6 Run mpls te tie-breaking { least-fill | most-fill | random }

A tie-breaking mode for calculating a path for a CR-LSP is specified.
Step 7 Run quit
Step 8 Run interface tunnel tunnel-number
The view of the MPLS TE tunnel interface is displayed.
The tie-breaking function for calculating a path is configured for the current tunnel.
The tie-breaking mode is configured either the tunnel interface view or MPLS view. If the tie-
breaking mode configured in both the tunnel interface and MPLS views, the configuration in
the tunnel interface view takes effect.
Step 10 Run commit
----End
3.6.3 Configuring IGP TE (OSPF or IS-IS)

After IGP TE is configured on all LSRs in an MPLS domain, a TEDB is generated on each
LSR.
Context
Either OSPF TE or IS-IS TE can be used:
NOTE
If neither OSPF TE nor IS-IS TE is configured, LSRs generate no TE link state advertisement (LSA) or
TE Link State PDUs (LSPs) and construct no TEDBs.
TE tunnels cannot be used in inter-area scenarios. In an inter-area scenario, an explicit path can be
configured, and the inbound and outbound interfaces of the explicit path must be specified, preventing a
failure to establish a TE tunnel.
l OSPF TE
OSPF TE uses Opaque Type 10 LSAs to carry TE attributes. The OSPF Opaque
capability must be enabled on each LSR. In addition, TE LSAs are generated only when
at least one OSPF neighbor is in the Full state.
l IS-IS TE
IS-IS TE uses the sub-time-length-value (sub-TLV) in the IS-reachable TLV (22) to carry
TE attributes. The IS-IS wide metric attribute must be configured. Its value can be
narrow, wide, compatible, or wide-compatible.

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. Run area area-id
The OSPF area view is displayed.

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

f. Run commit

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

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

c. Run cost-style { wide | compatible | wide-compatible }
The IS-IS wide metric attribute is configured.

d. Run traffic-eng [ level-1 | level-2 | level-1-2 ]
IS-IS TE is enabled.
If no level is specified when IS-IS TE is enabled, IS-IS TE is valid for both Level-1
and Level-2 routers.
e. (Optional) Run te-set-subtlv { bw-constraint bw-constraint-value | lo-multiplier
lo-multiplier-value | unreserve-bw-sub-pool unreserve-bw-sub-pool-value }*
The type and value of a sub-TLV carrying DS-TE (DiffServ-aware Traffic

Engineering) attributes are specified.
There are no unified standards for sub-TLVs that carry DS-TE attributes in non-
IETF mode. To ensure interconnection between devices of different vendors, you
need to manually configure TLV values for these sub-TLVs. After TLV values are
configured for these sub-TLVs, the traffic engineering database (TEDB) is
regenerated, and then TE tunnels are reestablished. The sub-TLVs can be sent only
after TLV values are configured for them.
f. Run commit
----End

3.6.4 (Optional) Configuring TE Attributes for a Link

TE attributes, such as the link bandwidth, administrative group attribute, affinity property, and
shared risk link group (SRLG) can be configured to select a link for a CR-LSP.
Context
TE link attributes are as follows:
l Link bandwidth
The link bandwidth attribute can be set to limit the CR-LSP bandwidth.
NOTE
If no bandwidth is set for a link, the CR-LSP bandwidth may be higher than the maximum
reservable link bandwidth. As a result, the CR-LSP cannot be established.
l Administrative group and affinity
An affinity determines attributes for links to be used by an MPLS TE tunnel. The affinity
property, together with the link administrative group attribute, is used to determine which
links a tunnel uses.
An affinity can be set using either a hexadecimal number or a name.
– Hexadecimal number: A 32-bit hexadecimal number is set for each affinity and link
administrative group attribute, which causes plan and computation difficulties.
– Name: Each affinity and link administrative group bit can be named, which
simplifies configuration and maintenance. Naming affinity and link administrative
group bits is recommended.
l SRLG
A shared risk link group (SRLG) is a set of links which are likely to fail concurrently
because they share a physical resource (for example, an optical fiber). In an SRLG, if
one link fails, the other links in the SRLG also fail.
An SRLG enhances CR-LSP reliability on an MPLS TE network with CR-LSP hot
standby or TE FRR enabled. Two or more links are at the same risk if they share physical
resources. For example, links on an interface and its sub-interfaces are in an SRLG. Sub-
interfaces share risks with their interface. These sub-interfaces will go Down if the
interface goes Down. If the links of a primary tunnel and a backup or bypass tunnel are
in the same SRLG, the links of the backup or bypass tunnel share risks with the links of
the primary tunnel. The backup or bypass tunnel will go Down if the primary tunnel goes
Down.
Procedure
l Configure link bandwidth.
The bandwidth value is set on outbound interfaces along links of a TE tunnel that
requires sufficient bandwidth.
a. Run:
system-view

b. Run:
interface interface-type interface-number
The view of an MPLS TE-enabled interface is displayed.

c. Run:
mpls te bandwidth max-reservable-bandwidth bandwidth
The maximum reservable link bandwidth is set.

d. Run:
mpls te bandwidth bc0 bc0-bandwidth
The BC bandwidth is set for the link.
NOTE
l The maximum reservable link bandwidth cannot be greater than the physical link
bandwidth. A maximum of 80% of the link bandwidth is recommended for the
maximum reservable link bandwidth.
l The BC0 bandwidth cannot be higher than the maximum reservable link bandwidth.
e. Run:
commit

l Set the TE metric value of a link.
a. Run:
system-view

b. Run:

c. Run:
mpls te metric value
The TE metric of a link is set.

d. Run:
commit

l Configure an affinity and a link administrative group attribute in hexadecimal format.
NOTE
l The modified administrative group takes effect only on LSPs that will be established, not on
LSPs that have been established.
l After the modified affinity is committed, the system will recalculate a path for the TE tunnel,
and the established LSPs in this TE tunnel are affected.
a. Run:
system-view

b. Run:
c. Run:
mpls te link administrative group value
An administrative group is configured for the link.

d. Run:
quit

e. Run:
interface tunnel tunnel-number

f. Run:
mpls te affinity property properties [ mask mask-value ] [ secondary |
best-effort ]
An affinity is set for the MPLS TE tunnel.

g. Run:
commit

l Name hexadecimal bits of an affinity and a link administrative group attribute.
NOTE
l The modified administrative group takes effect only on LSPs that will be established, not on
LSPs that have been established.
l After the modified affinity is committed, the system will recalculate a path for the TE tunnel,
and the established LSPs in this TE tunnel are affected.
a. Run:
system-view

b. Run:
path-constraint affinity-mapping
An affinity name mapping template is configured, and the template view is

displayed.
This template must be configured on each node that is used to calculate an MPLS
TE tunnel, and the same mappings between affinity names and bits must be
configured on each node.
c. Run:
attribute affinity-name bit-sequence bit-number
Mappings between affinity bits and names are configured.

This step can be performed to configure one affinity bit. Repeat this step to
configure more affinity bits. You can configure some or all 32 affinity bits.
d. Run:
e. Run:
mpls te link administrative group name bit-name &<1-32>
The administrative group attribute is specified for the link.

The affinity-name value must be in the range specified in the affinity name
template.

f. Run:
quit

g. Run:
interface tunnel tunnel-number

h. Run:
mpls te affinity { primary | secondary | best-effort } { include-all |
include-any | exclude } bit-name &<1-32>
An affinity is set for the MPLS TE tunnel.

i. Run:
commit

l Configure an SRLG.
NOTE
On the ingress of a hot-standby CR-LSP or a TE FRR tunnel, perform Steps 1 to 3. On the

interface of each SRLG member, perform Step 5 and Step 6.
a. Run:
system-view

b. Run:
mpls

c. Run:
mpls te srlg path-calculation [ preferred | strict ]
The SRLG path calculation mode is configured.
NOTE
l If strict is configured, CSPF uses an SRLG as a constraint when calculating a path for a
bypass or backup CR-LSP.
l If preferred is configured, CSPF uses an SRLG as a constraint when calculating a path
for a bypass or backup CR-LSP for the first time; if calculation fails, CSPF no longer
uses the SRLG as a constraint.
d. Run:
quit

e. Run:
f. Run:
mpls te srlg srlg-number
The link on which the interface resides joins the SRLG.

On a network with hot standby or TE FRR, the SRLG attribute needs to be
configured for the outbound interface of the ingress on a tunnel and other members

of the SRLG. A link joins an SRLG after the SRLG attribute is configured on an
outbound interface of the link.
NOTE
To delete the SRLG attribute from all interfaces on a device, run the undo mpls te srlg all-config
command in the MPLS view.
g. Run:
commit
----End
3.6.5 (Optional) Configuring an Explicit Path

An explicit path is configured on the ingress of an MPLS TE tunnel. It defines the nodes
through which the MPLS TE tunnel must pass or the nodes that are excluded from the MPLS
TE tunnel.
Context
An explicit path consists of a series of nodes. These nodes are arranged in sequence and form
a vector path. An interface IP address on every node is used to identify the node on an explicit
path. The loopback IP address of the egress node is usually used as the destination address of
an explicit path.
Two adjacent nodes are connected in either of the following modes on an explicit path:
l Strict: A hop is directly connected to its next hop.

l Loose: Other nodes may exist between a hop and its next hop.
The strict and loose modes are used either separately or simultaneously.
TE tunnels are classified as intra-area tunnels and inter-area tunnels. In this situation, areas
indicate OSPF and IS-IS areas, but not an autonomous system (AS) running the Border
Gateway Protocol (BGP). OSPF areas are divided based on different area IDs while IS-IS
areas are divided based on different levels.
l Intra-area tunnel: is a TE tunnel in a single OSPF or IS-IS area. An intra-area tunnel can
be established over a strict or loose explicit path.
l Inter-area tunnel: is a TE tunnel traversing multiple OSPF or IS-IS areas. An explicit
path must be used to establish an inter-area TE tunnel and an ABR or an Autonomous
System Boundary Router (ASBR) must be included in the explicit path.
The explicit path in use can be updated.
Procedure
Step 2 Run explicit-path path-name
An explicit path is created and the explicit path view is displayed.

Step 3 Run next hop ip-address [ include [ [ strict | loose ] | [ incoming | outgoing ] ] * | exclude ]
The next-hop address is specified for the explicit path.
The include parameter indicates that the tunnel does pass through a specified node; the
exclude parameter indicates that the tunnel does not pass through a specified node.
Step 4 (Optional) Run add hop ip-address1 [ include [ [ strict | loose ] | [ incoming | outgoing ] ] * |
exclude ] { after | before } ip-address2
A node is added to the explicit path.
Step 5 (Optional) Run modify hop ip-address1 ip-address2 [ include [ [ strict | loose ] | [ incoming |
outgoing ] ] * | exclude ]
The address of a node on an explicit path is changed.
Step 6 (Optional) Run delete hop ip-address
A node is removed from an explicit path.
Step 7 (Optional) Run list hop [ ip-address ]
Information about nodes on an explicit path is displayed.
Step 8 Run commit
----End
3.6.6 (Optional) Disabling TE LSP Flapping Suppression

TE LSP flapping suppression prevents high CPU usage stemming from TE LSP flapping.
This function can be disabled.
Procedure
Step 2 Run mpls
Step 3 Run mpls te
MPLS TE is globally enabled.
Step 4 Run mpls te suppress-flapping disable
TE LSP flapping suppression is disabled.
Step 5 Run commit
----End

3.6.7 Configuring an MPLS TE Tunnel Interface

An MPLS TE tunnel is established and managed on a tunnel interface. Therefore, the tunnel
interface must be configured on the ingress of an MPLS TE tunnel.
Procedure
Step 3 Run either of the following commands to configure the IP address of the tunnel interface:
l To assign an IP address to the tunnel interface, run ip address ip-address { mask | mask-
length } [ sub ]
The primary IP address must be configured before the secondary IP address can be
configured for the tunnel interface.
NOTE
An MPLS TE tunnel is unidirectional; therefore, its peer address is irrelevant to traffic forwarding. A
tunnel interface uses the local LSR ID as its IP address, without the need to be assigned an IP address.
The destination address of a tunnel 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
to MPLS TE from another protocol, a configured destination address is deleted automatically
and a new destination address needs to be configured.
Step 7 (Optional) Run mpls te signalled tunnel-name tunnel-name
The tunnel name carried in RSVP signaling messages is configured.
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 8 (Optional) Run mpls te bandwidth ct0 ct0-bw-value
The bandwidth is configured for an MPLS TE tunnel.
The bandwidth used by the tunnel cannot be higher than the maximum reservable link
bandwidth.

The bandwidth used by a tunnel does not need to be set if only a path needs to be configured
for an MPLS TE tunnel.
Step 9 (Optional) Run mpls te path explicit-path path-name [ secondary ]
An explicit path is configured for an MPLS TE tunnel.
An explicit path does not need to be configured if only the bandwidth needs to be set for an
MPLS TE tunnel.
Step 10 (Optional) Run mpls te resv-style { ff | se }
A resource reservation style is configured.
The SE style is used in the make-before-break scenario, and the fixed filter (FF) style is used
in a few scenarios.
Step 11 (Optional) Run mpls te cspf disable
Disable constraint shortest path first (CSPF) calculation when a TE tunnel is being
established.
NOTE
The mpls te cspf disable command is only applicable in the inter-AS VPN Option C scenario. In other
scenarios, running this command is not recommended.
Step 12 Run commit
----End
3.7 Configuring an Automatic RSVP-TE Tunnel

Automatic RSVP-TE tunnels are generated using the PCE Initiated LSP protocol. Such
tunnels do not need to be manually configured.
Usage Scenario
In an SDN solution, a controller can run the PCE Initiated LSP protocol to generate RSVP-TE
tunnels, without manual tunnel configuration. Dynamic RSVP-TE signaling adjusts paths of
TE tunnels dynamically based on network changes. To implement reliability functions, such
as TE FRR and CR-LSP backup, using RSVP-Te to establish MPLS TE tunnels is
recommended.
Before configuring an automatic RSVP-TE tunnel, complete the following tasks:
l Configure IS-IS to implement network layer connectivity for LSRs.

l Set an LSR ID for each LSR.

3.7.1 Enabling MPLS TE and RSVP-TE

Enabling MPLS TE and RSVP-TE on each node and interface in an MPLS domain is the
prerequisites for all TE features.
Procedure
Step 2 Run mpls lsr-id lsr-id
An LSR ID is set for a local node.
Note the following issues when setting an LSR ID:
l LSR IDs must be set before other MPLS commands are run.
l No default LSR ID is available.
l Using the IP address of a loopback interface as the LSR ID is recommended for an LSR.
Step 3 Run mpls
Step 4 Run mpls te
RSVP-TE is enabled.
Step 6 Run quit
Step 7 Run commit
----End
3.7.2 (Optional) Configuring CSPF

CSPF is configured to calculate the shortest path destined for a specified node.
Context
After CSPF is configured, it can be used to calculate paths if a connection between the
forwarder and controller is disconnected. If CSPF is not configured and a connection between
the forwarder and controller is disconnected, no path can be created because only the
controller can calculate paths.
CSPF calculates only the shortest path to the specified tunnel destination. During path
computation, if there are multiple paths with the same weight, the optimal path is selected
using the tie-breaking function.

The tie-breaking function is performed in one of the following modes:

l Most-fill: The device selects a link with the largest ratio of used bandwidth to maximum
reservable bandwidth. This mode enables the device to effectively use bandwidth
resources.
l Least-fill: The device selects a link with the smallest ratio of used bandwidth to
maximum reservable bandwidth. This mode enables the device to evenly use bandwidth
resources on links.
l Random: The device selects a link at random. This mode allows CR-LSPs to distribute
evenly over links, regardless of bandwidth.
NOTE
CSPF uses tie-breaking to select a link based on a bandwidth ratio. If ratios are the same in when no
reservable bandwidth is available or when the same bandwidth is used on every link, the link discovered
first is used, even if least-fill or most-fill is configured.
Procedure
Step 2 Run mpls
Step 3 Run mpls te cspf
CSPF is enabled on the local node.
Step 4 (Optional) Run mpls te cspf preferred-igp { isis [ process-id [ level-1 | level-2 ] ] | ospf
[ process-id [ area area-id ] ] }
A preferred IGP is configured. Its process and area or level can also be configured.
Step 5 (Optional) Run mpls te cspf multi-instance shortest-path [ preferred-igp { isis | ospf }
[ process-id ] ]
CSPF is configured to calculate shortest paths among all IGP processes and areas.
The mpls te cspf multi-instance shortest-path command is mutually exclusive with the
mpls te cspf preferred-igp command. If the mpls te cspf multi-instance shortest-path
command is run, this command overrides the mpls te cspf preferred-igp command.

A tie-breaking mode for calculating a path for a CR-LSP is specified.
Step 7 Run quit


The tie-breaking function for calculating a path is configured for the current tunnel.
The tie-breaking mode is configured either the tunnel interface view or MPLS view. If the tie-
breaking mode configured in both the tunnel interface and MPLS views, the configuration in
the tunnel interface view takes effect.
Step 10 Run commit
----End
3.7.3 Configuring IGP TE (OSPF or IS-IS)

After IGP TE is configured on all LSRs in an MPLS domain, a TEDB is generated on each
LSR.
Context
Either OSPF TE or IS-IS TE can be used:
NOTE
If neither OSPF TE nor IS-IS TE is configured, LSRs generate no TE link state advertisement (LSA) or
TE Link State PDUs (LSPs) and construct no TEDBs.
TE tunnels cannot be used in inter-area scenarios. In an inter-area scenario, an explicit path can be
configured, and the inbound and outbound interfaces of the explicit path must be specified, preventing a
failure to establish a TE tunnel.
l OSPF TE
OSPF TE uses Opaque Type 10 LSAs to carry TE attributes. The OSPF Opaque
capability must be enabled on each LSR. In addition, TE LSAs are generated only when
at least one OSPF neighbor is in the Full state.
l IS-IS TE
IS-IS TE uses the sub-time-length-value (sub-TLV) in the IS-reachable TLV (22) to carry
TE attributes. The IS-IS wide metric attribute must be configured. Its value can be
narrow, wide, compatible, or wide-compatible.
Procedure
l Configure OSPF TE.
a. Run system-view
c. Run opaque-capability enable
The OSPF Opaque capability is enabled.
d. Run area area-id
The OSPF area view is displayed.
e. Run mpls-te enable [ standard-complying ]

TE is enabled in the OSPF area.

f. Run commit

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

The IS-IS view is displayed.

c. Run cost-style { wide | compatible | wide-compatible }
The IS-IS wide metric attribute is configured.

d. Run traffic-eng [ level-1 | level-2 | level-1-2 ]
IS-IS TE is enabled.
If no level is specified when IS-IS TE is enabled, IS-IS TE is valid for both Level-1
and Level-2 routers.
e. (Optional) Run te-set-subtlv { bw-constraint bw-constraint-value | lo-multiplier
lo-multiplier-value | unreserve-bw-sub-pool unreserve-bw-sub-pool-value }*
The type and value of a sub-TLV carrying DS-TE (DiffServ-aware Traffic

Engineering) attributes are specified.
There are no unified standards for sub-TLVs that carry DS-TE attributes in non-
IETF mode. To ensure interconnection between devices of different vendors, you
need to manually configure TLV values for these sub-TLVs. After TLV values are
configured for these sub-TLVs, the traffic engineering database (TEDB) is
regenerated, and then TE tunnels are reestablished. The sub-TLVs can be sent only
after TLV values are configured for them.
f. Run commit
----End
3.7.4 Configuring the Automatic SR-TE Tunnel Capability on a

PCC
The PCE Initiated LSP protocol needs to be configured for automatic RSVP-TE tunnels. A
controller runs this protocol to deliver tunnel and path information to the ingress on which a
forwarder resides. Upon receipt of the information, the ingress automatically establishes an
RSVP-TE tunnel.
Context
The PCE Initiated LSP protocol is used to implement the automatic RSVP-TE tunnel
function. A PCE client (PCC) (ingress) establishes a PCE link to a PCE server (controller).
The controller delivers tunnel and path information to a forwarder configured on the ingress.
The ingress uses the information to automatically establish a tunnel and reports LSP status
information to the controller along the PCE link.

Procedure
Step 2 Run pce-client
A PCC is configured, and the PCC view is displayed.
Step 3 Run capbility initiated-lsp
The initiated LSP and RSVP-TE capabilities are enabled.
Step 4 Run connect-server ip-address
A candidate server is specified for the PCC.
Step 5 (Optional) Run mpls te pce cleanup initiated-lsp
The controller is enabled to create an LSP if the PCE server fails.
Step 6 Run commit
----End
3.7.5 Configuring Dynamic BFD For Initiated RSVP-TE LSP

LSPs that a controller runs the PCE Initiated LSP protocol to establish can only be monitored
by dynamic BFD.
Context
NOTE
Configuring dynamic BFD to monitor RSVP-TE Initiated LSPs is recommended. If no BFD session is
configured, the LSP goes Up by default, but its actual status cannot be determined.
Procedure
Step 2 Run mpls
Step 3 Run mpls te bfd enable auto-primary-tunnel pce-initiated-lsp
Dynamic BFD to monitor RSVP-TE Initiated LSP is enabled globally.
Step 4 Run commit
----End

3.7.6 Configuring Dynamic BFD for Initiated RSVP-TE Tunnel

RSVP-TE tunnels that a controller runs the PCE Initiated LSP protocol to establish can only
be monitored by dynamic BFD.
Context
NOTE
Configuring dynamic BFD to monitor RSVP-TE Initiated tunnels is recommended. If no BFD session is
configured, the tunnel goes Up by default, but its actual status cannot be determined.
Procedure
Step 2 Run mpls
Step 3 Run mpls te bfd tunnel enable auto-primary-tunnel pce-initiated-lsp
Dynamic BFD for initiated RSVP-TE tunnel is enabled globally.
Step 4 Run commit
----End
3.7.7 (Optional) Enabling Traffic Statistics Collection for

Automatic Tunnels
A device can be enabled to collect traffic statistics on RSVP-TE tunnels that are established
by the PCE Initiated LSP protocol.
Context
To view traffic information about an automatic tunnel, perform the following steps to enable a
device to collect traffic statistics on the automatic tunnel.
Procedure
Step 2 Run mpls
MPLS is enabled, and the MPLS view is displayed.
Step 3 Run quit
Step 4 Run mpls traffic-statistics

MPLS traffic statistics collection is enabled globally, and the traffic statistics view is
displayed.
Step 5 Run te auto-primary-tunnel pce-initiated-lsp
Traffic statistics collection for automatic tunnels is enabled.
Step 6 Run commit
----End
3.7.8 Verifying the Automatic RSVP-TE Tunnel Configuration

After configuring an automatic RSVP-TE tunnel, you can check information about the RSVP-
TE tunnel and its status statistics.
Prerequisites
The automatic RSVP-TE tunnel functions have been configured.
Procedure
l Run the following commands to check the IS-IS-related label allocation information:
– display isis traffic-eng advertisements [ { level-1 | level-2 | level-1-2 } | { lsp-id |
local } ] * [ process-id | [ vpn-instance vpn-instance-name ] ]
– display isis traffic-eng statistics [ process-id | [ vpn-instance vpn-instance-
name ] ]
l Run the display mpls te tunnel [ destination ip-address ] [ lsp-id 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 command to view TE tunnel statistics.
l Run the display mpls te tunnel-interface [ tunnel tunnel-number ] command to check
information about a tunnel interface on the ingress.
----End
Example
Run the following commands to check the previous configuration.
Run the display mpls te tunnel-interface command. The command output shows that the
tunnel is Up.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1


Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -
PCE Delegate : Only status report LSP Control Status : Local control
Entropy Label :None
Associated Tunnel Group ID: - Associated Tunnel Group Type: -

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal

3.8 Configuring PCE+ to Calculate Paths for MPLS TE

Tunnels
The PCE function is used to calculate a path over which an MPLS TE tunnel is established,
which more efficiently uses network resources than constrained shortest path first (CSPF).
Usage Scenario
Ingress nodes run the CSPF algorithm and use information stored in the traffic engineering
database (TEDB) to calculate paths for MPLS TE tunnels. On an MPLS TE network, multiple
tunnels originate from different ingress nodes and are established over paths that the ingress
nodes independently calculate. As a result, network-wide resources cannot be efficiently used.
The PCE+ solution can help resolve the preceding issue. PCE+ devices are classified as
servers and clients. A server calculates paths and stores network-wide path information. A
client initiates a request to calculate a path and functions as the ingress. After the client sends
a request to the server, the server calculates a path based on the network resources, which
achieves optimal network resource usage.
The NE40E can function as a PCE client.
Different from CSPF configured on the ingress, the PCE algorithm allows a PCE server to
configure and manage network-wide TE information, including node, link, and tunnel
attributes. Some steps in the following procedures are mandatory when CSPF is used, while
are optional when PCE is used.
Before configuring the PCE+ to calculate paths for MPLS TE tunnels, complete the following
tasks:
l Configure IS-IS to implement network layer connectivity.
l Enable MPLS TE and RSVP-TE.
l Enable IS-IS TE.
l (Optional) Configure TE attributes for links.
l Configure a tunnel interface.
NOTE
If a PCE server is used to configure and manage network-wide TE information and the PCE server and
client have the same parameters, the configurations on the PCE server take precedence. For example, the
bandwidth is set to 1000 kbit/s on a tunnel interface of a PCE client, and the bandwidth is set to 2000
kbit/s for the same tunnel on a PCE server. Only the bandwidth configured on the PCE server is used to
calculate a path. If a tunnel attribute is configured on a PCE client, not on a PCE server, the attribute can
take effect on the tunnel.
To improve the reliability of a TE tunnel established using PCE+, configure CR-LSP hot standby on the
tunnel interface on which the TE tunnel is established.

Figure 3-3 Flowchart for configuring a PCE client
Configure the ingress as a PCE

client.
Specify a candidate server for

the client.
Configure PCEP session

authentication.
Configure timers for the PCE

client.
Mandatory
Optional
3.8.1 Configuring the Ingress as a PCE Client

A PCE client can be configured on the ingress so that the ingress establishes a PCEP session
with a PCE server and sends a request to the server over the session to calculate a path.
Usage Scenario
Different from CSPF configured on the ingress, the PCE algorithm allows a PCE server to
configure and manage network-wide TE information, including node, link, and tunnel
attributes. Some steps are mandatory when CSPF is used, whereas are optional when PCE is
used.
If the ingress has to delegate LSPs only in some TE tunnels to the PCE server, the ingress
must report information about both delegated and undelegated LSPs to the PCE server, which
helps the PCE server correctly calculate global bandwidth information. To implement partial
LSP delegation, perform either of the following configurations:
l Configure the ingress to delegate LSPs in all TE tunnels to the PCE server. Then
configure the ingress to report LSP information on a specified tunnel interface to the
PCE server and withdraw the LSP delegation from the PCE server.
l Configure the ingress to report information about LSPs in all TE tunnels to the PCE
server, without delegating the LSPs to the PCE server. Then configure the ingress to
delegate the LSP on a specified TE tunnel interface to the PCE server.
Perform the following steps on the ingress:
Procedure
The ingress is configured as a PCE server, and the PCE client view is displayed.

Step 3 Run quit

Step 4 Run mpls
Step 5 (Optional) Run mpls te pce cleanup lsp-state
The PCE client is enabled to automatically degrade to use a local path calculation function if a
PCEP session fails.
If a PCE server fails or a PCEP connection is interrupted, to correctly establish an MPLS TE
tunnel, the PCE client must be able to automatically degrade to use a local path calculation
function. The PCE client can use CSPF (if configured) or routes to establish an MPLS TE
tunnel.
Step 6 Select either of the following solutions:
l Solution 1:
a. Run mpls te pce delegate
The ingress is configured to delegate LSPs in all local TE tunnels to the PCE server.
b. Run quit
c. Run interface tunnel tunnel-numbei
The specified TE tunnel interface view is displayed.
d. Run mpls te pce passive-delegate report-only
The ingress is configured to report LSP information on the specified tunnel to the
PCE server, without delegating LSPs in the tunnel to the PCE server.
l Solution 2:
a. Run mpls te pce passive-delegate report-only
The ingress is configured to report LSP information on all local tunnels to the PCE
server, without delegating LSPs in the tunnels to the PCE server.
b. Run quit
c. Run interface tunnel tunnel-numbei
The specified TE tunnel interface view is displayed.
d. Run mpls te pce delegate
The ingress is configured to delegate LSPs on the specified tunnel interface to the
PCE server.
Step 7 Run commit
----End
3.8.2 Specifying a Candidate Server for a PCE Client

Candidate servers can be specified for a PCE client to provide redundancy, which improves
network reliability.

Usage Scenario
PCE+ devices are classified as servers and clients. A client sends a request to the server to
calculate a path, and the server calculates a path. To specify a candidate PCE server for a PCE
client, run the connect-server command.
Multiple candidate PCE servers can be specified for a PCE client.
Procedure
The PCE client view.
A candidate server is specified for the PCE client.
The ip-address value is set to the source IP address of a PCE server. Repeat this step to
specify multiple candidate servers to provide redundancy.
Step 4 (Optional) Run preference preference
A preference value is assigned to a candidate PCE server.
The preference value is an integer ranging from 0 to 7. The greater the value, the higher the
preference.
When multiple candidate servers are specified for a single client, they can be prioritized. A
candidate server with the highest preference is selected to calculate paths.
If no preference value is set, the default value 0 is used, indicating the lowest preference. If
candidate servers have the same preference, the server with the smallest IP address is selected
to calculate paths.
Step 5 Run commit
----End
3.8.3 (Optional) Configuring PCEP Session Authentication

PCEP session authentication can be configured to improve network security and defend
against attacks.
Usage Scenario
Keychain authentication can be configured to secure a PCEP session established between the
PCE server and client, which prevents access of unauthorized users.
Procedure


A candidate server is specified for the PCE client.
Step 4 Run authentication_keychain keychain-name
Keychain authentication is configured for PCEP sessions established between the PCE client
and servers.
Step 5 Run commit
----End
3.8.4 (Optional) Configuring Timers for a PCE Client

The Keepalive timer, Hold timer, and LSP Delegate-hold timer can be set for a PCE client.
Usage Scenario
PCEP defines the Keepalive and Hold timers to maintain PCEP sessions. Both ends of a
PCEP session start these two timers. Each time the Keepalive timer expires, a local end
resends a Keepalive message. If no Keepalive message arrives after the Hold timer expires, a
local end considers the PCEP session disconnected.
Hold timer value = 4 x Keepalive timer value
After the Keepalive timer is set, the Hold timer value is automatically updated. However,
there are restrictions:
l The Hold timer value must be greater than or equal to the Keepalive timer value.
l Although setting a Keepalive timer value changes a Hold timer value, setting a Hold
timer value cannot change a Keepalive timer value.
l If the Keepalive time is set larger than 63s, the Hold timer remains 255s.
NOTE
Keepalive and Hold timers on both ends of a PCEP session are independent and can be assigned
different values. The two ends do not negotiate on a consistent value.
If a PCEP connection goes Down, a PCE client starts an LSP Delegate-hold timer. Before the
LSP Delegate-hold timer expires, the PCE client attempts to restore the PCEP connection to
the existing PCE server. After the LSP Delegate-hold timer expires, the PCE client attempts to
select another available PCE server to establish a PCEP session. The PCE client also starts an
LSP state timeout timer. Before this timeout timer expires, the delegated LSP status remains.
After the timeout timer expires, the PCE client is allowed to change the delegated LSP status
in the following situations:
l If the mpls te pce cleanup lsp-state command is run on the PCE client, the client deletes
the delegate LSP status and automatically uses a local path calculation function to
reestablish an LSP.
l If the mpls te pce cleanup lsp-state command is not run on the PCE client, the client
keeps attempting to establish a session with a PCE server.

Procedure
Step 3 Run timer { hold hold-time | keepalive keepalive-value | delegate-hold delegate-value |
state-timeout state-timeout-value }
Timers are set for the PCE client.
Default timer values are recommended.
Table 3-1 Parameter description

Parameter Description Value
hold hold-time Specifies the Hold timer The value is an integer

value. ranging from 0 to 255, in
seconds.
keepalive keepalive-time Specifies the Keepalive The value is an integer

timer value. ranging from 0 to 255, in
seconds.
delegate-hold delegate- Specifies the Delegate-hold The value is an integer

value timer value. ranging from 30 to 255, in
seconds.
state-timeout state-timeout- Specifies the value of the The value is an integer

value LSP state timeout timer. ranging from 0 to 1800, in
seconds.
Step 4 Run commit

----End
3.8.5 (Optional) Configuring a PCE Client to Delegate TE LSPs to

All PCE Servers
A PCE client can be configured to delegate TE LPSs to all PCE servers. This configuration
prevents a PCE server path calculation failure if forwarders select a master PCE server
different from that configured on a controller.
Usage Scenario
In a PCE+ scenario, forwarders (PCE clients) select the master and backup PCE servers. Each
PCE client delegates all TE LSPs to the selected or highest-priority PCE server. The PCE
server can then calculate paths for the delegated TE LSPs. In geographical redundancy, the
master and backup PCE servers are configured on controllers. In this situation, the forwarders

may select a master PCE server different from that configured on a controller, causing a
master PCE server inconsistency. After PCE clients delegate all TE LSPs to the selected PCE
server, the master PCE server configured on the controller cannot calculate paths. To prevent
a path calculation failure, run the multi-delegate enable command to enable a PCE client to
delegate TE LSPs to all PCE servers that have established PCEP sessions to the PCE client.
Procedure
Step 3 Run multi-delegate enable
The PCE client is enabled to delegate TE LSPs to all PCE servers along established PCEP
sessions.
Step 4 Run commit
----End
3.8.6 (Optional) Enabling a PCE Client to Support the IETF-

Compliant Association Object Format
A PCE client can be enabled to support the association object in the IETF-compliant format to
a PCE server.
Usage Scenario
A PCE server and a PCE client run PCEP to communicate. The PCEP protocol defines
multiple objects to be coded and decoded on both ends of a PCEP session. The association
object is one of them. The PCEP protocol does not support the coding or decoding of the non-
IETF association object. To address this issue, run the association-type enable command to
enable the PCE client to send the association object in the IETF-compliant format so that the
PCE server can code or decode the object.
Procedure
The PCE client view is displayed.
Step 3 Run association-type enable
A PCE client is enabled to support the association object in the IETF-compliant format.
Step 4 Run commit

----End
3.8.7 Verifying the PCE Configuration

After configuring the PCE function to calculate paths for MPLS TE tunnels, you can view
PCEP session information and PCEP statistics.
Prerequisites
The PCE function has been configured.
Procedure
l Run the display pce protocol session [ ip-address | verbose ] command to check PCEP
session information.
l Run the display pce protocol statistics [ ip-address ] command to check PCEP
statistics.
l Run the display mpls te tunnel-interface command to check PCE delegation type of the
TE tunnel.
----End
Example
Run the display pce protocol session verbose command. The command output shows that
the PCEP session is Up.
<HUAWEI> display pce protocol session verbose
Session IP : 7.7.7.7
Session ID : 73
State : UP
Keepalive Timer : 30
Hold Timer : 120
Peer Keepalive Timer : 30
Peer Hold Timer : 120
Session Capability : Stateful, PCE-Init, Segment-Routing, Label-Stitch
Session Preference : 3(YES)
Session Active Time : 2017-07-19 13:20:50
Last session down reason : Hold Timer Expired
Notification Status : Normal
Maximum Segment Depth : 10
Stitch Label Base : 321536
Stitch Label Size : 10240
Run the display pce protocol statistics command to view PCEP statistics.
<HUAWEI> display pce protocol session verbose
Remote IP : 10.10.10.9
Session ID : 125
Message statistics Sent Received
Open 1 1
Keepalive 62 62
Path computation request 0 0
Path computation response 0 0
LSP update 0 0
LSP report 11 0
LSP PCE-init 0 0
Notification 0 0
Error 0 0
Close 0 0

Label update 0 4
Label report 2 0
Total 74 63
Received unknown messages : 0
Received unknown requests : 0
Path computation statistics
Success : 0
Failure : 0
Timeout : 0
Minimum computation time (in seconds) : 0.000
Maximum computation time (in seconds) : 0.000
Run the display mpls te tunnel-interface command to view PCE delegation type.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0

ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
3.9 Configuring the IP-Prefix Tunnel Function

The ip-prefix tunnel function can be configured and used to establish P2P TE tunnels in a
batch, which simplifies the configuration.
Usage Scenario
When you want to create a large number of P2P TE tunnels or create P2P TE tunnels to form
a full-mesh network, creating them one by one is laborious and complex. To simplify MPLS
TE tunnel configuration, configure the ip-prefix tunnel function so that P2P TE tunnels can be
established in a batch.
The full-mesh network indicates that a P2P TE tunnel is established between any two nodes
on a network.
Before configuring the ip-prefix tunnel function, complete the following tasks:
l Configure an IGP to implement connectivity at the network layer.
l Configuring IGP TE (OSPF or IS-IS).
l (Optional) Configure TE attributes for links.

Figure 3-4 Flowchart for configuring the ip-prefix tunnel function
Configure an IP Prefix List.
Configure a P2P TE Tunnel Template.
Use the Automatic Primary Tunnel Function

to Establish P2P TE Tunnels in a Batch.
Mandatory procedure
Optional procedure
3.9.1 Configuring an IP Prefix List

An IP prefix list can be configured to define destination IP addresses used in the ip-prefix
tunnel function.
Procedure
Step 2 Run ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ip-address mask-
length [ greater-equal greater-equal-value ] [ less-equal less-equal-value ]
An IPv4 prefix list is configured.
The ip-prefix-name parameter specifies destination IP addresses that can or cannot be used to
establish a P2P TE tunnels.
Step 3 Run commit
----End
3.9.2 (Optional) Configuring a P2P TE Tunnel Template

A P2P TE tunnel template can be configured, and MPLS TE tunnel attributes can be set in the
template.
Usage Scenario
Before you create P2P TE tunnels in a batch, create a P2P TE tunnel template and configure
parameters, such as bandwidth and a path limit, in the template. The mpls te auto-primary-
tunnel command can then be run to reference this template. The device automatically uses the
parameters configured in the P2P TE tunnel template to create P2P TE tunnels in a batch.

Procedure
Step 2 Run mpls te p2p-template template-name
A P2P TE tunnel template is created, and the P2P TE tunnel template view is displayed.
Step 3 Select one or multiple operations.
Table 3-2 Operations
Operation Description
Run the bandwidth ct0 bw-value command Before bandwidth protection is provided for
to configure the CT0 bandwidth for MPLS traffic transmitted along a P2P TE tunnel,
TE tunnels. run the bandwidth command to set the CT0
bandwidth for the tunnel. Nodes on the P2P
TE tunnel can then reserve bandwidth for
services, which implements bandwidth
protection.
Run the record-route [ label ] command to This step enables nodes along a P2P TE
enable the route and label record for MPLS tunnel to use RSVP messages to record
TE tunnels. detailed P2P TE tunnel information,
including the IP address of each hop. The
label parameter in the record-route
command enables RSVP messages to record
label values.
Run the resv-style { se | ff } command to -

specify the resource reservation style for
MPLS TE tunnels.
Run the path metric-type { igp | te } -

command to specify the link metric type for
MPLS TE tunnels.
Run the affinity property properties An affinity is a 32-bit vector value used to
[ mask mask-value ] command to configure describe an MPLS link. An affinity and an
an affinity constraint for MPLS TE tunnels. administrative group attribute define the
nodes through which an MPLS TE tunnel
passes. Affinity masks determine the link
properties that should be checked by a
device. If some bits in the mask are 1, at
least one bit in an administrative group is 1,
and the corresponding bit in the affinity
must be 1. If the bits in the affinity are 0s,
the corresponding bits in the administrative
group cannot be 1.
You can use an affinity to control the nodes
through which a P2P TE tunnel passes.

Run the affinity primary { include-all | Before this command is run, run the path-
include-any | exclude } bit-name &<1-32> constraint affinity-mapping command in
command to configure an affinity for an the system view to create an affinity name
MPLS TE tunnel. template. In addition, run the attribute
affinity-name bit-sequence bit-number
command to configure the mappings
between affinity bit values and names in the
template view.
Run the hop-limit hop-limit-value Run this command to set the maximum
command to set the maximum number of number of hops that each CR-LSP in an
hops on an MPLS TE tunnel. MPLS TE tunnel supports.
Run the tie-breaking { least-fill | most-fill | -

random } command to configure a rule for
selecting a route among multiple routes to
the same destination.
Run the priority setup-priority [ hold- The setup priority of a tunnel must be no
priority ] command to set the setup and higher than its holding priority. To be
holding priority values for MPLS TE specific, a setup priority value must be
tunnels. greater than or equal to a holding priority
value.
If resources are insufficient, setting the
setup and holding priority values helps a
device release LSPs with lower priorities
and use the released resources to establish
LSPs with higher priorities.
Run the reoptimization [ frequency Periodic re-optimization allows an MPLS

interval ] command to enable the periodic TE tunnel to be automatically reestablished
re-optimization for MPLS TE tunnels. over a path with a lower cost. After a path
with a lower cost to the same destination
has been calculated for a specific reason,
such as a cost change, a TE tunnel will be
automatically reestablished, optimizing
resources on a network.
Run the bfd enable command to enable To rapidly detect LSP faults and improve
BFD for CR-LSP. network reliability, configuring BFD for
CR-LSP is recommended.
Run the bfd { min-tx-interval tx-interval | BFD parameters can be set to control BFD
min-rx-interval rx-interval | detect- detection sensitivity.
multiplier multiplier } * command to
configure BFD for CR-LSP parameters.
Run the fast-reroute [ bandwidth ] TE FRR is recommended for primary

command to enable TE FRR. MPLS TE tunnels, which improves network
reliability.

Run the bypass-attributes { bandwidth A bypass tunnel is established using the

bandwidth | priority setup-priority [ hold- configured bypass tunnel attributes. The
priority ] } * command to configure bypass bypass tunnel bandwidth cannot exceed the
tunnel attributes. primary tunnel bandwidth. The setup
priority of a bypass tunnel must be lower
than or equal to the holding priority. Both of
them must be lower than or equal to those of
the primary tunnel.
Run the lsp-tp outbound command to Physical links over which a TE tunnel is
enable traffic policing for MPLS TE established may also transmit traffic of other
tunnels. TE tunnels, non-CR-LSP traffic, or even IP
traffic, in addition to the TE tunnel traffic.
To limit TE traffic within a configured
bandwidth range, enable traffic policing for
a specific MPLS TE tunnel.
Step 4 Run commit

----End
3.9.3 Using the Automatic Primary Tunnel Function to Establish

P2P TE Tunnels in a Batch
The automatic primary tunnel function can be used to establish P2P TE tunnels in a batch.
Context
The automatic primary tunnel function uses a specified IP prefix list in which destination IP
addresses are defined so that tunnels to the destination IP addresses can be established in a
batch. The automatic primary tunnel function can also use a specified tunnel template that
defines public attributes before creating tunnels in a batch.
Procedure
Step 2 Run mpls te auto-primary-tunnel ip-prefix ip-prefix [ p2p-template template-name ]
The automatic primary tunnel function is configured.
Step 3 (Optional) Set the hold time for tunnels.
1. Run mpls
2. Run mpls te timer auto-primary-tunnel delay-delete time-value
The hold time for tunnels is set.

Step 4 Run commit
----End
Follow-up Procedure
If errors occur in services transmitted on a TE tunnel and the services cannot be restored, run
the reset mpls te auto-primary-tunnel command in the user view to reestablish the TE
tunnel to restore the services.
After this command is run, all LSPs in the specified tunnel are torn down and reestablished. If
some LSPs are transmitting traffic, the operation causes a traffic interruption. Exercise caution
when using this command.
3.9.4 Verifying the IP-Prefix Tunnel Function Configuration

After configuring the IP-prefix tunnel function, verify the tunnel information, including the
tunnel status, a P2P TE tunnel template used to establish tunnels, and IP prefix list.
Prerequisites
The IP-prefix tunnel function has been configured.
Operations
Table 3-3 Items to be checked and related commands
Operation Command
Check the display mpls te p2p-template

configuration of a P2P
TE tunnel template.
Check whether P2P TE display mpls te tunnel

tunnels are successfully
established using the
automatic primary
tunnel function.
Check detailed display mpls te tunnel-interface [ auto-primary-tunnel

information about the [ tunnel-name ] ]
automatic primary
tunnel function.

3.10 Configuring Dynamic Bandwidth Reservation

This section describes how to configure dynamic bandwidth reservation on an MPLS TE
interface. This configuration enables the MPLS TE interface dynamically reserve bandwidth
for an MPLS TE tunnel to account for the fact that physical bandwidth is variable.
Usage Scenario
A reservable bandwidth value is set on each interface along an MPLS TE tunnel. The MPLS
TE module checks whether links meets the bandwidth requirements of all tunnels based on
the reservable bandwidth. If a reservable bandwidth value is set on an interface and the
physical bandwidth changes on the interface, the MPLS TE module cannot correctly evaluate
link bandwidth resources because the available bandwidth may be less than the configured
reservable bandwidth. For example, a trunk interface has 1 Gbit/s physical bandwidth. Its
maximum reservable bandwidth is set to 800 Mbit/s, and its reserved bandwidth in the BC0
pool is set to 600 Mbit/s. If a trunk member fails, the trunk interface has its physical
bandwidth reduced to 500 Mbit/s, which fails to meet the requirements for the maximum
reservable bandwidth or the bandwidth in the BC0 pool. The MPLS TE module, however, still
attempts to reserve the configured bandwidth, and the bandwidth reservation attempt fails.
To remain the reserved bandwidth within the reservable bandwidth range, run the following
commands:
l mpls te bandwidth max-reservable-bandwidth dynamic: sets the proportion of the
maximum reservable bandwidth to the physical bandwidth on the interface.
l mpls te bandwidth dynamic: sets the proportion of the bandwidth in each BC pool to
the maximum reservable bandwidth.
The two proportions are used to enable MPLS TE to detect physical bandwidth changes along
links and preempt the bandwidth of an MPLS TE tunnel that requires bandwidth exceeding
the available link bandwidth. If soft preemption is supported by the preempted tunnel, traffic
on the tunnel can be smoothly switched to another links with sufficient bandwidth. The
smooth traffic switchover is also performed when an interface fails, which minimizes traffic
loss.
Before configuring dynamic bandwidth reservation, enable MPLS TE on the interface.
Procedure
Step 3 Run mpls te bandwidth max-reservable-bandwidth dynamic bw-value-percentage
The proportion of the maximum reservable bandwidth to the physical bandwidth is set.

NOTE
When both the mpls te bandwidth max-reservable-bandwidth dynamic command and the mpls te
bandwidth max-reservable-bandwidth command are run in a random order on an interface, the last
executed command takes effect.
Step 4 Run mpls te bandwidth dynamic bc0 bc0-bw-percentage

The proportion of the bandwidth in each BC pool to the maximum reservable bandwidth is
set.
NOTE
When both the mpls te bandwidth dynamic command and the mpls te bandwidth command are run in
a random order on an interface, the last executed command takes effect.
Step 5 Run commit

----End

Run the display mpls te link-administration bandwidth-allocation [ interface interface-
type interface-number ] command to check bandwidth information on a specified or all MPLS
TE interfaces.
<HUAWEI> display mpls te link-administration bandwidth-allocation interface
gigabitethernet 1/0/0
Link ID: GigabitEthernet1/0/0
Bandwidth Constraint Model : --
Physical Link Bandwidth(Kbits/sec) : 1000000
Maximum Link Reservable Bandwidth(Kbits/sec): 800000
Reservable Bandwidth BC0(Kbits/sec) : 480000
Reservable Bandwidth BC1(Kbits/sec) : 0
Downstream Bandwidth (Kbits/sec) : 0
IPUpdown Link Status : UP
PhysicalUpdown Link Status : UP
GracefulUpdown Link Status : DOWN
----------------------------------------------------------------------
TE-CLASS CT PRIORITY BW RESERVED BW AVAILABLE DOWNSTREAM
(Kbit/sec) (Kbit/sec) RSVPLSPNODE COUNT
----------------------------------------------------------------------
0 0 0 0 480000 0
1 0 1 0 480000 0
2 0 2 0 480000 0
3 0 3 0 480000 0
4 0 4 0 480000 0
5 0 5 0 480000 0
6 0 6 0 480000 0
7 0 7 0 480000 0
8 1 0 0 0 0
9 1 1 0 0 0
10 1 2 0 0 0
11 1 3 0 0 0
12 1 4 0 0 0
13 1 5 0 0 0
14 1 6 0 0 0
15 1 7 0 0 0
----------------------------------------------------------------------

3.11 Configuring P2MP TE Tunnels

A P2MP TE tunnel provides sufficient network bandwidth and high reliability for multicast
service transmission on an IP/MPLS backbone network.
Usage Scenario
The demand for multicast services, such as IPTV, multimedia conferences, and massively
multiplayer online role-playing games (MMORPGs), has steadily increased on IP/MPLS
backbone networks. These services require sufficient network bandwidth, assured quality of
service (QoS), and high reliability. The following multicast solutions are available, but are
insufficient for the requirements of multicast services or network carriers:
l IP multicast technology: deployed on a live P2P network with upgraded software. This
solution reduces upgrade and maintenance costs. IP multicast, similar to IP unicast, does
not support QoS or TE capabilities and has low reliability.
l Dedicated multicast network: deployed using asynchronous transfer mode (ATM) or
synchronous optical network (SONET)/synchronous digital hierarchy (SDH)
technologies. This solution provides high reliability and transmission rates, but has high
construction costs and requires separate maintenance.
IP/MPLS backbone network carriers require a multicast solution that has high TE capabilities
and can be implemented by upgrading existing devices.
P2MP TE is such a solution. It provides high reliability and QoS as well as TE capabilities.
P2MP TE can be implemented on an IP/MPLS backbone network by simple configuration to
provide multicast services, which reduces upgrade and maintenance costs and helps network
convergence.
P2MP TE tunnels can be manually or automatically established. Table 3-4 compares manual
P2MP tunnels with automatic P2MP TE tunnels.
Table 3-4 Comparison between manual and automatic P2MP TE tunnels
Item Manual P2MP TE Automatic P2MP TE

Tunnel Tunnel
Trigger method Manually triggered by users. Automatically triggered by

services.
Usage scenario Multicast services, NG MVPN or multicast

excluding NG MVPN or VPLS services are
multicast VPLS, are transmitted.
transmitted.
Traffic import method PIM or static IGMP is used Services are automatically
to direct services to LSPs. directed to LSPs.
Before configuring P2MP TE tunnels, complete the following tasks:

l Configure OSPF or IS-IS to implement IP connectivity between nodes on the P2MP TE

tunnel.
l Configure CSPF.
l Configure OSPF or IS-IS TE.
l (Optional) Configure MPLS TE attributes for links.
Figure 3-5 Flowchart for configuring P2MP TE tunnels
Manually triggered by users Automatically triggered by

services
Enable P2MP TE Globally Enable P2MP TE Globally
Disable P2MP TE on an Disable P2MP TE on an

Interface Interface
Setting Leaf Switching and

Configure Leaf Lists
Deletion Delays
Configure P2MP TE Tunnel

Configure Leaf Lists
Interfaces
Configuring a P2MP Tunnel

Template
Mandatory procedure
Optional procedure
3.11.1 Enabling P2MP TE Globally

This section describes how to enable P2MP TE globally on each node before a P2MP TE
tunnel is established.
Context
You can configure a P2MP TE tunnel only after P2MP TE is globally enabled on each node.

Procedure
Step 2 Run mpls
Step 3 Run mpls te
MPLS TE is enabled.
Step 4 Run mpls te p2mp-te
P2MP TE is globally enabled.
Step 5 Run commit
----End
3.11.2 (Optional) Disabling P2MP TE on an Interface

You can disable P2MP TE on a specific interface during the network planning.
Context
By default, after P2MP TE is globally enabled, P2MP TE is automatically enabled on each
MPLS TE-enabled interface on a local node. To disable P2MP TE on a specific interface
during network planning or there is no need to have P2MP TE enabled on a specific interface
because it does not support P2MP forwarding, disable P2MP TE on the specific interface.
Procedure
Step 3 Run mpls te p2mp-te disable
P2MP TE is disabled on the interface.
After the mpls te p2mp-te disable command is run, P2MP TE LSPs established on the
interface are torn down, and newly configured P2MP TE LSPs on the interface fail to be
established.
Step 4 Run commit
----End

3.11.3 (Optional) Setting Leaf Switching and Deletion Delays

To prevent two copies of traffic on a P2MP TE tunnel's egress, a leaf CR-LSP switchover
hold-off time and a deletion hold-off time can be set for MBB.
Context
Before the primary sub-LSP is deleted, both the primary sub-LSP and Modified sub-LSP
carry traffic. If the egress cannot receive traffic only from one sub-LSP, two copies of traffic
exist. To prevent two copies of traffic, perform the following steps to reset the leaf CR-LSP
switchover hold-off time and deletion hold-off time.
Procedure
Step 2 Run mpls
MPLS is enabled globally and the MPLS view is displayed.
Step 3 Run mpls te
A leaf CR-LSP switchover hold-off time and deletion hold-off time can be set only after
Step 4 Run mpls te p2mp-te leaf switch-delay delete-delay
A leaf CR-LSP switchover hold-off time and deletion hold-off time are set.
After the mpls te p2mp-te leaf switch-delay delete-delay command is run, traffic may be
interrupted if an ingress is idle but the egress is busy. In this situation, either of the following
may occur:
l The Modified sub-LSP has been ready on the ingress and the primary sub-LSP has been
deleted, but the Modified sub-LSP is not ready on the egress. If this occurs, when the
ingress switches traffic to the Modified sub-LSP, traffic is temporarily interrupted.
l The primary sub-LSP has been deleted, but the Modified sub-LSP failure message
cannot be immediately sent to the ingress. If this occurs, traffic is temporarily
interrupted.
Step 5 Run commit

----End
3.11.4 Configuring Leaf Lists

Configuring a leaf list on an ingress specifies all leaf nodes on a P2MP TE tunnel. A leaf list
helps you configure and manage these leaf nodes uniformly. The steps in this section must be

performed if P2MP TE tunnels are manually established. The steps in this section are optional
if the establishment of P2MP TE tunnels is automatically triggered by a service.
Context
For a P2MP TE tunnel, the path that originates from the ingress and is destined for each leaf
node can be calculated either by constraint shortest path first (CSPF) or by planning an
explicit path for a specific leaf node or each leaf node. After each leaf node is configured on
an ingress, the ingress sends signaling packets to each leaf node and then establishes a P2MP
TE tunnel. The NE40E uses leaf lists to configure and manage leaf nodes. All leaf nodes and
their explicit paths are integrated into a table, which helps you configure and manage the leaf
nodes uniformly.
An MPLS network that transmits multicast services selects dynamically leaf nodes on an
automatic P2MP TE tunnel and uses constrained shortest path first (CSPF) to calculate a path
destined for each leaf node. To control the leaf nodes of an automatic P2MP TE tunnel,
configure a leaf list.
Explicit path planning requires you to configure an explicit path for a specific leaf node or
each leaf node, and use the explicit path in the leaf list view.
NOTE
The configuration must prevent a remerge or crossover problem:

l Remerge event: occurs when two sub-LSPs have different inbound interfaces but the same
outbound interface on a transit node. Figure 3-6 shows that a remerge event occurs on the
outbound interface shared by two sub-LSPs.
l Crossover event: occurs when two sub-LSPs have different inbound and outbound interfaces on a
transit node. Figure 3-6 shows that a crossover event occurs on the transit node shared by the two
sub-LSPs.
Figure 3-6 Remerge and crossover events
Re-merge Cross-over
Sub-LSP1
Sub-LSP2
Procedure
Step 2 (Optional) Configure an explicit path to each leaf node.
1. Run explicit-path path-name
2. Run next hop ip-address [ include [ [ strict | loose ] | [ incoming | outgoing ] ] * |
exclude ]
A next-hop address is specified for the explicit path.

You can configure either the include or include parameter:

3. (Optional) Run add hop ip-address1 [ include [ [ strict | loose ] | [ incoming |
outgoing ] ] * | exclude ] { after | before } ip-address2
4. (Optional) Run modify hop ip-address1 ip-address2 [ include [ [ strict | loose ] |
[ incoming | outgoing ] ] * | exclude ]
The address of a node on the explicit path is changed.
5. (Optional) Run delete hop ip-address
A node is excluded from the explicit path.
6. Run commit
7. Run quit
For a P2MP TE tunnel, an explicit tunnel can be configured for a specific leaf node or each
leaf node.
Step 3 Run mpls te leaf-list leaf-list-name
A leaf list is established for a P2MP RSVP-TE tunnel.
Step 4 Run destination leaf-address
A leaf node is established in the leaf list.
The leaf-address parameter specifies the MPLS LSR ID of each leaf node.
Step 5 (Optional) Run path explicit-path path-name
An explicit path is specified for the leaf node.
The explicit-path path-name parameter specifies the name of the explicit path established in
Step 2.
NOTE
Repeat Step 3 and Step 4 on a P2MP TE tunnel to configure all leaf nodes.
Step 6 Run commit

----End
3.11.5 Configuring a P2MP TE Tunnel Interface

Configuring a tunnel interface on an ingress helps you to manage and maintain the P2MP TE
tunnel.
Context
A P2MP TE tunnel is established by binding multiple sub-LSPs to a P2MP TE tunnel
interface. A network administrator configures a tunnel interface to manage and maintain the
tunnel. After a tunnel interface is configured on an ingress, the ingress sends signaling packets
to all leaf nodes to establish a tunnel.

Procedure
Step 3 Run either of the following commands to assign an IP address to the tunnel interface:
l Run ip address ip-address { mask | mask-length } [ sub ]
An IP address is assigned to the tunnel interface.
l Run ip address unnumbered interface interface-type interface-number
The tunnel interface is allowed to borrow the IP address of a specified interface.
A tunnel interface must obtain an IP address before it can forward traffic. An MPLS TE
tunnel is unidirectional and does not need a peer address. Therefore, there is no need to
specifically configure an IP address for the tunnel interface. A TE tunnel interface usually
uses the ingress LSR ID as its IP address.
Step 5 Run mpls te p2mp-mode
A P2MP TE tunnel is established.
A tunnel ID is set.
Step 7 Run mpls te leaf-list leaf-list-name
A leaf list is specified for the P2MP TE tunnel.
Step 8 (Optional) Perform the following operations to set other tunnel attributes as needed:
Run mpls te bandwidth ct0 ct0-bw-value l A P2MP TE tunnel is established to

The bandwidth is configured for the tunnel. provide sufficient network bandwidth for
multicast services. Therefore, set the
bandwidth value.
l The bandwidth used by the tunnel cannot
be higher than the maximum reservable
link bandwidth.
l Ignore this step if the TE tunnel is used
only for changing the data transmission
path.

Run mpls te record-route [ label ] This step enables nodes along a P2MP TE
The route and label recording function is tunnel to use RSVP messages to record
enabled. detailed P2MP TE tunnel information,
including the IP address of each hop. The
label parameter in the record-route
command enables RSVP messages to record
label values.
Run mpls te resv-style { se | ff } -

A resource reservation style is specified.
Run mpls te path metric-type { igp | te } -

A link metric type used to select links is
specified.
Run mpls te affinity propertyy properties An affinity is a 32-bit vector value used to
[ mask mask-value ] describe an MPLS link. An affinity and an
An affinity and its mask are specified. administrative group attribute define the
nodes through which an MPLS TE tunnel
passes. Affinity masks determine the link
properties that a device must check. If some
bits in the mask are 1, at least one bit in an
administrative group is 1, and the
corresponding bit in the affinity must be 1.
If the bits in the affinity are 0s, the
corresponding bits in the administrative
group cannot be 1.
through which a manual P2MP TE tunnel
passes.
Run mpls te hop-limit hop-limit-value The mpls te hop-limit command sets the
The hop limit is set for sub-LSPs on the TE maximum number of hops that each sub-
tunnel. LSP in a P2MP TE tunnel supports.
Run mpls te tie-breaking { least-fill | -

most-fill | random
A rule for selecting a route among multiple
routes to the same destination is specified.
Run mpls te priority setup-priority [ hold- The setup priority of a tunnel must be no
priority ] higher than its holding priority. A setup
The priorities of the tunnel are set. priority value must be greater than or equal
to a holding priority value.
setup and holding priority values allows
LSPs with lower priorities to release
resources for establishing LSPs with higher
priorities.

Run mpls te reoptimization [ frequency Periodic re-optimization allows a P2MP TE

interval ] tunnel to be automatically reestablished
Periodic re-optimization is enabled for a over a better path. After a better path to the
manual P2MP TE Tunnel. same destination has been calculated for a
certain reason, such as a cost change, a TE
tunnel will be automatically reestablished,
optimizing resources on a network.
Run mpls te lsp-tp outbound Physical links over which a P2MP TE

Traffic policing is enabled for a manual tunnel is established transmit traffic of other
P2MP TE tunnel. TE tunnels, traffic of non-CR LSP traffic, or
even IP traffic, in addition to TE tunnel
traffic. To limit TE traffic within a
configured bandwidth range, run the mpls
te lsp-tp outbound command.
Step 9 (Optional) Run cspf disable

CSPF is disabled in the P2MP template.
NOTE
In an inter-domain scenario, this command is run if NG MVP triggers the creation of a dynamic P2MP
tunnel and a loose explicit path is configured in a P2MP template. Do not run this command in the other
situations.
Step 10 Run commit

----End
3.11.6 Configuring a P2MP Tunnel Template

Attributes can be set in a P2MP tunnel template that is used to automatically establish P2MP
TE tunnels.
Context
Attributes of an automatic P2MP TE tunnel can only be defined in a P2MP tunnel template,
but cannot be configured on a tunnel interface because the automatic P2MP TE tunnel has no
tunnel interface. When NG MVPN or multicast VPLS is deployed on a network, nodes that
transmit multicast traffic can reference the template and use attributes defined in the template
to automatically establish P2MP TE tunnels.
Procedure
Step 2 Run mpls te p2mp-template template-name
A P2MP tunnel template is created, and the P2MP tunnel template view is displayed.

Step 3 Select one or multiple operations.

Run leaf-list leaf-list-name When multicast services arrive at a node,

A leaf list is configured. the node automatically selects leaf nodes
and establishes a sub-LSP destined for each
leaf node.
This step enables a node that multicast
services access to select leaf nodes in a
specified leaf list.
NOTE
Before running the leaf-list command, the task
described in configuring a leaf list must be
complete. The leaf-list-name value in this step
must specify an existing leaf list.
Run bandwidth ct0 bw-value Before bandwidth protection is provided for

The CT0 bandwidth is set for the automatic traffic transmitted along an automatic P2MP
P2MP TE tunnel. TE tunnel, run the bandwidth command to
set the CT0 bandwidth for the tunnel. Nodes
on the P2MP TE tunnel can then reserve
bandwidth for services, which implements
bandwidth protection.
Run record-route [ label ] This step enables nodes along an automatic

The route and label record function is P2MP TE tunnel to use RSVP messages to
enabled. record detailed P2MP TE tunnel
information, including the IP address of
each hop. The label parameter in the
record-route command enables RSVP
messages to record label values.
Run resv-style { se | ff } -
A resource reservation style is specified.
Run path metric-type { igp | te } -

A link metric type used to select links is
specified.

Run affinity property properties [ mask An affinity is a 32-bit vector value used to
mask-value ] or affinity primary { include- describe an MPLS link. An affinity and an
all | include-any | exclude } bit-name administrative group attribute define the
&<1-32> nodes through which an MPLS TE tunnel
An affinity and its mask are specified. passes. Affinity masks determine the link
properties that a device must check. If some
bits in the mask are 1, at least one bit in an
administrative group is 1, and the
corresponding bit in the affinity must be 1.
If the bits in the affinity are 0s, the
corresponding bits in the administrative
group cannot be 1.
through which an automatic P2MP TE
tunnel passes.
Run hop-limit hop-limit-value The hop-limit command sets the maximum

The hop limit is set. number of hops that each sub-LSP in an
automatic P2MP TE tunnel supports.
Run tie-breaking { least-fill | most-fill | -

random }
A rule for selecting a route among multiple
routes to the same destination is specified.
Run priority setup-priority [ hold-priority ] The setup priority of a tunnel must be no

The setup and holding priorities are set. higher than its holding priority. A setup
priority value must be greater than or equal
to a holding priority value.
setup and holding priority values allows
LSPs with lower priorities to release
resources for establishing LSPs with higher
priorities.
Run reoptimization [ frequency interval ] Periodic re-optimization allows a P2MP TE

Periodic re-optimization is enabled for an tunnel to be automatically reestablished
automatic P2MP TE tunnel. over a better path. After a better path to the
same destination has been calculated for a
certain reason, such as a cost change, a TE
tunnel will be automatically reestablished,
optimizing resources on a network.
Run lsp-tp outbound Physical links over which a P2MP TE

Traffic policing is enabled for an automatic tunnel is established transmit traffic of other
P2MP TE tunnel. TE tunnels, traffic of non-CR LSP traffic, or
even IP traffic, in addition to TE tunnel
traffic. To limit TE traffic within a
configured bandwidth range, run the lsp-tp
outbound command.

Step 4 Run commit

----End
3.11.7 (Optional) Configuring the Reliability Enhancement

Function for a P2MP Tunnel
Configure a function to improve service reliability as needed.
Context
To improve reliability of traffic transmitted along a P2MP tunnel, configure either of the
following reliability enhancement functions:
l Multicast load balancing on a trunk interface
Without this function, a device randomly selects a trunk member interface to forward
multicast traffic. If this member interface fails, multicast traffic is interrupted. With this
function, multicast traffic along a P2MP tunnel is balanced among all trunk member
interfaces. This function helps improve service reliability and increase available
bandwidth for multicast traffic.
l MPLS P2MP load balancing
To enable P2MP load balancing globally, run the mpls p2mp force-loadbalance enable
command. In a multicast scenario where load balancing is configured in the Eth-Trunk
interface view, if a leaf node connected to the Eth-Trunk interface joins or quits the
multicast model, packet loss occurs on the other leave nodes connected to the non-Eth-
Trunk interfaces due to the model change. After the mpls p2mp force-loadbalance
enable command is run, load balancing is forcibly enabled in the system view, therefore
preventing packet loss.
l WTR time for traffic to be switched from the mLDP P2MP FRR path to the primary path
If the primary path of the mLDP P2MP FRR or P2MP TE path fails, traffic is switched
to the FRR path on the forwarding plane. Before mLDP converges on a downstream
node, traffic switches back to the restored primary path within the default WTR time
after which traffic will switch back to the primary path. If only some entries are
generated for the primary path within the period, some packets are dropped when traffic
switches back to the primary path. To prevent packet loss, run the mpls p2mp frr-wtr
command to set the delay time for traffic to be switched from the mLDP P2MP FRR or
P2MP TE path to the primary path.
Procedure
l Configure rapid MPLS P2MP switching.
a. Run system-viewThe system view is displayed.
b. Run mpls p2mp fast-switch enableRapid MPLS P2MP switching is enabled.
c. Run commitThe configuration is committed.
l Configure multicast load balancing on a trunk interface.
b. To enter the trunk interface view, run either of the following commands:
n interface eth-trunk trunk-id or interface ip-trunk trunk-id

c. Run multicast p2mp load-balance enableMulticast traffic load balancing is

enabled on the trunk interface that functions as an outbound interface on a P2MP
tunnel.
d. Run multicast p2mp root load-balance enable
Trunk load balancing for multicast traffic is enabled in the P2MP tunnel of a root
node
e. Run commitThe configuration is committed.
l Configure MPLS P2MP load balancing.
b. Run mpls p2mp force-loadbalance enableMPLS P2MP load balancing is enabled
globally.
c. Run multicast p2mp load-balance number load-balance_numberThe number of
trunk member interfaces that balance multicast traffic on a P2MP tunnel is set.
d. Run commitThe configuration is committed.
l Set the WTR time for traffic to be switched from the mLDP P2MP FRR path to the
primary path.
b. Run mpls p2mp frr-wtr time-valueThe delay time is set for traffic to be switched
from the mLDP P2MP FRR path to the primary path.
c. Run commitThe configuration is committed.
----End
3.11.8 Verifying the P2MP TE Tunnel Configuration

After configuring a P2MP TE tunnel, you can view information about the tunnel when it is in
the Up state.
Prerequisites
A P2MP TE tunnel has been configured.
Procedure
l Run the display mpls te p2mp tunnel-interface command to check information about
the P2MP TE tunnel interface on the ingress and all sub-LSPs.
l Run the display mpls te p2mp-template command to check P2MP TE tunnel template
configurations and information about P2MP TE tunnels established using this template.
l Run the display mpls te leaf-list command to check information about the leaf list
configured on the ingress.
l Run the display mpls te p2mp tunnel path command to check the path attributes of the
P2MP TE tunnel.
l Run the display mpls multicast-lsp protocol p2mp-te command to check the sub-LSP
status and MPLS forwarding entries, including the incoming label, outgoing label,
inbound interface, and outbound interface of each sub-LSP.
l Run the display mpls multicast-lsp statistics protocol p2mp-te command to check
statistics about sub-LSPs that pass through a local node.

l Run the display mpls rsvp-te p2mp lsp command to check information about RSVP
signaling of the P2MP LSP.
l Run the display mpls rsvp-te p2mp statistics command to check statistics about the
RSVP signaling packets sent and received over the P2MP TE tunnel.
l Run the display mpls rsvp-te p2mp session command to check information about
RSVP P2MP sessions.
----End
Example
After configuring a P2MP TE tunnel, run the following commands to check whether the
configuration has taken effect.
Run the display mpls te p2mp tunnel-interface command to view information about the
P2MP TE tunnel interface on the ingress and all sub-LSPs. The command output shows that
the tunnel is Up, and each sub-LSP is Up.
<HUAWEI> display mpls te p2mp tunnel-interface Tunnel 10
------------------------------------------------------------------------------
Tunnel10
------------------------------------------------------------------------------
P2MP Template : -
Tunnel State : UP
Session ID : 100
Ingress LSR ID : 1.1.1.1 P2MP ID : 0x1010101
Primary LSP State : UP
------------------------------------------------------------------------------
Main LSP State : UP LSP ID : 7
------------------------------------------------------------------------------
S2L Dest Addr : 3.3.3.3 State : UP
Run the display mpls te leaf-list verbose command to view information about each leaf list
configured on the ingress and used by each tunnel.
<HUAWEI> display mpls te leaf-list verbose
------------------------------------------------------------
P2MP-Leaf-List
------------------------------------------------------------
Name : leaf1 Status : Enabled
1 3.3.3.3 with path pe1tope2
2 4.4.4.4 with path pe1tope3
Run the display mpls te p2mp-template command. The command output shows P2MP TE
tunnel template configurations and information about P2MP TE tunnels established using this
template.
<HUAWEI> display mpls te p2mp-template verbose
------------------------------------------------------------
P2MP-Template
------------------------------------------------------------
Name : t1
Tie-breaking Policy : None Metric Type : None
Bfd Capability : Enabled Resv Style : SE
Bfd Min Tx(ms) : 200 Bfd Min Rx(ms) : --
Bfd Detect Multiplier: 3
Reoptimization : Disabled Reopt Freq(sec): --
IncludeAll : 0x0 IncludeAny : 0x0
ExcludeAny : 0x0
Setup Priority : 7 Hold Priority : 7
Record Route : Enabled Record Label : Enabled
Lsp-tp Outbound : Enabled Hop Limit : 32

Leaf-list Name : leaf1

FRR Flag : Enabled FRR Bandwidth : Disabled
Bypass Bandwidth : --
Bypass Setup Priority: 7 Bypass Hold Priority: 7
List of P2MP auto-tunnels using this template:

P2MPt132769
Number of P2MP auto-tunnels using this template: 1
Run the display mpls te p2mp tunnel path command to check the path attributes of the
P2MP TE tunnel.
NOTE
Before running the display mpls te p2mp tunnel path command, run the mpls te record-route [ label ]
command to enable the route and label recording functions.
The command output shows the path information of each sub-LSP over the P2MP TE tunnel
and the label assigned to each network segment.
<HUAWEI> display mpls te p2mp tunnel path
Tunnel Interface Name : Tunnel1
Lsp ID : 1.1.1.1 :100 : 0x1010101 :5
S2L Dest Addr: 4.4.4.4
Sub-Group Originator ID:1.1.1.1 Sub-Group ID:1
Hop Information
Hop 0 10.1.1.1
Hop 1 10.1.1.2 Label 32768
Hop 2 2.2.2.2 Label 32768
Hop 3 10.2.1.1 Local-Protection available
Hop 4 10.2.1.2 Label 32768
Hop 5 4.4.4.4 Label 32768

Lsp ID : 1.1.1.1 :100 : 0x1010101 :5
Hop Information
Hop 0 10.1.1.1
Hop 1 10.1.1.2 Label 32768
Hop 2 2.2.2.2 Label 32768
Hop 3 10.4.1.1
Hop 4 10.4.1.2 Label 32768
Hop 5 5.5.5.5 Label 32768
Run the display mpls multicast-lsp protocol p2mp-te command to view the sub-LSP status
and MPLS forwarding entries, including the destination address, incoming label, outgoing
label, inbound interface, and outbound interface of each sub-LSP.
<HUAWEI> display mpls multicast-lsp protocol p2mp-te
-------------------------------------------------------------------------------
LSP Information: RSVP P2MP-LSP
-------------------------------------------------------------------------------
No : 1
Session ID : 100 Ingress LSR ID : 1.1.1.1
Local LSP ID : 7 P2MP ID : 0x1010101
Forward ID : 0xE1 LSR Type : Ingress
LSP Age : 2013-06-18 11:38:57.000
Insegment Count: 0 Outsegment Count: 1
Outsegment :
Out Label : 4096 Out Interface : GigabitEthernet3/0/1

Next Hop : 10.1.1.2 Token : 0xa2

MTU : 1500
Run the display mpls multicast-lsp statistics protocol p2mp-te command to view statistics
about sub-LSPs that pass through a local node.
<HUAWEI> display mpls multicast-lsp statistics protocol p2mp-te
----------------------------------------------------------------------
P2MP Statistics
----------------------------------------------------------------------
Lsp Type Total Ingress Transit Egress
P2MP SUB LSP 3 3 0 0
----------------------------------------------------------------------
Lsp Type IngressLspBypassState TransitLspBypassState
ExistNotUsed InUse ExistNotUsed InUse
P2MP SUB LSP 0 0 0 0
----------------------------------------------------------------------
Run the display mpls rsvp-te p2mp statistics command to view statistics about RSVP
signaling packets sent and received over the P2MP TE tunnel.
<HUAWEI> display mpls rsvp-te p2mp statistics
LSR ID: 1.1.1.1
In Path Group Count: 3 Out Path Group Count: 3
Out Resv Group Count: 3 In Resv Group Count: 3
In-Branch Count: 1 Out-Branch Count: 1
P2MP LSP Count: 1 S2L SUB-LSP Count: 3
Send Path Count: 20 Receive Path Count: 0
Send Resv Count: 0 Receive Resv Count: 20
Send PathErr Count: 0 Receive PathErr Count: 0
Send ResvErr Count: 0 Receive ResvErr Count: 0
Send PathTear Count: 0 Receive PathTear Count: 0
Send ResvTear Count: 0 Receive ResvTear Count: 0
Send ErrMsg: 0 Receive ErrMsg: 0
In Path Group Cleanup Count: 0
In Resv Group Cleanup Count: 0
PLR Avail Out Path Group Count: 0 PLR Inuse Out Path Group Count: 0
MP Avail In Path Group Count: 0 MP Inuse In Path Group Count: 0
Total reliable delivery Statistics Information:
RetransPacketCounter: 0 RepPacketCounter: 0
RetransPathCounter: 0 RepPathCounter: 0
RetransResvCounter: 0 RepResvCounter: 0
RetransResvConfCounter: 0 RepResvConfCounter: 0
RetransPathErrCounter: 0 RepPathErrCounter: 0
RetransResvErrCounter: 0 RepResvErrCounter: 0
RetransPathTearCounter: 0 RepPathTearCounter: 0
RetransResvTearCounter: 0 RepResvTearCounter: 0
RetransSrefreshCounter: 0 RepSrefreshCounter: 0
RetransRecoveryPathMsgCounter: 0 RepRecoveryPathMsgCounter: 0
RetransGRPathMsgCounter: 0 RepGRPathMsgCounter: 0
RetransNotifyMsgCounter: 0 RepNotifyMsgCounter: 0
Run the display mpls rsvp-te p2mp session command to view information about RSVP
P2MP sessions.
<HUAWEI> display mpls rsvp-te p2mp session
----------------------------------------------------------------------
P2MP Session
----------------------------------------------------------------------
P2MP ID: 0x1010101 Session ID: 100
Ingress LSR ID: 1.1.1.1 Style: SE
LSP Count: 1
LSP ID List: 135
Run the display mpls rsvp-te p2mp lsp command to view statistics about all sub-LSPs.
<HUAWEI> display mpls rsvp-te p2mp lsp
----------------------------------------------------------------------
P2MP LSP

----------------------------------------------------------------------
P2MP ID: 0x1010101 Session ID: 100
Ingress LSR ID: 1.1.1.1 LSP ID: 134
In Path Group Count: 3 Out Path Group Count: 3
S2L Count: 3 Up S2L Count: 3
S2L Destination address: 3.3.3.3 States: UP
3.12 Adjusting RSVP Signaling Parameters

RSVP-TE supports various signaling parameters, which meet requirements for reliability and
network resources, and requirements of MPLS TE advanced functions.
Usage Scenario
RSVP TE supports diversified signaling parameters, which meet requirements of reliability
and network resources and some MPLS TE advanced features.
Before adjusting RSVP signaling parameters, enable MPLS TE and RSVP-TE.
Perform one or more of the following configurations as required.
3.12.1 Configuring the RSVP Hello Extension

The RSVP Hello extension rapidly monitors the connectivity of RSVP neighbors.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te hello
The RSVP Hello extension is enabled on the local node.
Step 4 Run mpls rsvp-te hello-lost times
The maximum number of Hello messages that can be discarded is set.
Step 5 Run mpls rsvp-te timer hello interval
The interval at which Hello messages are refreshed is set.
NOTE
If the refresh interval is changed, the modification takes effect after the existing refresh timer expires.
The interval must be longer than the time a device takes to perform a master/slave main control board
switchover. If the interval is set to less than the switchover time, a protocol intermittent interruption
occurs during a switchover. The default timer value is recommended.

Step 6 Run quit
The view of an RSVP-enabled interface is displayed.
The RSVP Hello extension is enabled on an interface.
The RSVP Hello extension rapidly detects the reachability of RSVP neighbors. For details,
see relevant standards.
Step 9 Run commit
----End
3.12.2 Configuring an RSVP Timer

An RSVP timer is configured to define the interval at which Path and Resv messages are
refreshed, and the timeout multiplier associated with the RSVP blocked state is also
configured.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te timer refresh interval
The interval at which Path and Resv messages are refreshed is set.
NOTE
If the refresh interval is modified, the modification takes effect after the existing refresh timer expires.
Do not set a long refresh interval or frequently modify a refresh interval.
Step 4 Run mpls rsvp-te keep-multiplier number
The PSB and RSB timeout multiplier is set.
Step 5 Run commit
----End

3.12.3 (Optional) Configuring Reliable RSVP Message

Transmission
When BFD is not configured on a network, reliable RSVP message transmission can be
configured to increase the success rate of detecting link faults, which minimize long-time
traffic loss inducted by link intermittent disconnections.
Procedure
Step 2 Run mpls
Step 3 Run mpls te
RSVP-TE is enabled.
Step 5 Run mpls rsvp-te reliable-delivery
Reliable RSVP message transmission is enabled.
Step 6 Run commit
----End
3.12.4 Configuring RSVP-TE Srefresh

Enabling Summary Refresh (Srefresh) on interfaces connecting two RSVP neighboring nodes
reduces the network cost and improves network performance. After Srefresh is enabled,
retransmission of Srefresh messages will be automatically enabled on interfaces.
Procedure
Step 2 Run mpls
Srefresh enabled in the MPLS view takes effect on an entire device.
Step 3 Run mpls rsvp-te srefresh
Srefresh is enabled.
Step 4 (Optional) Run mpls rsvp-te timer retransmission { increment-value increment |
retransmit-value interval } *

The retransmission parameters are set.
Step 5 (Optional) Enable the summary refresh (Srefresh) forward compatibility.

1. Run quit

2. Run interface interface-type interface-number
3. Run mpls rsvp-te srefresh compatible
The summary refresh (Srefresh) forward compatibility is enabled.
When the primary and backup CR-LSPs share the same link, the node on both ends of the link
may run different versions. If the upstream nodes run a version earlier than V8 and the
downstream node runs V8, Srefresh incompatibility occurs. To address this problem, run the
mpls rsvp-te srefresh compatible command on the interface that connects the downstream
device to the upstream node to enable Srefresh compatibility.
NOTE
This command can only be run on a downstream node running V8 when its upstream node runs a
version earlier than V8, which ensures that Srefresh can be properly negotiated between the two nodes.
Step 6 Run commit
----End
3.12.5 Enabling RSVP-TE Reservation Confirmation

RSVP-TE reservation confirmation configured on the egress of a tunnel verifies that resources
are successfully reserved.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te resvconfirm
RSVP-TE reservation confirmation is enabled.
After a node receives a Path message, it initiates reservation confirmation by sending a Resv
message carrying an object that requests for reservation confirmation.
NOTE
Receiving ResvConf messages does not mean that resource reservation is successful. It means that,
however, resources are reserved successfully only on the farthest upstream node where this Resv
message arrives. These resources may be preempted by other applications later.
Step 4 Run commit

----End
3.12.6 Changing the PSB and RSB Timeout Multiplier

The PSB and RSB timeout multiplier defines the maximum number of signaling packets that
can be discarded in a weak signaling environment.
Procedure
Step 2 Run mpls
Step 3 Run mpls rsvp-te keep-multiplier number
The PSB and RSB timeout multiplier is set.
NOTE
Set the PSB and RSB timeout multiplier greater than or equal to 5. This setting prevents the PSB and
RSB from aging or being deleted if the PSB and RSB fail to refresh when a great number of services are
transmitted.
Step 4 Run commit
----End
3.12.7 Verifying the Configuration of Adjusting RSVP Signaling

Parameters
After adjusting RSVP signaling parameters, you can view the refresh parameters, RSVP
reservation confirmation status, RSVP Hello extension status, and RSVP timer parameters.
Prerequisites
RSVP signaling parameters have been adjusted.
Procedure
l Run the display mpls rsvp-te command to check RSVP-TE configurations.
l Run the display mpls rsvp-te psb-content [ ingress-lsr-id tunnel-id lsp-id ] command to
check RSVP-TE PSB information .
l Run the display mpls rsvp-te rsb-content [ ingress-lsr-id tunnel-id lsp-id ] command to
check RSVP-TE RSB information.
l Run the display mpls rsvp-te statistics { global | interface [ interface-type interface-
number ] } command to check RSVP-TE statistics.
----End

Example
Run the following commands to check the previous configurations.
Run the display mpls rsvp-te command to view RSVP-TE configurations. For example:
<HUAWEI> display mpls rsvp-te
LSR ID: 1.1.1.1
Resv Confirmation Request: DISABLE
RSVP Hello Extension: DISABLE
Hello interval: 3 sec Max Hello misses: 4
Path and Resv message refresh interval: 30 sec
Path and Resv message refresh retries count: 3
Blockade Multiplier: 4
Graceful-Restart Capability: None
Run the display mpls rsvp-te psb-content command to view information about the RSVP-
TE PSB. For example:
<HUAWEI> display mpls rsvp-te psb-content
==============================================================
The PSB Content
==============================================================
Tunnel Addr: 3.3.3.3 Exist time: 0h 32m 6s
Tunnel ExtID: 4.4.4.4 Session ID: 502
Ingress LSR ID: 4.4.4.4 Local LSP ID: 1688
Previous Hop: ---- Next Hop: 10.4.1.2
Incoming / Outgoing Interface: ---- / GigabitEthernet1/0/0
InLabel: NULL OutLabel: 16
Send Message ID: 0 Recv Message ID: 0
Session Attribute-
SetupPrio: 7 HoldPrio: 7
SessionAttrib: SE Style desired
CSPF Route Flag: False
LSP Type: -
FRR Flag: No protection Local RRO Flag: 0x0
FRR Mode: -
ERO Information-
L-Type ERO-IPAddr ERO-PrefixLen Label
ERHOP_STRICT 10.4.1.2 32
RRO Information-
-----
SenderTspec Information-
Token bucket rate: 1250000
Token bucket size: 1000
Peak data rate: 1250000
Minimum policed unit: 0
Maximum packet size: 1500
CT-BandWidth Information(Bytes/sec):
CT0 Bandwidth: 1250000 CT1 Bandwidth: 0
Path Message arrive on Unknown(0x0) from PHOP 0.0.0.0
Path Message sent to NHOP 10.4.1.2 on GigabitEthernet1/0/0
Resource Reservation OK
PADS Ability: Enable
LSP Statistics Information:

SendPacketCounter : 1627 RecvPacketCounter : 0
SendPathCounter : 1627 RecvPathCounter : 0
SendResvCounter : 0 RecvResvCounter : 0
SendPathErrCounter : 0 RecvPathErrCounter : 0
SendResvErrCounter : 0 RecvResvErrCounter : 0
SendPathTearCounter: 0 RecvPathTearCounter: 0
SendResvTearCounter: 0 RecvResvTearCounter: 0

SendSrefreshCounter: 0 RecvSrefreshCounter: 0
-------------------------------------------------------------------------------
The PSB Content
-------------------------------------------------------------------------------
Session Attribute:
LSP Type: -
FRR Mode: -
ERO Information:
XRO Information:
L-Type XRO-IPAddr XRO-PrefixLen Attribute-Type
XRO_Avoid 13.1.1.1 32 Interface
XRO_Avoid 3.3.3.3 32 Node
XRO_Avoid 5.5.5.5 32 Node
Peak data rate: 0
PADS Ability: Enable

SendPacketCounter : 1615 RecvPacketCounter : 0
SendPathCounter : 1615 RecvPathCounter : 0
SendResvCounter : 0 RecvResvCounter : 0
SendPathErrCounter : 0 RecvPathErrCounter : 0
SendResvErrCounter : 0 RecvResvErrCounter : 0
Run the display mpls rsvp-te rsb-content command to view information about the RSVP-TE
RSB. For example:
<HUAWEI> display mpls rsvp-te rsb-content
==============================================================
The RSB Content
==============================================================
Tunnel Addr: 3.3.3.3 Session Tunnel ID: 502
Tunnel ExtID: 4.4.4.4
Next Hop: 10.4.1.2 Reservation Style: SE Style

Reservation Incoming Interface: GigabitEthernet1/0/0

Reservation Interface: GigabitEthernet1/0/0
Message ID: 0
Filter Spec Information-
The filter number: 1
Ingress LSR ID: 4.4.4.4 Local LSP ID: 1688 OutLabel: 16
Cleanup Timer : -
RRO Information-
-----
FlowSpec Information-
Peak data rate: 1250000
Bandwidth guarantees: 0
Delay guarantees: 0
Qos Service is Controlled
Resv Message arrive on GigabitEthernet1/0/0 from NHOP 10.4.1.2
Run the display mpls rsvp-te statistics global command to view RSVP-TE statistics. For
example:
<HUAWEI> display mpls rsvp-te statistics global
--------------------------------------------------------------------------
RSVP-TE Global Statistic
--------------------------------------------------------------------------
LSR ID: 4.4.4.4 LSP Count: 2
PSB Count: 2 RSB Count: 2
RFSB Count: -
FRR statistics information:
PLR AvailLsps: 0 PLR InuseLsps: 0
MP AvailLsps: 0 MP InuseLsps: 0
Total Statistics Information:
PSB CleanupTimeOutCounter: 0 RSB CleanupTimeOutCounter: 0
SendPacketCounter: 125 RecPacketCounter: 116
SendCreatePathCounter: 3 RecCreatePathCounter: 0
SendRefreshPathCounter: 115 RecRefreshPathCounter: 0
SendCreateResvCounter: 2 RecCreateResvCounter: 2
SendRefreshResvCounter: 0 RecRefreshResvCounter: 113
SendResvConfCounter: 0 RecResvConfCounter: 0
SendHelloCounter: 0 RecHelloCounter: 0
SendAckCounter: 0 RecAckCounter: 0
SendPathErrCounter: 0 RecPathErrCounter: 1
SendResvErrCounter: 0 RecResvErrCounter: 0
SendPathTearCounter: 1 RecPathTearCounter: 0
SendResvTearCounter: 0 RecResvTearCounter: 0
SendSrefreshCounter: 0 RecSrefreshCounter: 0
SendAckMsgCounter: 0 RecAckMsgCounter: 0
SendChallengeMsgCounter: 0 RecChallengeMsgCounter: 0
SendResponseMsgCounter: 0 RecResponseMsgCounter: 0
SendErrMsgCounter: 0 RecErrMsgCounter: 0
SendRecoveryPathMsgCounter: 0 RecRecoveryPathMsgCounter: 0
SendGRPathMsgCounter: 0 RecGRPathMsgCounter: 0
SendNotifyMsgCounter: 0 RecNotifyMsgCounter: 0
ResourceReqFaultCounter: 0
Bfd neighbor count: 0 Bfd session count: 0
3.13 Configuring RSVP Authentication

RSVP authentication is configured to protect a node from attacks and improve network
security. By default, no authentication mode is configured. Configuring RSVP authentication
is recommended to improve device security.

Usage Scenario
RSVP authentication prevents the following problems:
l An unauthorized node attempts to establish an RSVP neighbor relationship with a local
node.
l A remote node constructs forged RSVP messages to establish an RSVP neighbor
relationship with a local node and then initiates attacks to the local node.
RSVP key authentication cannot prevent replay attacks or RSVP message mis-sequence
during network congestion. RSVP message mis-sequence causes authentication termination
between RSVP neighbors. The handshake function, message window functions, and RSVP
key authentication are used to prevent the preceding problems.
CR-LSP flapping may lead to frequent re-establishment of RSVP neighbor relationships. As a
result, the handshake function is repeatedly performed and RSVP authentication is prolonged.
An RSVP authentication lifetime is set to resolve the preceding problems. If no CR-LSP
exists, RSVP neighbors still retain their neighbor relationship until the RSVP authentication
lifetime expires.
Before configuring RSVP authentication, configure an RSVP-TE tunnel.
Figure 3-7 RSVP authentication configuration
Configure an RSVP authentication key.
Configure the RSVP authentication lifetime.
Configure the handshake function.
Configure the message window function.
Mandatory
Optional
3.13.1 Configuring an RSVP Authentication Mode

RSVP authentication modes are configured between RSVP neighboring nodes or between the
interfaces of RSVP neighboring nodes. The keys on both ends to be authenticated must be the

same; otherwise, RSVP authentication fails, and RSVP neighboring nodes discard received
packets.
Context
RSVP authentication in the key mode is used to prevent an unauthorized node from
establishing an RSVP neighbor relationship with a local node. It can also prevent a remote
node from constructing forged packets to establish an RSVP neighbor relationship with the
local node.
The NE40E supports three RSVP key authentication modes, as shown in Figure 3-8.
Figure 3-8 RSVP key authentication networking
PLR MP
LSRA LSRB
Primary LSP
Bypass LSP
l Local interface-based authentication

Local interface-based authentication is performed between interfaces connecting a point
of local Repair (PLR) and a merge point (MP) in an inter-domain MPLS TE FRR
scenario.
– Local interface-based authentication is recommended on a network configured with
inter-domain MPLS TE FRR.
– Local interface- or neighbor interface-based authentication can be used on a
network that is not configured with inter-domain MPLS TE FRR.
l Neighbor node-based authentication
Neighbor node-based authentication takes effect on an entire device. It is usually
performed between a PLR and an MP based on LSR IDs.
This authentication mode is recommended on a network with non-inter-domain MPLS
TE FRR.
l Neighbor interface-based authentication
Neighbor interface-based authentication is performed between interfaces connecting two
LSRs. For example, neighbor interface-based authentication is performed between
interfaces connecting LSRA and LSRB shown in the Figure 3-8.
Local interface- or neighbor address-based authentication can be used on a network that
is not configured with inter-domain MPLS TE FRR.
Each pair of RSVP neighbors must use the same key; otherwise, RSVP authentication fails,
and all received RSVP messages are discarded.
Table 3-7 describes differences between local interface-, neighbor node-, and neighbor
address-based authentication modes.

Table 3-7 Principle for RSVP authentication mode selection

RSVP Key Local Interface- Neighbor Node- Neighbor Interface-based
Authenticat based based Authentication
ion Authentication Authentication
Authenticatio Local interface- RSVP neighbor- RSVP neighbor interface-based

n mode based based authentication
authentication authentication
Priority High Medium Low
Applicable Any network Non-inter-area Networks on which MPLS TE

environment network FRR is enabled and primary
CR-LSPs are in the FRR Inuse
state
Advantages N/A Simplex N/A

configuration
Procedure
l Configure RSVP key authentication in neighbor address-based mode.
a. Run system-view
b. Run interface interface-type interface-number
c. Run mpls rsvp-te authentication { { cipher | plain } auth-key | keychain
keychain-name }
The key for RSVP authentication is configured.
HMAC-MD5 or keychain authentication can be configured based on the selected
parameter:
n cipher: HMAC-MD5 authentication is used, and a key is displayed in
ciphertext.
n plain: HMAC-MD5 authentication is used, and a key is displayed in simple
text.
n keychain: Keychain authentication is used, and a globally configured keychain
is referenced.
If you configure a simple password, it will be saved in the configuration file in

plaintext that has a high security risk. Therefore, configuring a ciphertext password
is recommended. To improve the device security, periodically change the password.
Configuration must be complete on the two directly connected interfaces within
three update periods. If configuration is not complete after three update periods
elapse, the session goes Down.

d. Run commit

l Configure RSVP key authentication in neighbor-based mode.
a. Run system-view

b. Run mpls

c. Run mpls rsvp-te peer peer-address
The RSVP neighbor view is displayed.

d. Run mpls rsvp-te authentication { { cipher | plain } auth-key | keychain
keychain-name }
The key for RSVP authentication is configured.
HMAC-MD5 or keychain authentication can be configured based on the selected

parameter:
n cipher: HMAC-MD5 authentication is used, and a key is displayed in

ciphertext.
n plain: HMAC-MD5 authentication is used, and a key is displayed in simple
text.
n keychain: Keychain authentication is used, and a globally configured keychain
is referenced.
If you configure a simple password, it will be saved in the configuration file in

plaintext that has a high security risk. Therefore, configuring a ciphertext password
is recommended. To improve the device security, periodically change the password.
Configuration must be complete on the two neighboring nodes within three update
periods. If configuration is not complete after three update periods elapse, the
session goes Down.
e. (Optional) Run mpls rsvp-te challenge-lost peer-address
The maximum number of allowable discarded challenge messages that are sent by
the supplicant to the authenticator during RSVP authentication is set.
f. (Optional) Run mpls rsvp-te retrans-timer challenge retransmission-interval
The interval at which challenge messages are retransmitted is set.

g. Run commit
----End

3.13.2 (Optional) Setting RSVP Authentication Lifetime

The RSVP authentication lifetime is set to prevent RSVP authentication from being prolonged
when CR-LSP flapping causes frequent re-establishment of RSVP neighbor relationships and
repeatedly performed handshake.
Context
RSVP neighbors retain an RSVP neighbor relationship within a specified RSVP
authentication lifetime even if there are no CR-LSPs between the RSVP neighbors.
Configuring the RSVP authentication lifetime does not affect existing CR-LSPs.
Procedure
l Configuring RSVP authentication lifetime in the interface view
a. Run system-view
c. Run mpls rsvp-te authentication lifetime lifetime
The RSVP authentication lifetime is set.
d. Run commit
l Configuring RSVP authentication lifetime in the MPLS RSVP-TE peer view
a. Run system-view
b. Run mpls
c. Run mpls rsvp-te peer ip-address
The MPLS RSVP-TE peer view is displayed.
If ip-address is an interface IP address of the neighbor, not the neighbor LSR ID,
key authentication will only take effect on that neighbor interface. Key
authentication then provides high security and has the highest priority.
If ip-address is a neighbor LSR ID, key authentication will take effect on all
interfaces on the neighbor. Authentication configured using this method has a lower
priority than that configured based on the neighbor's interface IP address but has a
higher priority than that configured in the interface view.
d. Run mpls rsvp-te authentication lifetime lifetime
The RSVP authentication lifetime is set.
e. Run commit
----End

3.13.3 (Optional) Configuring the Handshake Function

The handshake function helps RSVP key authentication prevent replay attacks.
Context
If the handshake function is configured between neighbors and the lifetime is configured, the
lifetime must be greater than the interval at which RSVP update messages are sent. If the
lifetime is smaller than the interval at which RSVP update messages are sent, authentication
relationships may be deleted because no RSVP update message is received within the
lifetime. As a result, the handshake mechanism is used again when a new update message is
received. An RSVP-TE tunnel may be deleted or fail to be established.
Procedure
l Configuring the handshake function in the interface view
a. Run system-view
c. Run mpls rsvp-te authentication handshake
The handshake function is enabled.
NOTE
The task of Configuring an RSVP Authentication Mode must be complete before the
RSVP 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 identifier carried in the Response messages. If
identifier in the Response messages is the same as the local one, the device
determines to establish an RSVP authentication relationship with its neighbor.
d. Run commit
l Configuring the handshake function in the MPLS RSVP-TE peer view
a. Run system-view
b. Run mpls
n If ip-address is set to an interface IP address of a neighbor, not the neighbor
LSR ID, the handshake function will only take effect on that neighbor
interface.

n If ip-address is set to a neighbor LSR ID, the handshake function will take
effect on all interfaces of the neighbor.
d. Run mpls rsvp-te authentication handshake
NOTE
RSVP handshake function is configured. The handshake can only take effect after it is
configured on both ends of an RSVP authentication relationship.
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 identifier carried in the Response messages. If
identifier in the Response messages is the same as the local one, the device
determines to establish an RSVP authentication relationship with its neighbor.
e. Run commit
----End
3.13.4 (Optional) Configuring the Message Window Function

The message window function prevents RSVP message mis-sequence. RSVP message mis-
sequence terminates RSVP authentication between neighboring nodes.
Context
The message window function prevents RSVP message mis-sequence.
If the window size is greater than 1, the local device stores several latest valid sequence
numbers.
Procedure
l Configuring the message window function in the interface view
a. Run system-view
c. Run mpls rsvp-te authentication handshake
NOTE
RSVP handshake function is configured.The handshake can only take effect after it is

d. Run mpls rsvp-te authentication window-size window-size

The message window function is configured. The value is the number of valid
sequence numbers of received RSVP messages that can be stored.
If RSVP is enabled on an Eth-Trunk or IP-Trunkinterface, only one neighbor
relationship is established on the trunk interface between RSVP neighbors. This
means any trunk member interface receives RSVP messages in a random order,
which results in message mis-sequence. An RSVP message window size is
configured to address this problem. If the sliding window is too small, received
RSVP messages with sequence numbers outside the window size are discarded,
which terminates an RSVP neighbor relationship.
e. Run commit
l Configuring the message window function in the MPLS RSVP-TE peer view
a. Run system-view
b. Run mpls
The MPLS RSVP-TE peer view is displayed.
n If ip-address is set to an interface IP address of a neighbor, not the neighbor
LSR ID, the message window size will only take effect on that interface of the
neighbor.
n If ip-address is set to a neighbor LSR ID, the message window size will take
effect on all interfaces of the neighbor.
d. Run mpls rsvp-te authentication handshake
NOTE
RSVP handshake function is configured. The handshake can only take effect after it is
e. Run mpls rsvp-te authentication window-size window-size
The message window function is configured. The value is the number of valid
sequence numbers of received RSVP messages that can be stored.
If RSVP is enabled on an Eth-Trunk or IP-Trunkinterface, only one neighbor
relationship is established on the trunk interface between RSVP neighbors. This
means any trunk member interface receives RSVP messages in a random order,
which results in message mis-sequence. An RSVP message window size is
configured to address this problem. If the sliding window is too small, received
RSVP messages with sequence numbers outside the window size are discarded,
which terminates an RSVP neighbor relationship.
f. Run commit
----End

3.13.5 Verifying the RSVP Authentication Configuration

After configuring RSVP authentication, you can view information about RSVP
authentication.
Prerequisites
RSVP authentication has been configured.
Procedure
l Run the display mpls rsvp-te command to check RSVP-TE configurations on a specific
interface.
l Run the display mpls rsvp-te peer [ interface interface-type interface-number | peer-
address ] command to check RSVP-TE neighbor information on an RSVP-TE-enabled
interface.
----End
Example
Run the following command to check the previous configurations.
Run the display mpls rsvp-te peer command to view information about RSVP-TE neighbors
on an RSVP-TE-enabled interface.
<HUAWEI> display mpls rsvp-te peer
Interface GigabitEthernet1/0/1
Neighbor Addr: 10.1.1.2
SrcInstance: 0x4F7FEC90 NbrSrcInstance: 0x0
Hello Type Sent: NONE Neighbor Hello Extension: DISABLE
SRefresh Enable: NO
Authentication: ENABLE
WindowsSize: 1
Last Valid Seq # rcvd: NULL
Remote Node id Neighbor

SRefresh Enable: NO
WindowsSize: 1
Config Neighbor
SRefresh Enable: NO
WindowsSize: 1

3.14 Adjusting Parameters for Establishing an MPLS TE

Tunnel
Multiple attributes are used to establish MPLS TE tunnels flexibly.
Usage Scenario
During the establishment of an MPLS TE tunnel, special configurations are required.
Before adjusting parameters for establishing an MPLS TE tunnel, configure an RSVP-TE
tunnel.
3.14.1 Configuring an MPLS TE Explicit Path

An explicit path is configured on the ingress of an MPLS TE tunnel to define the nodes
through which the MPLS TE tunnel passes and the nodes that are excluded from the MPLS
TE tunnel.
Context
An explicit path consists of a series of nodes. These nodes are arranged in sequence and form
a vector path. An IP address for an explicit path is an interface IP address on every node. The
loopback IP address of the egress node is used as the destination address of an explicit path.
Two adjacent nodes on an explicit path are connected in either of the following modes:
l Strict: A hop is directly connected to its next hop.

l Loose: Other nodes may exist between a hop and its next hop.
The strict and loose modes can be used simultaneously.
TE tunnels are classified into the following types:
l Intra-area tunnel: A TE tunnel is in a single OSPF or IS-IS area, but not in an

autonomous system (AS) running the Border Gateway Protocol (BGP).
l Inter-area tunnel: A TE tunnel traverses multiple OSPF or IS-IS areas, but not BGP ASs.
A strict explicit path is used to establish an inter-area TE tunnel, on which a next hop can only
be an area border router (ABR) or an autonomous system boundary router (ASBR).
Procedure

Step 2 Run explicit-path path-name

Step 3 Run next hop ip-address [ include [ [ strict | loose ] | [ incoming | outgoing ] ] * | exclude ]
The next-hop address is specified for the explicit path.
The include parameter indicates that the tunnel does pass through a specified node; the
exclude parameter indicates that the tunnel does not pass through a specified node.
Step 4 (Optional) Run add hop ip-address1 [ include [ [ strict | loose ] | [ incoming | outgoing ] ] * |
exclude ] { after | before } ip-address2
Step 5 (Optional) Run modify hop ip-address1 ip-address2 [ include [ [ strict | loose ] | [ incoming |
outgoing ] ] * | exclude ]
The address of a node on an explicit path is changed.
Step 6 (Optional) Run delete hop ip-address
A node is removed from an explicit path.
Step 7 (Optional) Run list hop [ ip-address ]
Information about nodes on an explicit path is displayed.
Step 8 Run commit
----End
3.14.2 Setting Priority Values for an MPLS TE Tunnel

The priority values are set on the ingress of an MPLS TE tunnel. Preemption is performed
based on the setup and holding priorities during the establishment of an MPLS TE tunnel.
Procedure
Step 3 Run mpls te priority setup-priority [ hold-priority ]
The priority values are set for the MPLS TE tunnel.
Both the setup and holding priority values range from 0 to 7. The smaller the value, the higher
the priority.
NOTE
The setup priority value must be greater than or equal to the holding priority value. This means the setup
priority is lower than or equal to the holding priority.

Step 4 Run commit
----End
3.14.3 Setting the Hop Limit for a CR-LSP

The hop limit set on an ingress is the maximum number of hops on a path along which a CR-
LSP is to be established. The hop limit is a constraint used during path selection.
Procedure
Step 3 Run mpls te hop-limit hop-limit-value [ best-effort | secondary ]
The hop limit of a CR-LSP is set.
Step 4 Run commit
----End
3.14.4 Associating CR-LSP Establishment with the Overload

Setting
CR-LSP establishment can be associated with the overload setting. This association ensures
that CR-LSPs are established over paths excluding overloaded nodes.
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.
NOTE
Before the association is configured, the mpls te cspf command must be run to enable CSPF and 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.
Step 4 Run commit

----End
3.14.5 Configuring Route and Label Record

An ingress can be configured to allow routes and labels to be recorded along a path over
which an RSVP-TE CR-LSP will be established.
Procedure
Step 3 Run mpls te record-route [ label ]
Routes and labels are able to be recorded during the establishment of a CR-LSP.
Step 4 Run commit
----End

3.14.6 Setting Switching and Deletion Delays

The switching and deletion delays are set to ensure that a CR-LSP is torn down only after a
new CR-LSP has been established, which prevents traffic interruption.
Context
MPLS TE uses a make-before-break mechanism. If attributes of an MPLS TE tunnel, such as
bandwidth or path change, a new CR-LSP with new attributes is established. Such a CR-LSP
is called a Modified CR-LSP. The new CR-LSP must be established before the original CR-
LSP, also called the primary CR-LSP, is torn down. This prevents data loss and additional
bandwidth consumption during traffic switching.
If a forwarding entry associated with the new CR-LSP does not take effect after the original
CR-LSP has been torn down, a temporary traffic interruption occurs.
The switching and deletion delays can be set on the ingress of the CR-LSP to prevent the
preceding problem.
Procedure
Step 2 Run mpls
Step 3 Run mpls te switch-delay switch-time delete-delay delay-time
The switching time and deletion delay time are set.
Step 4 Run commit
----End
3.14.7 Verifying the Configuration of Establishment of MPLS TE

Tunnel
After adjusting the establishment of the MPLS TE tunnel, you can view information about the
tunnel interface.
Prerequisites
The establishment of the MPLS TE tunnel has been adjusted.
Procedure
l Run the display mpls te tunnel-interface command to check information about a tunnel
interface on the ingress of a tunnel.
----End

Example
Run the following command to check the previous configurations.
Run the display mpls te tunnel-interface command to view information about the tunnel
interface.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0


FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
3.15 Importing Traffic to an MPLS TE Tunnel

Before importing traffic to an MPLS TE tunnel, familiarize yourself with the usage scenario,
complete the pre-configuration tasks for the configuration.
Usage Scenario
An MPLS TE tunnel does not automatically import traffic. To enable traffic to travel along an
MPLS TE tunnel, use one of the methods listed in Table 3-8 to import the traffic to the MPLS
TE tunnel.
Table 3-8 Methods to import traffic to an MPLS TE tunnel

Methods Principles Usage Scenario Related
to Configuration Links
Import
Traffic
to an
MPLS
TE
Tunnel
Use static This is the simplest Scenario where public- Configuring IPv4 Static
routes method for importing network routes are used Routes
the traffic to an MPLS to import traffic to a TE
TE tunnel. You only or LDP over TE tunnel
need to configure a
static route with a TE
tunnel interface as the
outbound interface.


Import
Traffic
to an
MPLS
TE
Tunnel
Use the A TE tunnel is used as a Configuring the IGP

auto route logical link for IGP Shortcut
mechanis route calculation. A Configuring
m tunnel interface is used Forwarding
as an outbound interface Adjacency
of a route. The auto
route mechanism can be
implemented in either
of the following modes:
l 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 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.


Import
Traffic
to an
MPLS
TE
Tunnel
Policy- The policy-based -

Based routing (PBR) allows a
Routing device to select routes
based on user-defined
policies.
TE PBR, the same as IP
unicast PBR, is
implemented by
defining a set of
matching rules and
behaviors. The rules and
behaviors are defined
using the apply clause
with a TE tunnel
interface used as an
outbound interface. If
packets do not match
PBR rules, they are
properly forwarded
using IP; if they match
PBR rules, they are
forwarded over specific
tunnels.


Import
Traffic
to an
MPLS
TE
Tunnel
Tunnel By default, VPN traffic VPN scenario VPN Tunnel

Policy is forwarded through Management
LDP LSPs tunnels. If Configuration
the default LDP LSPs
cannot meet VPN traffic
requirement, a tunnel
policy is used to direct
VPN traffic to a TE
tunnel.
l Select-seq mode:
This policy changes
the type of tunnel
selected for VPN
traffic. A TE tunnel
is selected as a
public tunnel for
VPN traffic based on
the prioritized tunnel
types.
l Tunnel binding
mode: This policy
defines a specific
destination IP
address, and this
address is bound to a
TE tunnel.
NOTE
The preceding methods to import traffic to MPLS TE tunnels apply only to P2P tunnels.
Before you import traffic to an MPLS TE tunnel, configure an RSVP-TE tunnel.

3.15.1 Configuring the IGP Shortcut

An IGP shortcut is configured on the ingress of a CR-LSP. The IGP shortcut prevents a route
of a CR-LSP from being advertised to neighbors or used by the neighbors.
Context
NOTE
IGP shortcut and forwarding adjacency cannot be configured simultaneously.
Procedure
Step 3 Run mpls te igp shortcut [ isis | ospf ] or mpls te igp shortcut isis hold-time interval
The IGP shortcut is configured.
hold-time interval specifies the period after which IS-IS responds to the Down status of the
TE tunnel.
If a TE tunnel goes Down and this parameter is not specified, IS-IS recalculates routes. If this
parameter is specified, IS-IS responds to the Down status of the TE tunnel after only the
specified interval elapses. It either recalculates routes or not depending on the TE tunnel
status:
l If the TE tunnel goes Up, IS-IS does not recalculate routes.
l If the TE tunnel goes Down, IS-IS still recalculates routes.
Step 4 Run mpls te igp metric { absolute | relative } value
The IGP metric of the TE tunnel is configured.
Either of the following parameters is set when configuring the metric value used by a TE
tunnel during IGP shortcut path calculation:
l If absolute is configured, the TE tunnel metric value is equal to the configured metric
value.
l If relative is configured, the TE tunnel metric value is equal to the sum of the IGP route
metric value and relative TE tunnel metric value.
Step 5 For IS-IS, run isis enable [ process-id ]
IS-IS is enabled on the tunnel interface.
Step 6 For OSPF, run the following commands in sequence.
l Run quit
l Run ospf [ process-id ]

l Run enable traffic-adjustment

Traffic adjustment is enabled.
Step 7 Run commit
----End
Follow-up Procedure
If a network fault occurs, IGP convergence is triggered. In this case, a transient forwarding
status inconsistency may occur among nodes because of their different convergence rates,
which poses the risk of microloops. To prevent microloops, perform the following steps:
NOTE
Before you enable the OSPF TE tunnel anti-microloop function, configure CR-LSP backup parameters.
l For IS-IS, run the following commands in sequence.
a. Run system-view
An IS-IS process is created, and the IS-IS process view is displayed.
c. Run avoid-microloop te-tunnel
The IS-IS TE tunnel anti-microloop function is enabled.
d. (Optional) Run avoid-microloop te-tunnel rib-update-delay rib-update-delay
The delay in delivering the IS-IS routes whose outbound interface is a TE tunnel
interface is set.
e. Run commit
l For OSPF, run the following commands in sequence.
a. Run system-view
c. Run avoid-microloop te-tunnel
The OSPF TE tunnel anti-microloop function is enabled.
d. (Optional) Run avoid-microloop te-tunnel rib-update-delay rib-update-delay
The delay in delivering the OSPF routes whose outbound interface is a TE tunnel
interface is set.
e. Run commit
3.15.2 Configuring Forwarding Adjacency

The forwarding adjacency is configured on the ingress of a CR-LSP. The forwarding
adjacency allows a route of a CR-LSP to be advertised to neighbors so that these neighbors
can use this CR-LSP to transmit traffic.

Context
A routing protocol performs bidirectional detection on a link. The forwarding adjacency needs
to be enabled on both ends of a tunnel. The forwarding adjacency allows a node to advertise a
CR-LSP route to other nodes. Another tunnel for transferring data packets in the reverse
direction must be configured.
Procedure
The view of an MPLS TE tunnel interface is displayed.
Step 3 Run mpls te igp advertise [ hold-time interval | include-ipv6-isis ] *
The forwarding adjacency is configured.
If IPv6 IS-IS is used, the include-ipv6-isis parameter must be configured.
Step 4 Run mpls te igp metric { absolute | relative } value
The IGP metric value of the MPLS TE tunnel is configured.
NOTE
A proper IGP metric value helps correctly advertise and use a CR-LSP route. The metric value of a CR-
LSP must be less than the metric value of an unwanted IGP route.
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.
Step 5 You can select either of the following modes to enable the forwarding adjacency.
l For IS-IS, run isis enable [ process-id ]
IS-IS is enabled on the tunnel interface.
l For OSPF, run the following commands in sequence.
a. Run the quit command to return to the system view.
b. Run the ospf [ process-id ] command to enter the OSPF view.
c. Run the enable traffic-adjustment advertise command to enable the forwarding
adjacency.
Step 6 Run commit
----End
3.15.3 (Optional) Configuring CBTS

Service class can be set for packets that MPLS TE tunnels allow to pass through.

Context
When services are iterated to multiple TE tunnels, the mpls te service-class command is run
on the TE tunnel interface to set a service class so that a TE tunnel transmits services of a
specified service class.
DS-TE tunnels can be prioritized to receive traffic. A priority or multiple priorities can be
assigned to a tunnel to which services are iterated. Table 3-9 describes the default mapping
between DS-TE tunnel's CTs and flow queues.
Table 3-9 Default mapping between DS-TE tunnel's CTs and flow queues
CT Flow Queue
CT0 be
CT1 af1
CT2 af2
CT3 af3
CT4 af4
CT5 ef
CT6 cs6
CT7 cs7
If services are iterated to multiple TE tunnels for load balancing, tunnel selection rules are the
same as those in CBTS:
1. If the priority of service traffic matches a configured priority of a tunnel, the matching
tunnel carries the service traffic.
2. If the priority of service traffic does not match a configured priority of a tunnel, the
following rules apply:
a. If one of load-balancing tunnels is assigned the priority of "default", services that
fail match any tunnel priorities pass through the default tunnel.
b. If none of load-balancing tunnels is assigned the priority of "default" and a tunnel
has no priority, services that fail match any tunnel priorities pass through the tunnel
without a priority specified.
c. If none of load-balancing tunnels is assigned the priority of "default" and all tunnels
have priorities, services that fail match any tunnel priorities pass through the tunnel
with the lowest priority.
Procedure
The MPLS TE tunnel interface view is displayed.

Step 3 Run mpls te service-class { service-class & <1-8> | default }

A service class is set for packets that an MPLS TE tunnel allows to pass through.
NOTE
l This command is used only on the ingress of an MPLS TE tunnel.

l If the mpls te service-class command is run repeatedly on a tunnel interface, the latest
configuration overrides the previous one.
Step 4 Run commit

----End
3.16 Configuring the Limit Rate of MPLS TE Traffic

This section describes how to configure the limit rate of MPLS TE traffic to limit TE tunnel
traffic within the bandwidth range that is actually configured.
Usage Scenario
For a physical link of a TE tunnel, besides traffic on the TE tunnel, the physical link may bear
MPLS traffic of other TE tunnels, MPLS traffic of other non-CR-LSPs, or even IP traffic
simultaneously. To limit the TE tunnel traffic within a bandwidth range that is actually
configured, set a limit rate for TE tunnel traffic.
After the configuration of the limit rate, TE traffic is limited to a bandwidth range that is
actually configured. TE traffic with the bandwidth higher than the set bandwidth is dropped.
NOTE
Before you configure the limit rate of MPLS TE traffic, run the mpls te bandwidth command on a
tunnel interface. If this command is not run, the limit rate of MPLS TE traffic is unavailable.
Context
Before configuring the limit rate of MPLS TE traffic, configure a static CR-LSP or an
RSVP-TE tunnel.
Procedure
The tunnel interface view is displayed.
Step 3 Run mpls te bandwidth
The bandwidth constraint of the MPLS TE tunnel is configured.
Step 4 Run mpls te lsp-tp outbound
The TE traffic policing is configured.

Step 5 Run commit
----End

l Run the display current-configuration interface Tunnel tunnel-number command. The
command output shows that the rate limit function has been enabled.
<HUAWEI> display current-configuration interface Tunnel 1
#
interface Tunnel1
tunnel-protocol mpls te
mpls te lsp-tp outbound
#
return
3.17 Configuring Bandwidth Information Flooding for

MPLS TE
If the link bandwidth changes slightly, the threshold for flooding bandwidth information is set
on the ingress or a transit node of a CR-LSP, which reduces flooding attempts and saves
network resources.
Usage Scenario
To synchronize data between TEDBs in an IGP area, OSPF TE or IS-IS TE is configured to
update TEDB information and flood bandwidth information if the remaining bandwidth
changes on an MPLS interface.
NE40E supports the following methods of controlling bandwidth information flooding:

l Configure flooding commands to enable immediate bandwidth information flooding on a
device.
l Configure a flooding interval to enable periodic bandwidth information flooding on a
device.
l Configure a flooding threshold to prevent frequent flooding.
– When the percentage of the bandwidth reserved for the MPLS TE tunnel on a link
to the remaining link bandwidth in the TEDB is greater than or equal to the
configured threshold (flooding threshold), OSPF TE and IS-IS TE flood link
bandwidth information to all devices in this area and update TEDB information.
– When the percentage of the bandwidth released by the MPLS TE tunnel to the
remaining link bandwidth in the TEDB is greater than or equal to the configured
threshold, OSPF TE and IS-IS TE flood link bandwidth information to all devices
in this area and update TEDB information.
Before adjusting the flooding threshold, configure an RSVP-TE tunnel.

Procedure
l Configure forcible bandwidth information flooding.
a. Run system-view

b. Run mpls

c. Run mpls te manual-flooding
A device on the MPLS TE tunnel is configured to immediately flood the bandwidth

change to the network.
d. Run commit

l Configure periodic bandwidth information flooding.
a. Run system-view

b. Run mpls

c. Run mpls te periodic-flooding [ interval time-value ]
Periodic bandwidth information flooding is enabled on a device.

d. Run commit

l Configure a flooding threshold.
a. Run system-view

c. Run mpls te bandwidth change thresholds { down | up } percent
The flooding threshold is configured.
The flooding threshold is set only on a physical interface.

d. Run commit
----End
3.18 Configuring Tunnel Re-optimization

Tunnel re-optimization is configured to allow a device to dynamically adjust paths for tunnels.

Usage Scenario
Topology and link attributes of an IP/MPLS network are changeable. As a result, a path over
which an MPLS TE tunnel has been established may not be optimal. Tunnel re-optimization
can be configured to allow the MPLS TE tunnel to be reestablished over an optimal path.
Re-optimization is implemented in either of the following modes:
l Periodic re-optimization: The system attempts to reestablish tunnels over better paths (if
there are) at a specified interval configured using the mpls te auto reoptimization
command. This implementation prevents manual intervention and reduces configuration
workload.
l Manual re-optimization: A user configures the system to attempt to reestablish TE
tunnels over better paths if there are.
NOTE
Tunnel re-optimization does not take effect on a tunnel if this tunnel has been established over an
explicit path.
Tunnel re-optimization cannot be used on tunnels for which a system selects paths in most-fill tie-
breaking mode.
Before configuring tunnel re-optimization, configure an RSVP-TE tunnel.
Procedure
l Configure periodic re-optimization.
a. Run system-view
b. Run interface tunnel interface-number
The tunnel interface view of the tunnel to be established is displayed.
c. Run mpls te reoptimization [ frequency interval ]
Periodic re-optimization is enabled.
d. (Optional) Run mpls te inter-area reoptimization
Inter-IGP-area RSVP-TE P2P tunnel re-optimization is enabled. In an inter-IGP-
area scenario, if re-optimization is triggered on the ingress, a better path in the area
where the ingress resides can only be detected, but a better path exists in the
downstream area cannot be detected. If the latter exists only, re-optimization cannot
be performed to reestablish the RSVP-TE P2P LSP over the better path. To enable
this function, run the mpls te inter-area reoptimization command to enable inter-
IGP-area RSVP-TE P2P tunnel re-optimization. After this command is run, the
RSVP-TE P2P LSP is reestablished over the better path in the downstream area.
e. (Optional) Run quit
f. (Optional) Run mpls
g. (Optional) Run mpls te reoptimization link-up disable

Link change-triggered RSVP-TE tunnel re-optimization is disabled.

If route flapping occurs on a network, tunnel re-optimization is repeatedly triggered,
which wastes network resources. To prevent the problem, run the mpls te
reoptimization link-up disable command to disable link change-triggered RSVP-
TE tunnel re-optimization. After this command is run, tunnels are not optimized.
NOTE
This command prevents tunnel re-optimization triggered by link changes. If the frequency
interval parameter is set in the mpls te reoptimization command run in the tunnel interface
view to enable tunnel re-optimization for a specific tunnel, the tunnel can be optimized
properly.
The mpls te reoptimization link-up disable command disables all tunnel re-optimization
functions.
h. Run commit
l Configure manual re-optimization. Run the following command in the user view mpls te
reoptimization [ auto-tunnel name tunnel-interface | tunnel tunnel-number ]
Manual re-optimization is configured.
Manual re-optimization can be enabled on a specific or all tunnels on a node.
----End

After completing the configuration, run the display mpls te tunnel-interface command on
the ingress of a tunnel to view the following information:
l Whether periodic re-optimization is enabled
l Interval between periodic re-optimization processes
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -

Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
3.19 Configuring Automatic Tunnel Bandwidth

Adjustment
This section describes how to configure the automatic adjustment of the tunnel bandwidth.
Usage Scenario
Automatic bandwidth adjustment is enabled to adjust the bandwidth of the tunnel
automatically.
The system periodically collects traffic rates of outbound interfaces on the tunnel and
calculates the average bandwidth of the tunnel within a specified period of time. The

establishment of an LSP is requested based on the bandwidth constraint of the sampled

maximum value of average bandwidth. After the LSP is established, the old LSP is torn down
using the make-before-break feature, and the traffic is switched to the new LSP.
The sampling interval is configured in the MPLS view and takes effect on all MPLS TE
tunnels. The rate of the outbound interface on an MPLS TE tunnel is recorded at each
sampling interval. The actual average bandwidth assigned to the MPLS TE tunnel in a
sampling interval can be obtained.
After automatic bandwidth adjustment is enabled, the mpls te timer auto-bandwidth
command configures periodic sampling obtains the average bandwidth of the MPLS TE
tunnel during a sampling interval. The system recalculates an average bandwidth based on
sampling during a sampling interval and uses the bandwidth to establish an MPLS TE tunnel.
Traffic switches to the new MPLS TE tunnel, and the original MPLS TE tunnel is torn down.
If the MPLS TE tunnel fails to be established, traffic transmission continues along the original
MPLS TE tunnel, and the bandwidth is adjusted after the next sampling interval expires.
Before configuring the bandwidth automatic adjustment, configure an RSVP-TE tunnel.
Procedure
Step 2 Run mpls
Step 3 Run mpls te timer auto-bandwidth [ interval ]
The sampling interval is specified.
Step 4 Run quit
The tunnel interface view of the MPLS TE tunnel is displayed.
Step 6 Run statistic enable
MPLS TE tunnel statistics can be collected.
Step 7 To configure automatic bandwidth adjustment, run one of the following commands.
l Run mpls te auto-bandwidth adjustment { [ threshold percent [ absolute-bw
absolute-bw ] ] | frequency interval | [ max-bw max-bandwidth | min-bw min-
bandwidth ] * | [ overflow-limit overflow-limit-value ] | [ underflow-limit underflow-
limit-value ] * } *
The automatic bandwidth adjustment is enabled. The frequency and allowable bandwidth
range for adjustment are configured.
The following policies can be configured to control automatic bandwidth adjustment:
– After the mpls te auto-bandwidth command is run, a device must accumulatively
sample bandwidth values for at least three times within a configured interval time.

If the device samples bandwidth values for less than three times within the specified
interval, automatic bandwidth adjustment is not performed. The existing sampling
times are counted in the next bandwidth adjustment interval.
– You can use the threshold percent [ absolute-bw absolute-bw ] parameter to
determine whether or not to adjust bandwidth.
The system compares the average bandwidth within a sampling period with the
actual bandwidth, and the bandwidth will be automatically adjusted if the ratio of
bandwidth change to the actual bandwidth is greater than the threshold value.If the
absolute threshold is set, bandwidth can be automatically adjusted only after the
bandwidth change also exceeds the absolute threshold.
Therefore, if the network traffic changes frequently but frequent bandwidth
adjustment is not needed, you can set a greater threshold value.
– Automatic bandwidth adjustment is performed if conditions are met in either of the
following situations depending on whether overflow-limit overflow-limit-value and
underflow-limit underflow-limit-value parameters are configured:
n The two arameters are not configured, and the configured interval time
expires. The average bandwidth exceeds the upper bandwidth adjustment
threshold or falls below the lower bandwidth adjustment threshold.
n The two parameters are configured. The average bandwidth exceeds the upper
bandwidth adjustment threshold or falls below the lower bandwidth adjustment
threshold for a number of timers more than overflow-limit overflow-limit-
value or less than underflow-limit underflow-limit-value.
The default overflow-limit overflow-limit-value and underflow-limit underflow-
limit-value parameters do not take effect. By default, after the configured interval
time expired, a device automatically adjusts bandwidth values if the average
bandwidth exceeds the upper bandwidth adjustment threshold or falls below the
lower bandwidth adjustment threshold.
l Run mpls te auto-bandwidth collect-bw { [ frequency interval ] | [ max-bw max-
bandwidth | min-bw min-bandwidth ] * } *
The frequency and allowable bandwidth range for collection are configured.
Step 8 Run commit
The current tunnel configuration is committed.
----End

After completing the configuration, run the display mpls te tunnel-interface command on
the ingress of the tunnel to view the following tunnel configuration information.
l Automatically adjusted bandwidth (Auto BW)
l Automatically adjusted frequency (Auto BW Freq)
l Minimum bandwidth that can be adjusted (Min BW)
l Maximum bandwidth that can be adjusted (Max BW)
l Current bandwidth that is collected (Current Collected BW)

Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled

IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
3.20 Locking the Tunnel Configuration

Tunnel configurations can be locked by the controller when the configurations are sent to a
NE40E.
Usage Scenario
In service delivery, a controller delivers tunnel configurations to a NE40E. The NE40E uses
the obtained configurations to create a tunnel or modify an existing tunnel. To prevent users
from modifying such tunnel configurations, the controller delivers the mpls te lock command
to lock the configurations, in addition to configurations to the NE40E. Before you modify the
configuration of a tunnel, run the undo mpls te lock command to unlock the tunnel
configuration on the tunnel interface.
Before locking the tunnel configuration, complete the following tasks:
l Configure the controller to deliver tunnel configurations to a NE40E.

l Assign a user management rights.
Procedure
The tunnel interface view of an MPLS TE tunnel is displayed.
Step 3 Run mpls te lock
The configuration of the MPLS TE tunnel is locked.
Step 4 Run commit
----End

After locking the tunnel configurations, verify that no command can be run on the tunnel
interface to modify configurations and commands can be run only after the undo mpls te lock
command is run to unlock the configurations.

3.21 Configuring DS-TE

This feature combines traditional TE tunnels with the DiffServ model to provide QoS
guarantee based on service types.
Usage Scenario
A static CR-LSP is easy to configure. Labels are manually allocated, and no signaling
protocol is used to exchange control packets. The setup of a static CR-LSP consumes only a
few resources, and you do not need to configure an IGP TE extension or CSPF for the static
CR-LSP. However, static CR-LSP application is quite limited. A static CR-LSP cannot
dynamically adapt to network changes and is limited in applications.
MPLS TE tunnels apply to one of the following VPN scenarios:

l A single TE tunnel transmits various types of services in a non-VPN scenario.
l A single TE tunnel transmits various types of services in a VPN instance.
l A single TE tunnel transmits various types of services in multiple VPN instances.
l A single TE tunnel transmits various types of VPN and non-VPN services.
Traditional MPLS TE tunnels (non-standard DS-TE tunnels) cannot transmit services based
on service types in compliance with the quality of service (QoS). For example, when a TE
tunnel carries both voice and video flows, video flows may have more duplicate frames than
voice flows. Therefore, video flows require higher drop precedence than the voice flows. The
same drop precedence, however, is used for voice and video flows on MPLS TE tunnels.
To prevent services over a tunnel from interfere with each other, establish a tunnel for each
type of service in a VPN instance or for each type of non-VPN service. This solution wastes
resources because a large number of tunnels are established when many VPN instances carry
various services.
In the preceding MPLS TE tunnel scenarios, the DS-TE tunnel solution is optimal. An edge
node in a DS-TE domain classifies services and adds service type information in the EXP
field in packets. A transit node merely checks the EXP field to select a proper PHB to forward
packets.
A DS-TE tunnel classifies services and reserves resources for each type of services, which
improves network resource use efficiency. A DS-TE tunnel carries a maximum of eight types
of services.
NOTE
l The IETF DS-TE tunnel configuration requires the ingress and egress hardware to support HQoS.
The non-IETF DS-TE tunnel has no such a restriction.
l If the same type of service in multiple VPN instances is carried using the same CT of a DS-TE
tunnel, the bandwidth of each type of service in each VPN instance can be set on an access CE to
prevent services of the same type but different VPN instances from competing for resources.
l To prevent non-VPN services and VPN services from completing resources, you can configure DS-
TE to carry VPN services only or configure the bandwidth for non-VPN services in DS-TE.
Before configuring DS-TE, complete the following tasks:

l Configure unicast static routes or an IGP to ensure the readability between LSRs at the
network layer.
l Set an LSR ID on each LSR.
l Enable behavior aggregate (BA) traffic classification on each LSR interface along an
LSP.
3.21.1 Configuring a DS-TE Mode

You can configure an MPLS TE tunnel to work a DS-TE mode, either IETF mode or non-
IETF mode.
Context
Perform the following steps on each LSR in a DS-TE domain:
NOTE
If bandwidth constraints are configured for a tunnel, the IETF and non-IETF modes cannot be switched
to each other.
Procedure
Step 2 Run mpls
Step 3 Run mpls te ds-te mode { ietf | non-ietf }
A DS-TE mode is specified.
Step 4 Run commit
----End
Follow-up Procedure
The IETF mode and non-IETF mode can be switched between each other on the NE40E.
Table 3-10 describes switching between DS-TE modes. The arrow symbol (—>) indicates
"switched to."

Table 3-10 Switching between DS-TE modes
Item Non-IETF—>IETF IETF—>Non-IETF
Changes N/A RDM—>N/A

in MAM—>N/A
bandwidth
constraint
models
Bandwidt BC0 bandwidth values remain. BC0 bandwidth values remain.

h change
TE-class If the TE-class mapping table is No TE-class mapping table is used.

mapping not configured, the default TE- l A TE-class mapping table is not
table Class mapping table is used. deleted once it is configured.
Otherwise, the configured one is
used. l If no TE-Class mapping table is
configured, the default TE-Class
NOTE
mapping table is deleted.
For information about the default
TE-class mapping table, see Table
3-11.
3.21.2 Configuring a DS-TE Bandwidth Constraints Model

If CT bandwidth preemption is allowed, the Russian dolls model (RDM) is recommended to
efficiently use bandwidth resources. If CT bandwidth preemption is not allowed, the MAM is
recommended.
Context
Procedure
Step 2 Run mpls
Step 3 Run mpls te ds-te bcm { mam | rdm }
A DS-TE bandwidth constraints model is configured.
Step 4 Run commit
----End

3.21.3 (Optional) Configuring a TE-Class Mapping Table

Configuring the same TE-class mapping table on the whole DS-TE domain is recommended.
Otherwise, LSPs may be incorrectly established.
Context
Skip this section if the non-IETF DS-TE mode is used.
In IETF DS-TE mode, plan a TE-class mapping table. Configuring the same TE-class
mapping table on the whole DS-TE domain is recommended. Otherwise, LSPs may be
incorrectly established.
Procedure
Step 2 Run te-class-mapping
A TE-class mapping table is created, and the TE-class mapping view is displayed.
Step 3 Perform one or more commands to configure TE-classes:
l To configure TE-class 0, run te-class0 class-type { ct0 | ct1 | ct2 | ct3 | ct4 | ct5 | ct6 |
ct7 } priority priority [ description description-info ]
Note the following information when you configure a TE-class mapping table:
l The TE-class mapping table is unique on each device.
l The TE-class mapping table takes effect globally. It takes effect on all DS-TE tunnels
passing through the local LSR.
l A TE-class refers to a combination of a CT and a priority, in the format of <CT,
priority>. The priority is the preemption priority of a CR-LSP, not the EXP value in the
MPLS header. The priority value is an integer ranging from 0 to 7. The smaller the value,
the higher the priority is. A CR-LSP can be established only when both <CT, setup-

priority> and <CT, holding-priority> exist in a TE-class mapping table. For example, the
TE-class mapping table of a node contains only TE-Class [0] = <CT0, 6> and TE-Class
[1] = <CT0, 7>, only can the following three types of CR-LSPs be successfully set up:
– Class-Type = CT0, setup-priority = 6, holding-priority = 6
NOTE
The combination of setup-priority = 6 and hold-priority = 7 does not exist because the setup priority
cannot be higher than the holding priority on a CR-LSP.
l In a MAN model, a higher-class CT preempts bandwidth of the same CT, not bandwidth
of different CTs.
l In the RDM module, CT bandwidth preemption is limited by preemption priorities and
matching BCs. Assumed that preemption priorities are set to m and n and CT values are
set to i and j. If 0 <= m < n <= 7 and 0 <= i < j <= 7, the following situations occur:
– CTi with priority m can preempt the bandwidth of CTi with priority n or of CTj
with priority n.
– Total CTi bandwidth <= BCi bandwidth
In IETF DS-TE mode, if no TE-class mapping table is configured, a default TE-class mapping
table is used. Table 3-11 describes the default TE-class mapping table.
Table 3-11 Default TE-class mapping table
TE-Class CT Priority
TE-Class[0] 0 0
TE-Class[1] 1 0
TE-Class[2] 2 0
TE-Class[3] 3 0
TE-Class[4] 0 7
TE-Class[5] 1 7
TE-Class[6] 2 7
TE-Class[7] 3 7
NOTE
After the TE-class mapping is configured, to change TE-class descriptions, run the { te-class0 | te-class1
| te-class2 | te-class3 | te-class4 | te-class5 | te-class6 | te-class7 } description description-info
command.
Step 4 Run commit
----End

3.21.4 Configuring Link Bandwidth

You can configure link bandwidth to limit the bandwidth for a DS-TE tunnel.
Context
Perform the following steps on each outbound interface on a DS-TE LSP:
Procedure
The view of the link outbound interface is displayed.
The maximum reservable link bandwidth is set.
Step 4 Run mpls te bandwidth { bc0 bc0-bw-value | bc1 bc1-bw-value | bc2 bc2-bw-value | bc3
bc3-bw-value | bc4 bc4-bw-value | bc5 bc5-bw-value | bc6 bc6-bw-value | bc7 bc7-bw-
value }*
The bandwidth values of bandwidth constraints (BCs) are set for a link.
Step 5 Run commit
----End
Follow-up Procedure
A distinct bandwidth constraints model determines a specific mapping between the maximum
reservable link bandwidth and BC bandwidth:
l In the RDM: max-reservable-bandwidth ≥ bc0-bw-value ≥ bc1-bw-value ≥ bc2-bw-value

≥ bc3-bw-value ≥ bc4-bw-value ≥ bc5-bw-value ≥ bc6-bw-value ≥ bc7-bw-value
l In the MAM: max-reservable-bandwidth ≥ bc0-bw-value + bc1-bw-value + bc2-bw-
value + bc3-bw-value + bc4-bw-value + bc5-bw-value + bc6-bw-value + bc7-bw-value
The Bandwidth Constraint (BC) bandwidth refers to the bandwidth constraints on a link,
whereas the CT bandwidth refers to the bandwidth constraints of various types of service
traffic on a DS-TE tunnel. The BCi bandwidth of a link must be greater than or equal to the
sum (0 <= i <= 7) of all CTi bandwidth values of DS-TE tunnels passing through the link. For
example, three LSPs with CT1 passing through a link has bandwidth values x, y, and z,
respectively. The link interface BC1 bandwidth must be greater than or equal to the sum of x,
y, and z.
3.21.5 Configuring a Tunnel Interfaces

Before creating a DS-TE tunnel, create a tunnel interface and configure tunnel attributes in the
view of the tunnel interface.

Context
Perform the following steps on the ingress of a TE tunnel to be established:
Procedure
The tunnel description is configured.
Step 4 (Optional) Run either of the following commands to assign an IP address to the tunnel
interface:
l To configure an IP address, run ip address ip-address { mask | mask-length } [ sub ]

The secondary IP address of the tunnel interface can be configured only after the primary
IP address is configured.
To forward traffic, the tunnel interface must have an IP address. An MPLS TE tunnel,
however, is unidirectional, and o peer address exists. Therefore, it is unnecessary to assign an
IP address to a tunnel interface. A tunnel interface usually borrows the loopback address,
which functions as the LSR ID of the local node.
MPLS TE is configured as a tunneling protocol.
The LSR ID of the egress is configured as the destination address of the tunnel.
By default, a GRE tunnel is used. As each type tunnel has specific a requirement for a
destination address, when the tunnel protocol is changed to MPLS TE, the destination address
configured using the destination command is automatically deleted. You need to reconfigure
it.
A tunnel ID is set.
Step 8 Run mpls te signal-protocol { cr-static | rsvp-te }
A signaling protocol is configured for a tunnel.
Step 9 (Optional) Run mpls te priority setup-priority [ hold-priority ]
The tunnel priorities are set.
A smaller value indicates a higher priority.

NOTE
The holding priority must be higher than or equal to the setup priority. If no holding priority is set, its
value is the same as that setup priority.If the bandwidth and priority type of combination is not TE-
Class-Mapping table, LSP can not be established.
Step 10 Run commit

Each time you change an MPLS TE parameter, run the commit command to commit the
configuration.
----End
3.21.6 Configuring an RSVP CR-LSP and Specifying Bandwidth

Values
When configuring an RSVP CR-LSP and specifying its bandwidth values, ensure that the sum
of CT bandwidth values does not exceed the sum of BC bandwidth values.
Procedure
l Configure IGP TE.
For detailed configurations, see Configuring IGP TE (IS-IS).
l Configure CSPF.
For configuration details, see Configuration CSPF.
l Configure bandwidth values for an MPLS TE tunnel.
Perform the following steps on the ingress of a tunnel:
a. Run system-view
c. Run mpls te bandwidth { ct0 bw-value | ct1 bw-value | ct2 bw-value | ct3 bw-
value }
Single-CT information is specified.
d. Run commit
For the same node, the sum of CTi bandwidth values must not exceed the BCi bandwidth
values (0 <= i <= 7). CTi can use bandwidth resources only of BCi.
NOTE
If the bandwidth required by the MPLS TE tunnel is higher than 28,630 kbit/s, the available
bandwidth assigned to the tunnel may not be precise, but the tunnel can be established
successfully.
l (Optional) Configure an explicit path.
To limit the path over which an MPLS TE tunnel is established, perform the following
steps on the ingress of the tunnel:

a. Create an explicit path. For detailed configuration, see (Optional) Configuring an

MPLS TE Explicit Path.
b. Run quit
c. Run interface tunnel interface-number
d. Run mpls te path explicit-path path-name
An explicit path is configured for the tunnel.
e. Run commit
----End
3.21.7 (Optional) Configuring CBTS

Service class can be set for packets that MPLS TE tunnels allow to pass through.
Context
When services are iterated to multiple TE tunnels, the mpls te service-class command is run
on the TE tunnel interface to set a service class so that a TE tunnel transmits services of a
specified service class.
DS-TE tunnels can be prioritized to receive traffic. A priority or multiple priorities can be
assigned to a tunnel to which services are iterated. Table 3-12 describes the default mapping
between DS-TE tunnel's CTs and flow queues.
Table 3-12 Default mapping between DS-TE tunnel's CTs and flow queues
CT Flow Queue
CT0 be
CT1 af1
CT2 af2
CT3 af3
CT4 af4
CT5 ef
CT6 cs6
CT7 cs7
If services are iterated to multiple TE tunnels for load balancing, tunnel selection rules are the
same as those in CBTS:
1. If the priority of service traffic matches a configured priority of a tunnel, the matching
tunnel carries the service traffic.

2. If the priority of service traffic does not match a configured priority of a tunnel, the
following rules apply:
a. If one of load-balancing tunnels is assigned the priority of "default", services that
fail match any tunnel priorities pass through the default tunnel.
b. If none of load-balancing tunnels is assigned the priority of "default" and a tunnel
has no priority, services that fail match any tunnel priorities pass through the tunnel
without a priority specified.
c. If none of load-balancing tunnels is assigned the priority of "default" and all tunnels
have priorities, services that fail match any tunnel priorities pass through the tunnel
with the lowest priority.
Procedure
Step 3 Run mpls te service-class { service-class & <1-8> | default }
A service class is set for packets that an MPLS TE tunnel allows to pass through.
NOTE
l This command is used only on the ingress of an MPLS TE tunnel.

l If the mpls te service-class command is run repeatedly on a tunnel interface, the latest
configuration overrides the previous one.
Step 4 Run commit

----End
3.21.8 Verifying the DS-TE Configuration

After configuring DS-TE, you can verify DS-TE information and CT information of a tunnel.
Prerequisites
All DS-TE functions have been configured.
Procedure
l Run the display mpls te ds-te { summary | te-class-mapping [ default | config |
verbose ] } command to check DS-TE information.
l Run the display mpls te te-class-tunnel { all | { ct0 | ct1 | ct2 | ct3 | ct4 | ct5 | ct6 | ct7 }
priority priority } command to check information about the TE tunnel associated with
TE-classes.
l Run the display interface tunnel interface-number command to check CT traffic
information on a specified tunnel interface.
----End

Example
If the configurations succeed, you can run the preceding commands to obtain the following
results:
l Run the display mpls te ds-te { summary | te-class-mapping [ default | config |
verbose ] } command on the ingress to view DS-TE information.
l Run the display mpls te te-class-tunnel command on the ingress to view information
about a TE tunnel associated with TE-classes.
3.22 Configuring MPLS TE Manual FRR

MPLS TE manual FRR is a local protection mechanism that protects traffic on a link or a
node on a CR-LSP.
Usage Scenario
FRR provides rapid local protection for MPLS TE networks requiring high reliability. If a
local failure occurs, FRR rapidly switches traffic to a bypass tunnel, minimizing the impact on
traffic.
A backbone network has a large capacity and its reliability requirements are high. If a link or
node failure occurs on the backbone network, a mechanism is required to provide automatic
protection and rapidly remove the fault. The Resource Reservation Protocol (RSVP) usually
establishes MPLS TE LSPs in Downstream on Demand (DoD) mode. If a failure occurs,
Constraint Shortest Path First (CSPF) can re-calculate a reachable path only after the ingress
is notified of the failure. The failure may trigger reestablishment of multiple LSPs and the
reestablishment fails if bandwidth is insufficient. Either the CSPF failure or bandwidth
insufficiency delays the recovery of the MPLS TE network.
Configuring TE FRR on MPLS TE-enabled interfaces allows traffic to automatically switch
to a protection link if a link or node on a primary tunnel fails. After the primary tunnel
recovers or is reestablished, traffic switches back to the primary tunnel. This process meets
the reliability requirements of the MPLS TE network.
NOTE
l FRR requires reserved bandwidth for a bypass tunnel that needs to be pre-established. If available
bandwidth is insufficient, FRR protects only important nodes or links along a tunnel.
l RSVP-TE tunnels using bandwidth reserved in Shared Explicit (SE) style support FRR, but static TE
tunnels do not.
Before configuring MPLS TE manual FRR, complete the following tasks:
l Establish a primary RSVP-TE tunnel.
l Enable MPLS TE and RSVP-TE in the MPLS and physical interface views on every
node along a bypass tunnel. (See Enabling MPLS TE and RSVP TE.)
l (Optional) Configure TE attributes for the links of bypass tunnel. (See (Optional)
Configuring TE Attributes.)
l Enable CSPF on a Point of Local Repair (PLR).
l (Optional) Configure an explicit path for the bypass tunnel.

Figure 3-9 MPLS TE manual FRR configuration
Enable TE fast reroute.
Configure bypass tunnels.
Modify the PSB and RSB timeout multiplier.
Mandatory
Optional
3.22.1 Enabling TE FRR

TE FRR must be enabled on the ingress of a primary tunnel before TE manual FRR is
configured.
Procedure
Step 2 Run interface tunneltunnel-number
The view of the primary MPLS TE tunnel interface is displayed.
Step 3 Run mpls te fast-reroute [ bandwidth ]
TE FRR is enabled.
NOTE
After TE FRR is enabled using the mpls te fast-reroute command, run the mpls te bypass-attributes
command to set bypass tunnel attributes.
Step 4 Run commit

----End
3.22.2 Configuring a Bypass Tunnel

A path and attributes must be configured for a bypass tunnel after TE manual FRR is enabled
on a PLR.

Context
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 at a
specific interval and binds the bypass tunnel to the primary tunnel if there is an optimal bypass
tunnel.
Procedure
The view of the bypass tunnel interface is displayed.
MPLS TE is configured.
The LSR ID of an MP is configured as the destination address of the bypass tunnel.
The bypass tunnel ID is configured.
Step 6 (Optional) Run mpls te path explicit-path path-name [ secondary ]
An explicit path is configured for the bypass tunnel.
NOTE
Physical links of a bypass tunnel cannot overlap protected physical links of the primary tunnel.
Step 7 (Optional) Run mpls te bandwidth ct0 bandwidth

Set the bandwidth for the bypass tunnel.
Step 8 Run mpls te bypass-tunnel
A bypass tunnel is configured.
Step 9 Run mpls te protected-interface interface-type interface-number
The interface on which the bypass tunnel protects traffic is specified.
Step 10 Run commit
----End

Follow-up Procedure
Routes and labels are automatically recorded after a bypass tunnel is configured.
A bypass tunnel is established over a configured explicit path on the PLR.
If a primary tunnel fails, traffic switches to a bypass tunnel. If the bypass tunnel also goes
Down, the protected traffic is interrupted, and FRR fails. Even though the bypass tunnel goes
Up, traffic cannot be forwarded. Traffic will be forwarded only after the primary tunnel has
been restored or re-established.
NOTE
l The mpls te fast-reroute command and the mpls te bypass-tunnel command cannot be configured
on the same tunnel interface.
l After FRR switches traffic from a primary tunnel to a bypass tunnel, the bypass tunnel must be kept
Up, and its path must remain unchanged when transmitting traffic. If the bypass tunnel goes Down,
the protected traffic is interrupted and FRR fails.
3.22.3 (Optional) Setting the FRR Switching Delay Time

After the FRR switching delay time is set, FRR entry delivery is delayed, preventing traffic
from being switched twice when both HSB and FRR are enabled.
Context
The FRR switching delay time can be set to delay FRR entry delivery. This allows traffic to
be switched to the HSB path, not the FRR path, preventing traffic from being switched twice.
Procedure
Step 2 Run mpls
Step 3 Run mpls te
Step 4 Run mpls te frr-switch-delay frr-switch-delay-value
The FRR switching delay time (in ms) is set.
Step 5 Run commit
----End
3.22.4 Verifying the MPLS TE Manual FRR Configuration

After configuring MPLS TE manual FRR, you can view detailed information about the
bypass tunnel.
Prerequisites
The MPLS TE manual FRR function has been configured.

Procedure
l Run the display mpls lsp command to check information about the primary tunnel.
l Run the display mpls te tunnel-interface command to check information about the
tunnel interface on the ingress of a primary or bypass tunnel.
l Run the display mpls te tunnel path command to check information about paths of a
primary or bypass tunnel.
----End
Example
Run the display mpls lsp command to view information about the primary tunnel.
<HUAWEI> display mpls lsp
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
4.4.4.4/32 NULL/11264 -/GE1/0/0
Run the display mpls te tunnel-interface command, and you can see that the tunnel is Up.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-


Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
Run the display mpls te tunnel path command to view path attributes of tunnels.
<HUAWEI> display mpls te tunnel path
Lsp ID : 1.1.1.1 :200:1
Hop Information
Hop 1 2.1.1.1 Local-Protection available | bandwidth | node
Hop 2 2.1.1.2 Label 106497
Hop 3 2.2.2.2
Hop 4 3.1.1.1 Local-Protection available | bandwidth
Hop 5 3.1.1.2 Label 3
Hop 6 3.3.3.3
Tunnel Interface Name : AutoTunnel67141670
Lsp ID : 1.1.1.1 :67141670 :2
Hop Information
Hop 1 10.1.1.2
Hop 2 10.1.1.1
Hop 3 3.3.3.3

Lsp ID : 2.2.2.2 :67141671 :209
Hop Information
Hop 1 2.2.2.2
Hop 2 2.1.1.2
Hop 3 2.1.1.1
Hop 4 1.1.1.1
Hop 5 10.1.1.2
Hop 6 10.1.1.1
Hop 7 3.3.3.3

3.23 Configuring MPLS TE Auto FRR

MPLS TE Auto FRR is a local protection mechanism that protects traffic on a link or a node
on a CR-LSP.
Usage Scenario
On a network that requires high reliability, FRR is configured to improve network reliability.
If the network topology is complex and a great number of links must be configured, the
configuration procedure is complex.
Auto FRR automatically establishes an eligible bypass tunnel, which simplifies
configurations.
MPLS TE Auto FRR, similar to MPLS TE manual FRR, can be performed in the RSVP GR
process. For details about MPLS TE manual FRR, see Configuring MPLS TE Manual
FRR.
NOTE
Only a primary CR-LSP supports MPLS TE Auto FRR.
In this example, a bypass tunnel with a higher priority is available on the NE40E. MPLS TE
Auto FRR automatically deletes a binding between a primary tunnel and a bypass tunnel with
a lower priority and binds the primary tunnel to another bypass tunnel with a higher priority.
A bypass tunnel has a higher priority than another based on the following conditions in
descending order:
l SRLG
In MPLS TE Auto FRR, if the shared risk link group (SRLG) attribute is configured, the
primary and bypass tunnels must be in different SRLGs. If they are in the same SRLG,
the bypass tunnel cannot be established.
l Bandwidth protection takes precedence over non-bandwidth protection.
l Node protection takes precedence over link protection.
l Manual protection takes precedence over auto protection.
Before configuring MPLS TE Auto FRR, complete the following tasks:
l Set up a primary RSVP-TE tunnel.
l Enable MPLS, MPLS TE, and RSVP-TE in the system and interface views on every
node along a bypass tunnel. (See Enabling MPLS TE and RSVP-TE.)
l (Optional) Configure the physical bandwidth for a bypass tunnel if the primary tunnel
bandwidth needs to be protected. (See (Optional) Configuring TE Attributes.)
l Enable CSPF on the ingress and transit nodes along a primary tunnel.

Figure 3-10 MPLS TE Auto FRR configuration
Enabling the TE Auto FRR
Enabling the TE FRR and Configuring the

Auto Bypass Tunnel Attributes
Modifying PSB and RSB Timeout

Multiplier
Mandatory
procedure
Optional
procedure
3.23.1 Enabling TE Auto FRR

MPLS TE Auto FRR must be enabled on the ingress or a transit node of a primary tunnel
before MPLS TE Auto FRR is configured.
Procedure
Step 2 Run mpls
Step 3 Run mpls te auto-frr [ self-adapting ]
MPLS TE Auto FRR is enabled globally.
To enable an automatic bypass tunnel to dynamically select node or link protection based on
network conditions, configure self-adapting.
Step 4 Run quit
The system view is displayed again.
The view of the outbound interface of the primary tunnel is displayed.
Step 6 (Optional) Run mpls te auto-frr { block | default | link | node | self-adapting }
TE Auto FRR is enabled on the interface.
By default, all MPLS TE-enabled interfaces support TE Auto FRR after MPLS TE Auto FRR
is enabled globally. To disable TE Auto FRR on interfaces, run the mpls te auto-frr block
command on these interfaces. The mpls te auto-frr block command disables TE Auto FRR
on interfaces, even if TE Auto FRR is enabled or re-enabled globally.

To enable an automatic bypass tunnel bound to the current tunnel to dynamically select node
or link protection based on network conditions, configure self-adapting.
NOTE
l If the mpls te auto-frr default command is configured in the interface view, the Auto FRR
capability on the interface is consistent with the global Auto FRR capability.
l After node protection is enabled, if an automatic bypass tunnel cannot be established due to none
available links, the penultimate hop (not other hops) on the primary tunnel attempts to establish an
automatic bypass tunnel to implement link protection.
l If the mpls te auto-frr node command without self-adapting configured is run, and the requirement
for node protection is not met, the penultimate hop (but not other hops) on the primary tunnel
attempts to set up an automatic bypass tunnel for link protection.
Step 7 Run commit

----End
3.23.2 Enabling MPLS TE FRR and Configuring Attributes for an

Automatic Bypass Tunnel
After MPLS TE FRR is enabled on the ingress of a primary tunnel, a bypass tunnel is
established automatically.
Procedure
The view of the primary tunnel interface is displayed.
TE FRR is enabled.
If TE FRR bandwidth protection is needed, configure the bandwidth parameter in this
command.
Step 4 (Optional) Run mpls te bypass-attributes [ bandwidth bandwidth | priority setup-priority
[ hold-priority ] ]
Attributes are set for the automatic bypass tunnel.
NOTE
l The bandwidth attribute can only be set for the bypass tunnel after the mpls te fast-reroute
bandwidth command is run for the primary tunnel.
l The bypass tunnel bandwidth cannot exceed the primary tunnel bandwidth.
l If no attributes are configured for an automatic bypass tunnel, by default, the automatic bypass
tunnel uses the same bandwidth as that of the primary tunnel.
l The setup priority of a bypass tunnel must be lower than or equal to the holding priority. These
priorities cannot be higher than the corresponding priorities of the primary tunnel.
l If the primary tunnel bandwidth is changed or FRR is disabled, the bypass tunnel attributes are
automatically deleted.

Step 5 (Optional) Configure affinities for the automatic bypass tunnel.

Affinities determine link attributes of an automatic bypass tunnel. Affinities and a link
administrative group attribute are used together to determine over which links the automatic
bypass tunnel can be established.
Perform either of the following configurations:
l Set a hexadecimal number.

a. Run quit
The interface view of the link through which a bypass tunnel passes is displayed.
c. Run mpls te link administrative group value
An administrative group attribute is specified.
d. Run quit
e. Run interface tunnel tunnel-number
The tunnel interface view of the primary tunnel is displayed.
f. Run mpls te bypass-attributes affinity property properties [ mask mask-value]
An affinity of the bypass tunnel is configured.
l Set an affinity name.
Naming an affinity makes the affinity easy to understand and maintain. Setting an
affinity name is recommended.
a. Run quit
b. Run path-constraint affinity-mapping
displayed.
Repeat this step on each node used to calculate the path over which an automatic
bypass tunnel is established. The affinity name configured on each node must match
the mappings between affinity bits and names.
c. Run attribute affinity-name bit-sequence bit-number
d. Run quit
e. Run interface interface-type interface-number
f. Run mpls te link administrative group name bit-name &<1-32>
g. Run quit

h. Run interface tunnel tunnel-number

i. Run mpls te bypass-attributes affinity { include-all | include-any | exclude } bit-
name &<1-32>
NOTE
If an automatic bypass tunnel that satisfies the specified affinity cannot be established, a node will
bind a manual bypass tunnel satisfying the specified affinity to the primary tunnel.
Step 6 Run commit

----End
3.23.3 (Optional) Configuring Auto Bypass Tunnel Re-

Optimization
Auto Bypass tunnel re-optimization allows paths to be recalculated at certain intervals for an
auto bypass tunnel. If an optimal path is recalculated, a new auto bypass tunnel will be set up
over this optimal path. In this manner, network resources are optimized.
Context
Network changes often cause the changes in optimal paths. Auto bypass tunnel re-
optimization allows the system to re-optimize 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. 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.
Step 4 (Optional) Run return
Return to the user view.
Step 5 (Optional) Run mpls te reoptimization [ auto-tunnel name tunnel-interface | tunnel tunnel-
number ]
Manual re-optimization is enabled.
After you configure the automatic re-optimization in the MPLS view, you can return to the
user view and run the mpls te reoptimization command to immediately re-optimize the
tunnels 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.

Step 6 Run commit

----End
3.23.4 Verifying the MPLS TE Auto FRR Configuration

After configuring MPLS TE Auto FRR, you can view detailed information about the bypass
tunnel.
Prerequisites
MPLS TE Auto FRR has been configured.
Procedure
l Run the display mpls te tunnel verbose command to check the binding of a primary
tunnel and an automatic bypass tunnel.
l Run the display mpls te tunnel-interface command to check detailed information about
an automatic bypass tunnel.
l Run the display mpls te tunnel path command to check information about paths of a
primary or bypass tunnel.
----End
Example
Run the display mpls te tunnel verbose command to view detailed information about TE
tunnels.
<HUAWEI> display mpls te tunnel verbose
No : 1
Tunnel-Name : Tunnel2
TunnelIndex : -
Session ID : 200 LSP ID : 1
Lsr Role : Ingress
Ingress LSR ID : 1.1.1.1
Egress LSR ID : 3.3.3.3
In-Interface : -
Out-Interface : GE1/0/0
Sign-Protocol : RSVP TE Resv Style : SE
IncludeAnyAff : 0x0 ExcludeAnyAff : 0x0
IncludeAllAff : 0x0
ER-Hop Table Index : - AR-Hop Table Index: 2
C-Hop Table Index : -
PrevTunnelIndexInSession: - NextTunnelIndexInSession: -
PSB Handle : 65546
Created Time : 2009/03/30 09:52:03 DST
--------------------------------
DS-TE Information
--------------------------------
Bandwidth Reserved Flag : Reserved
CT0 Bandwidth(Kbit/sec) : 10000 CT1 Bandwidth(Kbit/sec): 0
Setup-Priority : 7 Hold-Priority : 7

--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass In Use : Not Used
Bypass Tunnel Id : 67141670
BypassTunnel : Tunnel Index[AutoTunnel67141670], InnerLabel[3]
Bypass Lsp ID : 2049 FrrNextHop : 3.3.3.3
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 : -
tunnel is Up.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-


Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
Run the display mpls te tunnel path command to view information about path attributes of
tunnels.
Lsp ID : 1.1.1.1 :200:1
Hop Information
Hop 2 2.1.1.2 Label 106497
Hop 3 2.2.2.2
Hop 5 3.1.1.2 Label 3
Hop 6 3.3.3.3
Lsp ID : 1.1.1.1 :67141670 :2
Hop Information
Hop 1 10.1.1.2
Hop 2 10.1.1.1
Hop 3 3.3.3.3

Lsp ID : 2.2.2.2 :67141671 :209
Hop Information
Hop 1 2.2.2.2
Hop 2 2.1.1.2
Hop 3 2.1.1.1
Hop 4 1.1.1.1
Hop 5 10.1.1.2
Hop 6 10.1.1.1
Hop 7 3.3.3.3

3.24 Configuring MPLS Detour FRR

MPLS detour FRR automatically creates a detour LSP on each eligible node along primary
CR-LSP to protect downstream links or nodes.
Context
TE FRR provides local link or node protection for TE tunnels. TE FRR is working in either
facility backup or one-to-one backup. Table 3-13 compares facility backup and one-to-one
backup.
Table 3-13 Comparison between facility backup and one-to-one backup

Mode Advantages Disadvantage
Facility Is extensible, resource efficient, and Bypass tunnels must be manually

backup easy to implement. planned and configured, which is
time-consuming and laborious on a
complex network.
One-to-one Is easy to configure, eliminates Each node has to maintain the status
backup manual network planning, and of detour LSPs, which consumes
provides flexibility on a complex additional bandwidth resources.
network.
TE FRR in one-to-one backup mode is also called MPLS detour FRR. Each eligible node
automatically creates a detour LSP.
This section describes how to configure MPLS detour FRR. For information about how to
configure TE FRR in facility backup mode, see 3.22 Configuring MPLS TE Manual FRR
and 3.23 Configuring MPLS TE Auto FRR.
NOTE
l The facility backup and one-to-one backup modes are mutually exclusive on the same TE tunnel
interface. If both modes are configured, the latest configured mode overrides the previous one.
l After MPLS detour FRR is configured, nodes on a TE tunnel are automatically enabled to record
routes and labels. Before you disable the route and label record functions, disable MPLS detour
FRR.
Before configuring MPLS detour FRR, configure an RSVP-TE tunnel.
NOTE
Enable CSPF on each node along both the primary and backup LSPs.
Procedure

Step 2 Run interface tunnelinterface-number
The TE tunnel interface view is displayed.
Step 3 Run mpls te detour
MPLS detour FRR is enabled.
On the same tunnel interface, both the mpls te detour and mpls te fast-reroute commands
can be run. The latest configuration overrides the previous one.
Step 4 Run commit
----End

After configuring MPLS detour FRR, run the following commands to check the
configurations.
l Run the display mpls te tunnel command to view TE tunnel information.

<HUAWEI> display mpls te tunnel
* means the LSP is detour LSP
------------------------------------------------------------------------------
-
Ingress LsrId Destination LSPID In/OutLabel R Tunnel-name
------------------------------------------------------------------------------
-
1.1.1.1 5.5.5.5 23 -/32830 I Tunnel1
1.1.1.1 5.5.5.5 23 *-/32830 I Tunnel1
------------------------------------------------------------------------------
-
R: Role, I: Ingress, T: Transit, E: Egress
l Run the display mpls te tunnel path command to view TE tunnel path information on a
local node.
Lsp ID : 1.1.1.1 :100 :23
Hop Information
Hop 0 10.1.1.1 Local-Protection available | node
Hop 1 10.1.1.2 Label 32830
Hop 2 3.3.3.3 Label 32830
Hop 4 10.1.3.2 Label 3
Hop 5 5.5.5.5 Label 3

Lsp ID : 1.1.1.1 :100 :23
Detour Lsp PLR ID :10.1.2.1
Hop Information
Hop 0 10.1.2.1
Hop 1 10.1.2.2 Label 32830
Hop 2 2.2.2.2 Label 32830
Hop 3 10.1.6.1
Hop 4 10.1.6.2 Label 32831
Hop 5 4.4.4.4 Label 32831
Hop 6 10.1.7.1
Hop 7 10.1.7.2 Label 32830
Hop 8 6.6.6.6 Label 32830
Hop 9 10.1.5.2
Hop 10 10.1.5.1 Label 3
Hop 11 5.5.5.5 Label 3

l Run the display mpls rsvp-te psb-content command to view RSVP-TE path state block
(PSB) information.
<HUAWEI> display mpls rsvp-te psb-content
------------------------------------------------------------------------------
-
The PSB Content
------------------------------------------------------------------------------
-
Session Attribute:
Label Record desired
LSP Type: -
FRR Mode: One-to-One BackUp
ERO Information:
RRO Information-
-----
Peak data rate: 0

SendPacketCounter: 1947 RecvPacketCounter: 0
SendPathCounter: 1947 RecvPathCounter: 0
SendResvCounter: 0 RecvResvCounter: 0
SendPathErrCounter: 0 RecvPathErrCounter: 0
SendResvErrCounter: 0 RecvResvErrCounter: 0
Detour Information:
PLR ID : 10.1.2.1
Avoid Node: 3.3.3.3
3.25 Configuring P2MP TE FRR

P2MP TE fast reroute (FRR) provides local link protection for a P2MP TE tunnel. It
establishes a bypass tunnel to protect sub-LSPs. If a link fails on the P2MP TE tunnel, traffic
switches to the bypass tunnel within 50 milliseconds, which increases tunnel reliability.

Usage Scenario
P2MP TE FRR establishes a bypass tunnel to provide local link protection for the P2MP TE
tunnel called the primary tunnel. The bypass tunnel is a P2P TE tunnel. The principles and
concepts of P2MP TE FRR are similar to those of P2P TE FRR.
The NE40E supports FRR link protection, not node protection, over a P2MP TE tunnel.
Therefore, path planning for the bypass tunnel is irrelevant to node protection. For example,
in Figure 3-11, the bypass tunnel path planned for the link between P1 and P2 can provide
link protection. However, the link between P3 and PE4 for which a bypass tunnel path is
planned traverses the node P4 so that the bypass tunnel cannot be bound to the primary tunnel
or provide link protection.
Figure 3-11 FRR link protection for a P2MP TE tunnel

P5
P1 ( PLR ) P2 ( MP ) PE2
PE1
P3 P4 PE3
P6 PE4
Bypass tunnel
Primary tunnel
P2P and P2MP TE tunnels can share a bypass tunnel. Therefore, when planning bandwidth
for the bypass tunnel, ensure that the bypass tunnel bandwidth is equal to the total bandwidth
of the bound P2P and P2MP tunnels.
NOTE
If traffic is switched to a P2MP FRR tunnel, the forwarding performance deteriorates temporarily, and
the impact is removed after traffic switches back to the primary tunnel.
In NG MVPN scenarios, when P2MP TE FRR protection is used, the interface of a primary P2MP
tunnel needs to be enabled to delay in going Up. The delay is related to the number of VPN multicast
groups over the tunnel. For 1000 multicast groups, set the delay time to 30s. Increase the delay time if
more multicast groups are configured.
Before configuring P2MP TE FRR, configure a P2MP TE tunnel.

3.25.1 Configuring Manual FRR for a Manually Configured P2MP

TE Tunnel
Manual FRR can be configured on the tunnel interface of a manually configured P2MP TE
tunnel.
Context
The process of configuring P2MP TE FRR is identical to that for configuring P2P TE FRR,
which includes the following two procedures:
l Enable the P2MP TE FRR function on the tunnel interface of the primary tunnel
(P2MP TE tunnel).
l Configure a bypass tunnel on the point of local repair (PLR) node and bind the
bypass tunnel to the primary tunnel.
NOTE
Manual P2MP TE FRR only applies to manual P2MP TE tunnels.
Procedure
l Enable the P2MP TE FRR function on the tunnel interface of the primary tunnel (P2MP
TE tunnel).
a. Run system-view
c. Run mpls te fast-reroute [ bandwidth ]
The P2MP TE FRR function is enabled.
NOTE
You can run the mpls te bypass-attributes command to configure bypass tunnel attributes
only after running the mpls te fast-reroute bandwidth command.
d. (Optional) Run mpls te bypass-attributes
Bypass tunnel attributes are configured.
e. Run commit
l Configure a bypass tunnel on the PLR node and bind the bypass tunnel to the primary
tunnel.
a. Run system-view
b. Run interface tunnel tunnel-number
The tunnel interface view of a bypass tunnel is displayed.
c. Run tunnel-protocol mpls te

d. Run destination ip-address

The LSR ID of a merge point (MP) is specified as the destination address of the
bypass tunnel.
e. Run mpls te tunnel-id tunnel-id
The bypass tunnel ID is specified.
f. (Optional) Run mpls te path explicit-path path-name
An explicit path is specified for the bypass tunnel.
NOTE
The explicit path planned for the bypass tunnel and the primary tunnel path to be protected
must use different physical links.
g. (Optional) Run mpls te bandwidth ct0 bandwidth
The bypass tunnel bandwidth is configured.
h. Run mpls te bypass-tunnel
i. Run mpls te protected-interface interface-type interface-number
A link interface to be protected by a bypass tunnel is specified.
j. Run commit
----End
3.25.2 Configuring FRR for Automatic P2MP TE Tunnels

Auto P2MP TE FRR is configured in a P2MP TE template for automatic P2MP TE tunnels.
Context
The process of configuring FRR for automatic P2MP TE tunnels is as follows:
l Configure the ingress.
l Configure a bypass tunnel on the PLR and bind it to the primary tunnel.
Procedure
l Configure the ingress.
a. Run system-view
b. Run mpls te p2mp-template template-name
A P2MP tunnel template is created, and the P2MP tunnel template view is
displayed.
c. Run fast-reroute [ bandwidth ]
P2MP TE FRR is enabled.
The bandwidth parameter enables bandwidth protection for the primary tunnel. A
bypass tunnel is selected to provide bandwidth for the primary tunnel.

d. (Optional) Run bypass-attributes { bandwidth bandwidth | priority setup-priority

[ hold-priority ] } *
Attributes for the FRR bypass tunnel are set.
The bandwidth parameter sets the bandwidth for the bypass tunnel. The priority
parameter sets the holding and setup priority values for the bypass tunnel.
e. Run commit

l Configure a bypass tunnel on the PLR node and bind the bypass tunnel to the primary
tunnel.
a. Run system-view

b. Run interface tunnel tunnel-number
The tunnel interface view of a bypass tunnel is displayed.

c. Run tunnel-protocol mpls te

d. Run destination ip-address
The LSR ID of a merge point (MP) is specified as the destination address of the
bypass tunnel.
e. Run mpls te tunnel-id tunnel-id
The bypass tunnel ID is specified.

f. (Optional) Run mpls te path explicit-path path-name
An explicit path is specified for the bypass tunnel.
NOTE
The explicit path planned for the bypass tunnel and the primary tunnel path to be protected
must use different physical links.
g. (Optional) Run mpls te bandwidth ct0 bandwidth
The bypass tunnel bandwidth is configured.

h. Run mpls te bypass-tunnel

i. Run mpls te protected-interface interface-type interface-number
A link interface to be protected by a bypass tunnel is specified.

j. Run commit
----End
3.25.3 Verifying the P2MP TE FRR Configuration

After configuring P2MP TE FRR, verify P2MP TE FRR information.

Prerequisites
P2MP TE FRR has been configured.
Procedure
l Run the display mpls te p2mp tunnel frr [ tunnel-name ] [ lsp-id ingress-lsr-id session-
id local-lsp-id [ s2l-destination leaf-address ] ] command to check bypass tunnel
attributes.
----End
Example
After completing the configurations, run the display mpls te p2mp tunnel frr command on
the PLR to view the bypass tunnel status and bypass tunnel attributes.
<HUAWEI> display mpls te p2mp tunnel frr
Lsp ID : 1.1.1.1 :100 :4
Bypass In Use : Not Exists
Bypass Tunnel ID : 0
BypassTunnel : -
Bypass LSP ID : -
FrrNextHop : -
Bypass Attribute
Setup Priority : 7
Hold Priority : 7
HopLimit : 32
Bandwidth : 0
IncludeAnyGroup : 0
ExcludeAnyGroup : 0
IncludeAllGroup : 0

Lsp ID : 1.1.1.1 :100 :4
Bypass In Use : In Use
BypassTunnel : Tunnel Index[Tunnel1], InnerLabel[32774]
Bypass LSP ID : 72
FrrNextHop : 4.4.4.4
Bypass Attribute
Setup Priority : 7
Hold Priority : 7
HopLimit : 32
Bandwidth : 0
IncludeAnyGroup : 0
ExcludeAnyGroup : 0
IncludeAllGroup : 0
3.26 Configuring P2MP TE Auto FRR

Auto fast reroute (FRR) is a local protection mechanism in MPLS TE. Auto FRR deployment
is easier than manual FRR deployment.
Usage Scenario
FRR protection is configured for networks requiring high reliability. If P2MP TE manual FRR
is used (configured by following the steps in Configuring P2MP TE FRR), a lot of

configurations are needed on a network with complex topology and a great number of links to
be protected. In this situation, P2MP TE Auto FRR can be configured.
Unlike P2MP TE manual FRR, P2MP TE Auto FRR automatically creates a bypass tunnel
that meets traffic requirements, which simplifies configurations.
The NE40E supports upgrade binding that if a bypass tunnel with a priority higher than an
existing bypass tunnel is calculated, the primary tunnel will be automatically unbound from
the existing bypass tunnel and bound to the one with the higher priority. A bypass tunnel is
selected based on the following rules prioritized in descending order:
l An SRLG attribute is configured for a bypass tunnel.
l If P2MP TE Auto FRR and an SRLG attribute are configured, the primary and bypass
tunnels must be in different SRLGs. If these two tunnels are in the same SRLG, the
bypass tunnel may fail to be established.
l A bypass tunnel with bandwidth protection configured takes preference over that with
non-bandwidth protection configured.
A bypass tunnel provides link protection, not node protection, for its primary tunnel.
Before configuring P2MP TE Auto FRR, complete the following tasks:
l Configure a primary P2MP TE tunnel.
l Enable MPLS, MPLS TE, and RSVP-TE globally and in the physical interface view on
each node along a bypass tunnel to be established. For configuration details, see
Enabling MPLS TE and RSVP-TE.
l (Optional) To protect bandwidth of the primary tunnel, set the physical link bandwidth
for the bypass tunnel to be established. For configuration details, see (Optional)
Configuring Link TE Attributes.
l Enable CSPF on each node along the bypass tunnel to be established.
Figure 3-12 Flowchart for configuring P2MP TE Auto FRR
Enable P2MP TE Auto FRR
Enable MPLS TE FRR and Configuring

Attributes for an Automatic Bypass Tunnel
Configure Auto Bypass Tunnel

Re-Optimization
Mandatory
Optional
3.26.1 Enabling P2MP TE Auto FRR

Enabling P2MP TE Auto FRR on the ingress or a transit node of the primary tunnel is the
prerequisite of configuring TE Auto FRR.

Context
Perform either of the following operations to enable P2MP TE Auto FRR on the NE40E:
l Configure the entire device and its interface when Auto FRR needs to be configured on
most interfaces.
l Only configure a specified interface when Auto FRR needs to be configured only on a
few interfaces.
Procedure
l Configure the entire device and its interface.
a. Run system-view

b. Run mpls

c. Run mpls te auto-frr self-adapting
MPLS TE Auto FRR is enabled globally.
P2MP TE FRR only supports link protection, while a bypass tunnel that the ingress
establishes supports node protection by default. As a result, the bypass tunnel fails
to be established. To prevent the establishment failure, configure the self-adapting
parameter in the mpls te auto-frr command, which enables the ingress to
automatically switch from node protection to link protection.
d. Run mpls te p2mp-te auto-frr enable
P2MP TE Auto FRR is enabled globally.

e. Run quit

f. Run interface interface-type interface-number
The view of the outbound interface on the primary tunnel is displayed.

g. (Optional) Run mpls te auto-frr { block | default }
TE Auto FRR is enabled.
After Auto FRR is enabled globally, the mpls te auto-frr default command is by
default run on all MPLS TE interfaces on the device. To disable Auto FRR on a
specified interface, run the mpls te auto-frr block command on that interface.
After the mpls te auto-frr block command is run, Auto FRR is disabled on the
specified interface, regardless of whether Auto FRR is enabled or reenabled
globally.
NOTE
l If the mpls te auto-frr default command is run, the interface Auto FRR capability status
is the same as the global Auto FRR capability status.
h. Run commit

l Configure a specified interface.

a. Run system-view

b. Run mpls

c. Run mpls te p2mp-te auto-frr enable
P2MP TE Auto FRR is enabled globally.

d. Run quit

The view of the outbound interface on the primary tunnel is displayed.

f. Run mpls te auto-frr { default | link | self-adapting }
P2MP TE Auto FRR is enabled.

g. Run commit
----End
3.26.2 Enabling the TE FRR and Configuring the Auto Bypass

Tunnel Attributes
After MPLS TE FRR is enabled on the ingress of a primary tunnel, a bypass tunnel is
established automatically.
Procedure
The view of the primary tunnel interface is displayed.
TE FRR is enabled.
If TE FRR bandwidth protection is needed, configure the bandwidth parameter in this

command.
Step 4 (Optional) Run mpls te bypass-attributes [ bandwidth bandwidth | priority setup-priority

[ hold-priority ] ]
Attributes are set for the automatic bypass tunnel.

NOTE
l The bandwidth attribute can only be set for the bypass tunnel after the mpls te fast-reroute
bandwidth command is run for the primary tunnel.
l The bypass tunnel bandwidth cannot exceed the primary tunnel bandwidth.
l If no attributes are configured for an automatic bypass tunnel, by default, the automatic bypass
tunnel uses the same bandwidth as that of the primary tunnel.
l The setup priority of a bypass tunnel must be lower than or equal to the holding priority. These
priorities cannot be higher than the corresponding priorities of the primary tunnel.
l If the primary tunnel bandwidth is changed or FRR is disabled, the bypass tunnel attributes are
automatically deleted.
Step 5 (Optional) Configure affinities for the automatic bypass tunnel.

Affinities determine link attributes of an automatic bypass tunnel. Affinities and a link
administrative group attribute are used together to determine over which links the automatic
bypass tunnel can be established.
Perform either of the following configurations:
l Set a hexadecimal number.
a. Run quit
c. Run mpls te link administrative group value
d. Run quit
e. Run interface tunnel tunnel-number
f. Run mpls te bypass-attributes affinity property properties [ mask mask-value]
l Set an affinity name.
Naming an affinity makes the affinity easy to understand and maintain. Setting an
affinity name is recommended.
a. Run quit
b. Run path-constraint affinity-mapping
displayed.
Repeat this step on each node used to calculate the path over which an automatic
bypass tunnel is established. The affinity name configured on each node must match
the mappings between affinity bits and names.
c. Run attribute affinity-name bit-sequence bit-number

d. Run quit
f. Run mpls te link administrative group name bit-name &<1-32>
g. Run quit
h. Run interface tunnel tunnel-number
i. Run mpls te bypass-attributes affinity { include-all | include-any | exclude } bit-
name &<1-32>
NOTE
If an automatic bypass tunnel that satisfies the specified affinity cannot be established, a node will
bind a manual bypass tunnel satisfying the specified affinity to the primary tunnel.
Step 6 Run commit
----End
3.26.3 (Optional) Configuring Auto Bypass Tunnel Re-

Optimization
Auto Bypass tunnel re-optimization allows paths to be recalculated at certain intervals for an
auto bypass tunnel. If an optimal path is recalculated, a new auto bypass tunnel will be set up
over this optimal path. In this manner, network resources are optimized.
Context
Network changes often cause the changes in optimal paths. Auto bypass tunnel re-
optimization allows the system to re-optimize 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. 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.

Step 4 (Optional) Run return

Return to the user view.
Step 5 (Optional) Run mpls te reoptimization [ auto-tunnel name tunnel-interface | tunnel tunnel-
number ]
Manual re-optimization is enabled.
After you configure the automatic re-optimization in the MPLS view, you can return to the
user view and run the mpls te reoptimization command to immediately re-optimize the
tunnels 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.
Step 6 Run commit
----End
3.26.4 Verifying the P2MP TE Auto FRR Configuration

After configuring P2MP TE Auto FRR, verify P2MP TE Auto FRR information.
Prerequisites
P2MP TE Auto FRR has been configured.
Procedure
l Run the display mpls te p2mp tunnel frr [ tunnel-name ] [ lsp-id ingress-lsr-id session-
id local-lsp-id [ s2l-destination leaf-address ] ] command to check bypass tunnel
attributes.
----End
Example
After completing the configurations, run the display mpls te p2mp tunnel frr command on
the point of local repair (PLR) to view the bypass tunnel status and bypass tunnel attributes.
<HUAWEI> display mpls te p2mp tunnel frr
Lsp ID : 1.1.1.1 :1 :9
Bypass In Use : Not Exists
BypassTunnel : -
Bypass LSP ID : -
FrrNextHop : -
Bypass Attribute(Not configured)
Setup Priority : -
Hold Priority : -
HopLimit : -
Bandwidth : -
IncludeAnyGroup : -
ExcludeAnyGroup : -
IncludeAllGroup : -

Lsp ID : 1.1.1.1 :1 :10


Bypass LSP ID : 11
FrrNextHop : 3.1.1.1
Bypass Attribute
Setup Priority : 7
Hold Priority : 7
HopLimit : 32
Bandwidth : 0
IncludeAnyGroup : 0
ExcludeAnyGroup : 0
IncludeAllGroup : 0
3.27 Configuring CR-LSP Backup

CR-LSP backup is configured to provide end-to-end protection for a CR-LSP.
Usage Scenario
CR-LSP backup provides an end-to-end path protection for an entire CR-LSP.
A backup CR-LSP is established in either of the following modes:
l Hot-standby mode: A backup CR-LSP and a primary CR-LSP are created
simultaneously.
l Ordinary backup mode: A backup CR-LSP is created only after a primary CR-LSP fails.
The paths of backup CR-LSPs in the preceding modes are different:
l Hot standby mode: The path of a backup CR-LSP and the path of a primary CR-LSP
overlap only if the backup CR-LSP is established over an explicit path.
l Ordinary backup mode: The path of a backup CR-LSP and the path of a primary CR-
LSP overlap in any cases.
Hot standby supports best-effort paths. If both the primary and backup CR-LSPs fail, a
temporary path, called a best-effort path, is established. All traffic switches to this path. In
Figure 3-13, the path of the primary CR-LSP is PE1 -> P1 -> PE2, and the path of the backup
CR-LSP is PE1 -> P2 -> PE2. If both the primary and backup CR-LSPs fail, the node triggers
the setup of a best-effort path along the path PE1 -> P2 -> P1 -> PE2.

Figure 3-13 Schematic diagram for a best-effort path

P1 P2
Primary path
PE1 PE2 Secondary path
Best-effort path
Before configuring CR-LSP backup, complete the following tasks:
l Establish a primary RSVP-TE tunnel.
l Enable MPLS, MPLS TE, and RSVP-TE in the MPLS and physical interface views on
every node along a bypass tunnel. (See Enabling MPLS TE and RSVP-TE.)
l (Optional) Configure the link bandwidth for the backup CR-LSP. (See (Optional)
Configuring TE Attributes.)
l (Optional) Configure an explicit path for the backup CR-LSP. (See (Optional)
Configure an explicit path.)
Figure 3-14 CR-LSP backup configuration
Configure CR-LSP backup.
Configure a best-effort LSP.
Mandatory
Optional
3.27.1 Configuring CR-LSP Backup Parameters

A backup CR-LSP is established in either hot standby or ordinary backup mode. A hot-
standby CR-LSP and an ordinary backup CR-LSP cannot be established simultaneously.

Context
CR-LSP backup is disabled by default. After CR-LSP backup is configured on the ingress of a
primary CR-LSP, the system automatically selects a path for a backup CR-LSP.
Procedure
Step 3 Establish a primary RSVP-TE tunnel
Step 4 Run mpls te backup { hot-standby [ wtr interval ] | ordinary [ best-effort ] }

The mode of establishing a backup CR-LSP is configured.
NOTE
The bypass and backup tunnels cannot be configured on the same tunnel interface. The mpls te bypass-
tunnel and mpls te backup commands cannot be configured on the same tunnel interface. Also, the
mpls te protected-interface and mpls te backup commands cannot be configured on the same tunnel
interface.
Step 5 (Optional) Run mpls te path explicit-path path-name secondary

An explicit path is specified for the backup CR-LSP.
NOTE
The mpls te path explicit-path path-name secondary and mpls te backup commands must be
configured simultaneously.
Step 6 (Optional) Run mpls te affinity property properties [ mask mask-value ] secondary
An affinity is set for the backup CR-LSP.
Step 7 (Optional) Run mpls te hop-limit hop-limit-value secondary
A hop limit value is set for the backup CR-LSP.
NOTE
mpls te hop-limit hop-limit-value secondary and mpls te backup commands must be configured
simultaneously.
Step 8 (Optional) Run mpls te backup hot-standby overlap-path

The path overlapping function is configured for the hot-standby CR-LSP.
By default, a primary CR-LSP and hot-standby CR-LSP are separated. If the network
topology does not meet this requirement, the hot-standby CR-LSP cannot be established. The
path overlapping function allows a hot-standby CR-LSP to use some links of a primary CR-
LSP, to secure the establishment of the hot-standby CR-LSP. The hot-standby and primary
CR-LSPs cannot fully overlap.
Step 9 (Optional) Run mpls te backup hot-standby dynamic-bandwidth
The dynamic bandwidth adjustment function is enabled for the hot-standby CR-LSP.

This function enables 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 helps
efficiently use network resources and reduce network costs.
Step 10 Run commit
----End
3.27.2 (Optional) Configuring a Best-effort Path

A best-effort path is configured to take over traffic if both the primary and backup CR-LSPs
fail.
Context
In hot-standby mode, perform the following steps on the ingress of a TE tunnel:
Procedure
Step 3 Run mpls te backup ordinary best-effort
A best-effort path is configured.
Step 4 (Optional) Run mpls te affinity property properties [ mask mask-value ] best-effort
The affinity property of the best-effort path is configured.
Step 5 (Optional) Run mpls te hop-limit hop-limit-value best-effort
The hop limit is set for the best-effort path.
Step 6 Run commit
----End
3.27.3 (Optional) Configuring a Traffic Switching Policy for a

Hot-Standby CR-LSP
This section describes how to configure a traffic switching policy for a hot-standby CR-LSP.
The traffic switching policy determines whether to switch traffic back to the primary CR-LSP
and sets a switchback delay.

Context
When a primary CR-LSP is Down, traffic switches to the hot-standby CR-LSP. When the
primary CR-LSP is Up, traffic switches back by default. This configuration provides the
flexibility to control the traffic switchover behavior.
Procedure
Step 3 Run mpls te backup hot-standby mode { revertive [ wtr interval ] | non-revertive }
The traffic switching policy is configured for the hot-standby CR-LSP and the switchback
delay is set.
Step 4 Run commit
----End
3.27.4 (Optional) Configuring a Manual Switching Mechanism for

a Primary/Hot-Standby CR-LSP
This section describes how to configure a manual switching mechanism for a primary/hot-
standby CR-LSP. This mechanism allows you to control primary/hot-standby CR-LSP
switchovers using commands.
Context
When a primary CR-LSP needs to be adjusted, you can switch the traffic to the hot-standby
CR-LSP using the hotstandby-switch force command. After the primary CR-LSP has been
adjusted, you can switch back the traffic to the primary CR-LSP using the hotstandby-switch
clear command.
Procedure
Step 3 Run hotstandby-switch { force | clear }
A manual switching mechanism for the primary/hot-standby CR-LSP is configured.

If you specify force, the traffic switches temporarily to the hot-standby CR-LSP. If you
specify clear, the traffic switches back to the primary CR-LSP.
----End
3.27.5 Verifying the CR-LSP Backup Configuration

After configuring CR-LSP backup, you can view information about backup CR-LSPs.
Prerequisites
CR-LSP backup has been configured.
Procedure
l Run the display mpls te tunnel-interface command to check information about a tunnel
interface on the ingress of a tunnel.
l Run the display mpls te hot-standby state { all [ verbose ] | interface tunnel-interface-
name } command to check information about the hot-standby status.
----End
Example
tunnel is Up.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-

Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
Run the display mpls te hot-standby state interface tunnel interface-name command to
view the hot-standby status of the tunnel interface.
<HUAWEI> display mpls te hot-standby state interface Tunnel 1
----------------------------------------------------------------
Verbose information about the Tunnel1 hot-standby state
----------------------------------------------------------------
Tunnel name : Tunnel1
Session ID : 1
Main LSP index : 0x33
Hot-standby LSP index : 0x161
HSB switch result : hot-standby LSP
HSB switch reason : wait to restore
WTR config time : 10 s
WTR remain time : 2 s
Current state : wait to restore
Using overlapped path : no

3.28 Configuring a Tunnel Protection Group

This section describes how to configure a tunnel protection group. A 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.
Usage Scenario
A tunnel protection group provides end-to-end protection for traffic transmitted along TE
tunnel. If a working tunnel fails, bidirectional automatic protection switching switches traffic
to a protection CR-LSP.
NOTE
In an MPLS OAM for associated or co-routed LSP scenario where tunnel APS is configured, if the
primary and backup tunnels use the same path and the path fails, both the tunnels are affected, and
services may be interrupted.
A protected tunnel is called a working tunnel. A tunnel that protects the working tunnel is
called a protection tunnel. The working and protection tunnels form a tunnel protection group.
A tunnel protection group works in 1:1 mode. In 1:1 mode, one protection tunnel protects
only one working tunnel.
l Working and protection tunnels

Tunnel-specific attributes in a tunnel protection group are independent from each other.
For example, a protection tunnel with bandwidth 50 Mbit/s can protect a working tunnel
with 100 Mbit/s bandwidth.
TE FRR can be enabled to protect the working tunnel.
A protection tunnel cannot be protected by other tunnels or have TE FRR enabled.
l Protection switching mechanism
The NE40E performs protection switching based on the following rules.
Table 3-14 Switching rules

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

including forcible and manual switch requests.
A signal failure will trigger traffic switching.
Lockout of ↑ Prevents traffic from switching to a protection

protection tunnel even if a working tunnel fails.
Signal Fail for ↑ Switches traffic from a protection tunnel to a

Protection working tunnel if the protection tunnel fails.
Forcible switch ↑ Forcibly switches traffic from a working tunnel

to a protection tunnel, regardless of whether the
protection tunnel functions properly (unless a
higher priority switch request takes effect).

Switching Priority Description

Request
Signal Fail for ↑ Switches traffic from a working tunnel to a

Working protection tunnel if the working tunnel fails.
Manual switch ↑ 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, which happens after the wait-to-restore
(WTR) timer elapses.
No request Lowest There is no switching request.
Before configuring a tunnel protection group, create a working tunnel and a protection tunnel.
NOTE
l A tunnel protection group uses a configured protection tunnel to protect a working tunnel, which
improves tunnel reliability. Configuring working and protection tunnels over separate links is
recommended.
l The working and protection tunnels must be bidirectional. The following types of bidirectional
tunnels are supported:
l Static bidirectional associated LSPs
l Dynamic bidirectional associated LSPs
l Static bidirectional co-routed LSPs
3.28.1 Creating 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, which improves
tunnel reliability.
Context
A tunnel protection group can be configured on the ingress to protect a working tunnel. The
switchback delay time and a switchback mode can also be configured. There are two
switchback modes: revertive and non-revertive. The revertive mode is used by default. A
tunnel protection group working in revertive mode supports the switchback delay time.
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 time a signal failure is declared and the
time protection switching is initiated. holdoff-time specifies a multiplier of 100
milliseconds.
NOTE
Holdoff-time = 100 milliseconds x holdoff-time

l In non-revertive mode, traffic does not switch back to a working tunnel even after the
working tunnel recovers.
l In revertive mode, traffic switches back to a working tunnel after the working tunnel
recovers.
l Wait to restore (WTR) time is the time elapses before traffic switching is performed. The
wtr-time parameter specifies a multiplier of 30 seconds.
NOTE
WTR time = 30 seconds x wtr-time
Step 4 Run commit
Step 5 Configure a detection mechanism.
----End
Follow-up Procedure
You can also perform the preceding steps to modify a protection tunnel group.
An MPLS TE tunnel protection group can be detected by MPLS OAM or MPLS-TP OAM to
rapidly trigger protection switchovers if a fault occurs.
After an MPLS TE tunnel group is created, properly select an MPLS OAM mechanism:
l If both the working and protection tunnels are static, configure MPLS OAM for
bidirectional associated LSPs.
l If both the working and protection tunnels are static bidirectional co-routed LSPs,
configure MPLS OAM for bidirectional co-routed LSPs.
l If OAM is deleted before APS is deleted, APS incorrectly considers that OAM has
detected a link fault, affecting protection switching. To resolve this issue, re-configure
OAM.
If both the working and protection tunnels are both static bidirectional co-routed CR-LSPs,
Configuring MPLS-TP OAM for a Bidirectional Co-routed LSP.

3.28.2 (Optional) Configuring the Protection Switching Trigger

Mechanism
This section describes how to configure the protection switching trigger mechanism for a
tunnel protection group to forcibly switch traffic to the working or protection tunnel.
Alternatively, you can perform a traffic switchover manually.
Context
Read switching rules before configuring the protection switching trigger mechanism.
Perform the following steps on the ingress of the tunnel protection group as needed:
Procedure
Step 3 Select one of the following protection switching trigger methods as required:
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
NOTE
The preceding commands can take effect immediately after being run, without the commit command
executed.
----End
3.28.3 Verifying the Tunnel Protection Group Configuration

After configuring a tunnel protection group, run display commands to view information about
the tunnel protection group and the binding between the working and protection tunnels.
Prerequisites
A tunnel protection group has been configured.
Procedure
Step 1 Run the display mpls te protection tunnel { all | tunnel-id | interface tunnel-interface-
name } [ 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-name } command to check the binding between the working and protection tunnels.
----End

Example
After completing the configurations, you can run a display command to view the
configuration of a tunnel protection group.
# Run the display mpls te protection tunnel all command on the ingress to view information
about the tunnel protection group.
<HUAWEI> 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 display mpls te protection binding protect-tunnel tunnel-id command. The
command output shows that a protection tunnel has been bound to a working tunnel.
<HUAWEI> display mpls te protection binding protect-tunnel 101
------------------------------------------------------------------------
Binding information of( tunnel id: 101 )
------------------------------------------------------------------------
Protect-tunnel id :101
Protect-tunnel name :Tunnel1
Maximum number of bound work-tunnels :8
Currently bound work-tunnels :Total( 1 )
:Tunnel2
3.29 Configuring Isolated LSP Computation

To improve label switched path (LSP) reliability on a network that has the constraint-based
routed label switched path (CR-LSP) hot standby feature, you can configure the isolated LSP
computation feature so that the device uses both the disjoint algorithm and the constrained
shortest path first (CSPF) algorithm to compute isolated primary and hot-standby LSPs.
Context
Most IP radio access networks (IP RANs) that use Multiprotocol Label Switching (MPLS) TE
have high reliability requirements for LSPs. However, the existing CSPF algorithm simplifies
the LSP path according to the principle of minimizing the link cost, and can not automatically
calculate the completely separate primary and secondary LSP paths.
Specifying explicit paths can meet this reliability requirement; this method, however, does not
adapt to topology changes. Each time a node is added to or deleted from the IP RAN, carriers
must modify the explicit paths, which is time-consuming and laborious.
To resolve these problems, you can configure isolated LSP computation. After this feature is
enabled, the disjoint and CSPF algorithms work together to compute primary and hot-standby
LSPs at the same time and cut off crossover paths of the two LSPs. Then, the device gets the
isolated primary and hot-standby LSPs.
NOTE
l Isolated LSP computation is a best-effort technique. If the disjoint and CSPF algorithms cannot get
isolated primary and hot-standby LSPs or two isolated LSPs do not exist, the device uses the
primary and hot-standby LSPs computed by CSPF.
l After you enable the disjoint algorithm, the shared risk link group (SRLG), if configured, becomes
ineffective.

Before configuring isolated LSP computation, complete the following tasks:
l Configure an RSVP-TE tunnel.
l Configure CR-LSP backup and establish a hot-standby CR-LSP.
NOTE
l CSPF must be enabled on ingress node of the RSVP-TE tunnel.

l Isolated LSP computation requires the collaboration of the CR-LSP hot standby feature and requires
the hot-standby LSP to have the same reserved bandwidth as the primary LSP.
Procedure
Step 3 Run mpls te cspf disjoint
The disjoint algorithm is enabled.
Step 4 Run commit
----End

l Run the display mpls te cspf destination ip-address computation-mode disjoint
command to check the computed primary and hot-standby LSPs after the disjoint
algorithm is enabled.
l Run the display mpls te tunnel path tunnel-name command to check information about
the actual primary and hot-standby LSPs.
Run the display mpls te cspf destination ip-address computation-mode disjoint command
to view the computed primary and hot-standby LSPs after the disjoint algorithm is enabled.
<HUAWEI> display mpls te cspf destination 6.6.6.6 computation-mode disjoint
Main path for the given constraints is:
10.1.1.1 Include
10.1.1.2 Include
10.1.4.1 Include
10.1.4.2 Include
10.1.5.1 Include
10.1.5.2 Include
The total metrics of the calculated path is : 16
Hot-standby path for the given constraints is:

10.1.2.1 Include
10.1.2.2 Include
10.1.6.1 Include
10.1.6.2 Include
10.1.7.1 Include
10.1.7.2 Include
Complete disjoint path computed and the total metrics of the calculated path
is : 21

Run the display mpls te tunnel path tunnel-name command to view information about the
actual primary and hot-standby LSPs.
<HUAWEI> display mpls te tunnel path Tunnel11
Lsp ID : 1.1.1.1 :1 :2
Hop Information
Hop 0 10.1.1.1
Hop 1 10.1.1.2
Hop 2 3.3.3.3
Hop 3 10.1.4.1
Hop 4 10.1.4.2
Hop 5 5.5.5.5
Hop 6 10.1.5.1
Hop 7 10.1.5.2
Hop 8 6.6.6.6

Lsp ID : 1.1.1.1 :1 :3
Hop Information
Hop 0 10.1.2.1
Hop 1 10.1.2.2
Hop 2 2.2.2.2
Hop 3 10.1.6.1
Hop 4 10.1.6.2
Hop 5 4.4.4.4
Hop 6 10.1.7.1
Hop 7 10.1.7.2
Hop 8 6.6.6.6
The command outputs show that the computed primary and hot-standby LSPs are the same as
the actual primary and hot-standby LSPs, indicating that the device has computed two isolated
LSPs.
3.30 Configuring an RSVP GR Helper

An RSVP GR Helper is configured to allow devices along an RSVP-TE tunnel to retain
RSVP sessions during a master/backup switchover.
Usage Scenario
The NE40E can only function as a GR Helper to help a neighbor node to complete RSVP GR.
The RSVP GR Helper needs to be configured only after GR is enabled on the neighbor node
that supports the RSVP GR Restarter. If a local device is only connected to NE40Es running
the same version with the local device, there is no need to configure the RSVP GR Helper on
the local device.
Before configuring an RSVP GR Helper, configure an RSVP-TE tunnel.

Figure 3-15 RSVP GR Helper configuration
Enable the RSVP Hello extension function.
Enable the RSVP GR support capability.
Configure Hello sessions between RSVP GR nodes.
Modify the basic time.
Mandatory
Optional
3.30.1 Enabling the RSVP Hello Extension

The RSVP Hello extension is configured on a GR node and its neighbor to rapidly monitor
reachability between these RSVP nodes.
Procedure
Step 2 Run mpls
The RSVP Hello extension is enabled globally.
Step 4 Run quit
The RSVP Hello extension is enabled on an interface.

After RSVP Hello extension is enabled globally on a node, enable the RSVP Hello extension
on each interface of the node.
Step 7 Run commit
----End
3.30.2 Enabling the RSVP GR Support Capability

The RSVP GR support capability helps a node support its neighbors' GR capabilities.
Procedure
Step 2 Run mpls
RSVP-TE is enabled.
Step 5 Run mpls rsvp-te hello support-peer-gr
The RSVP GR support function is enabled.
Step 6 Run commit
----End
3.30.3 (Optional) Configuring a Hello Session Between RSVP GR

Nodes
If TE FRR is deployed, a Hello session must be established between a PLR and an MP. A
Hello session must be manually established if it cannot be automatically established between
RSVP neighboring nodes.
Procedure
Step 2 Run mpls

RSVP-TE is enabled.
Step 5 Run mpls rsvp-te hello nodeid-session ip-address
A Hello session is established between two RSVP neighboring nodes.
The ip-address parameter specifies the LSR ID of an RSVP neighboring node.
Step 6 Run commit
----End
3.30.4 Verifying the RSVP GR Helper Configuration

After configuring RSVP GR, you can verify that the TE tunnel properly forwards data during
the GR process.
Prerequisites
RSVP GR has been configured.
Procedure
l Run the display mpls rsvp-te graceful-restart command to check the RSVP-TE GR
status.
l Run the display mpls rsvp-te graceful-restart peer [ { interface interface-type
interface-number | node-id } [ ip-address ] ] command to check information about the
RSVP GR status on a neighbor.
----End
Example
Run the display mpls rsvp-te graceful-restart command to view the RSVP GR status on the
local node.
<HUAWEI> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 3.3.3.3
Graceful-Restart Capability: GR-Support
Restart Time: 90000 Milli Second
Recovery Time: 0 Milli Second
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 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 to view the RSVP GR status
on a neighbor.
<HUAWEI> display mpls rsvp-te graceful-restart peer

Remote Node id Neighbor

SrcInstance: 0xFE88AC7E NbrSrcInstance: 0x0
Neighbor Capability:
No Gr capabilities
GR Status: Normal
Restart Time: 0 Millisecond
Recovery Time: 0 Millisecond
Stored GR message number: 0
Neighbor on Interface GigabitEthernet1/0/0

SrcInstance: 0xFE88AC7E NbrSrcInstance: 0x0
Neighbor Capability:
No Gr capabilities
GR Status: Normal
Restart Time: 0 Millisecond
Recovery Time: 0 Millisecond
Stored GR message number: 0
3.31 Configuring the Entropy Label for Tunnels

The entropy label can be used to improve load balancing in traffic forwarding.
Usage Scenario
With the increasing growth of user networks and the extending scope of network services,
load-balancing techniques are used to improve bandwidth between nodes. A great amount of
traffic results in load imbalance on transit nodes. To address the problems, the entropy label
capability can be configured to improve load balancing performance.
Before configuring the entropy label for tunnels, Enabling MPLS TE and RSVP-TE.
Figure 3-16 Configure the entropy tag flow chart for the tunnel
3.31.1 Configuring an LSP Ingress to Deeply Parse IP Packets

This section describes how to enable an LSP ingress to deeply parse IP packets.

Context
After the entropy label function is enabled on the LSP ingress, the ingress uses IP header
information to generate an entropy label and adds the label to the packets. The entropy label is
used as a key value by a transit node to load-balance traffic. If the length of a data frame
carried in a packet exceeds the parsing capability, the ingress fails to parse the IP header or
generate an entropy label. Perform the following steps on the LSP ingress:
Procedure
Step 2 Run load-balance identify entropy-label
The LSP ingress is enabled to deeply parse IP packets.
Step 3 Run commit
----End
3.31.2 Enabling the Entropy Label Capability on the Egress of an

LSP
The entropy label capability can be configured on the egress of an LSP to load-balance traffic.
Context
The growth of user networks worsens the load imbalance on transit nodes. To address this
problem, the entropy label capability can be configured. When the entropy label capability is
configured, it must be enabled also on the egress.
Procedure
Step 2 Run mpls
Step 3 Run entropy-label-capability enable
The entropy label capability is configured on the egress of an LSP
Step 4 Run commit
----End
3.31.3 Configuring the Entropy Label for Global Tunnels

The entropy label can be configured to global tunnels to improve load balancing performance.

Context
If severe load imbalance occurs, the entropy label can be configured for global tunnels to help
transit nodes properly load-balance traffic. The entropy label capability is enabled on the
egress for tunnels. An entropy label is configured in the tunnel interface view to confirm the
tunnel entropy label requirement, and the ingress sends the requirement to the forwarding
plane for processing.
Procedure
Step 2 Run mpls
Step 3 Run mpls te
Step 4 Run mpls te entropy-label rsvp-te
The entropy label is configured for global tunnels.
Step 5 Run commit
----End
3.31.4 (Optional) Configuring an Entropy Label Capability for a

Tunnel in the Tunnel Interface View
The entropy label capability can be configured in the tunnel interface view to improve load
balancing performance.
Context
If severe load imbalance occurs, the entropy label can be configured in the tunnel interface
view to help transit nodes properly load-balance traffic. The entropy label capability is
enabled on the egress for tunnels. An entropy label is set on the ingress to confirm the tunnel
entropy label requirement, and the ingress sends the requirement to the forwarding plane for
processing. If no entropy label is configured in the tunnel interface view, the entropy label
capability is determined by the global entropy label capability.
Procedure
Step 2 Run mpls

Step 3 Run mpls te

Step 4 Run quit
Step 7 Run mpls te entropy-label
An entropy label is configured for a tunnel in the tunnel interface view.
Step 8 Run commit
----End
3.31.5 Verifying the Configuration of the Entropy Label for

Tunnels
After configuring the entropy label for tunnels, you can verify entropy label information.
Prerequisites
The entropy label has been configured for tunnels.
Procedure
l Run the display mpls te tunnel-interface command to check the tunnel entropy label
capability.
----End
Example
Run the following commands to check the previous configuration.
Run the display mpls te tunnel-interface command to view the tunnel entropy label
capability.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1

Bfd Cap : None

Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal

3.32 Configuring Static BFD for CR-LSP

By configuring static BFD for CR-LSP, you can monitor a static CR-LSP or an RSVP CR-
LSP.
Usage Scenario
BFD for CR-LSP monitors the primary and hot-standby CR-LSPs and triggers traffic
switchovers between them.
NOTE
When static BFD for CR-LSP is used and the BFD status is Up, the BFD status remains Up even after
the tunnel interface of the CR-LSP is shut down.
Before configuring static BFD for CR-LSP, configure an RSVP-TE tunnel or CR-LSP
backup.
Figure 3-17 Static BFD for CR-LSP configuration
Enable BFD globally.
Set BFD parameters on the ingress.
Set BFD parameters on the egress.
Mandatory
Optional
3.32.1 Enabling BFD Globally

BFD must be enabled globally before configurations relevant to BFD are performed.
Procedure

Step 2 Run bfd

BFD is enabled globally on the local node, and the BFD view is displayed.
Configurations relevant to BFD can be performed only after the bfd command is run globally.
Step 3 Run commit
----End
3.32.2 Setting BFD Parameters on the Ingress

This section describes how to set BFD parameters on the ingress to monitor CR-LSPs using
BFD sessions.
Procedure
Step 2 Run bfd session-name bind mpls-te interface interface-type interface-number [ te-lsp
[ backup ] ] [ one-arm-echo ]
BFD is configured to monitor the primary or backup LSP bound to a TE tunnel.
If the backup parameter is specified, the BFD session is bound to the backup CR-LSP.
Step 3 Run discriminator local discr-value
The local discriminator of the BFD session is configured.
Step 4 Run discriminator remote discr-value
The remote discriminator of the BFD session is configured.
This command cannot be run for a one-arm-echo session.
NOTE
The local discriminator of the local device and the remote discriminator of the remote device are the
same, and the remote discriminator of the local device and the local discriminator of the remote device
are the same. A discriminator inconsistency causes the BFD session to fail to be established.
Step 5 (Optional) Run min-tx-interval interval

The minimum interval at which BFD packets are sent is configured.
l Effective local interval at which BFD packets are sent = MAX { Configured local
interval at which BFD packets are sent, Configured remote interval at which BFD
packets are received }
l Effective local interval at which BFD packets are received = MAX { Configured remote
interval at which BFD packets are sent, Configured local interval at which BFD packets
are received }
l Effective local detection interval = Effective local interval at which BFD packets are
received x Configured remote detection multiplier

For example:
l The local interval at which BFD packets are sent is set to 200 ms, the local interval at
which BFD packets are received is set to 300 ms, and the local detection multiplier is set
to 4.
l The remote interval at which BFD packets are sent is set to 100 ms, the remote interval
at which BFD packets are received is set to 600 ms, and the remote detection multiplier
is set to 5.
Then,
l Effective local interval at which BFD packets are sent = MAX { 200 ms, 600 ms } = 600
ms; effective local interval at which BFD packets are received = MAX { 100 ms, 300
ms } = 300 ms; effective local detection period = 300 ms x 5 = 1500 ms
l Effective remote interval at which BFD packets are sent = MAX { 100 ms, 300 ms } =
300 ms; effective remote receiving interval = MAX { 200 ms, 600 ms } = 600 ms;
effective remote detection period = 600 ms x 4 = 2400 ms
Step 6 (Optional) Run min-rx-interval interval
The local minimum interval at which BFD packets are received is configured.
For a one-arm-echo session, run the min-echo-rx-interval interval command to configure the
minimum interval at which the local device receives BFD packets.
Step 7 (Optional) Run detect-multiplier multiplier
The local BFD detection multiplier is configured.
Step 8 Run commit
----End
3.32.3 Setting BFD Parameters on the Egress

This section describes how to set BFD parameters on the egress to monitor CR-LSPs using
BFD sessions.
Procedure
Step 2 The IP link, LSP, or TE tunnel can be used as the reverse tunnel to inform the ingress of a
fault. If there is a reverse LSP or a TE tunnel, use the reverse LSP or the TE tunnel. If no LSP
or TE tunnel is established, use an IP link as a reverse tunnel. If the configured reverse tunnel
requires BFD detection, you can configure a pair of BFD sessions for it. Run the following
commands as required:
l Configure a BFD session to monitor reverse channels.
– For an LDP LSP, run bfd session-name bind ldp-lsp peer-ip ip-address nexthop
ip-address [ interface interface-type interface-number ]
– For a CR-LSP, run bfd session-name bind mpls-te interface tunnel interface-
number te-lsp [ backup ]

– For a TE tunnel, run bfd session-name bind mpls-te interface tunnel interface-
number
For an IP link, run bfd session-name bind peer-ip ip-address [ vpn-instance vpn-name ]
[ source-ip ip-address ]
l Configure a BFD session group to monitor reverse channels.
a. Run the bfd session-name bind mpls-te interface interface-type interface-number
[ te-lsp [ backup ] ] group command to create binding information about a BFD
session group.
b. Run the sub-session discriminator local discr-value remote remote-value select-
board slot-id command to create sub-session 1 for the BFD session group.
c. Run the sub-session discriminator local discr-value remote remote-value select-
NOTE
– A BFD session group is used when two devices are connected through an Eth-Trunk link, and
the two member interfaces of the Eth-Trunk interface are located on different interfaces. That
is, a BFD session group is used for an inter-board Eth-Trunk interface.
– Two BFD sub-sessions created in a BFD session group are used to detect two inter-board Eth-
Trunk links. The status of a BFD session group depends on the status of the two BFD sub-
sessions. As long as one BFD sub-session is Up, the status of the BFD session group is Up.
When both sub-sessions are Down, the BFD session group is Down.

The local discriminator of the BFD session is set.
NOTE
A BFD session group does not need to be configured with a local discriminator. Each sub-session in a BFD
session group has its own discriminator.

The remote discriminator of the BFD session is set.
NOTE
same. The remote discriminator of the local device and the local discriminator of the remote device are
the same. A discriminator inconsistency causes the BFD session to fail to be established.
A BFD session group does not need to be configured with a remote discriminator. Each sub-session in a
BFD session group has its own discriminator.

The local minimum interval at which BFD packets are sent is configured.
If an IP link is used as a reverse tunnel, this parameter is inapplicable.
are received }

For example:
to 4.
is set to 5.
Then,
The BFD detection multiplier is configured.
Step 8 Run commit
----End
3.32.4 Verifying the Configuration of Static BFD for CR-LSP

After configuring the static BFD for CR-LSP, you can view configurations, such as the status
of the BFD sessions of Up.
Prerequisites
The static BFD for CR-LSP has been configured.
Procedure
l Run the display bfd session mpls-te interface tunnel-name te-lsp [ verbose ] command
to check information about the BFD session on the ingress.
l Run the following commands to view information about the BFD session on the egress.
– Run the display bfd session all [ for-ip | for-lsp | for-te ] [ verbose ] command to
check information about all BFD sessions.
– Run the display bfd session static [ for-ip | for-lsp | for-te ] [ verbose ] command
to check information about static BFD sessions.
– Run the display bfd session peer-ip peer-ip [ vpn-instance vpn-name ] [ verbose ]
command to check information about BFD sessions with reverse IP links.
– Run the display bfd session ldp-lsp peer-ip ip-address [ nexthop nexthop-ip
[ interface interface-type interface-number ] ] [ verbose ] command to check
information about the BFD sessions with reverse LDP LSPs.

– Run the display bfd session mpls-te interface tunnel-name te-lsp [ verbose ]
command to check information about the BFD sessions with reverse CR-LSPs.
– Run the display bfd session mpls-te interface tunnel-name [ verbose ] command
to check information about the BFD sessions with reverse TE tunnels.
l Run the following commands to view BFD session statistics.
– Run the display bfd statistics session all [ for-ip | for-lsp | for-te ] command to
check statistics about all BFD sessions.
– Run the display bfd statistics session static [ for-ip | for-lsp | for-te ] command to
check statistics about static BFD sessions.
– Run the display bfd statistics session peer-ip peer-ip [ vpn-instance vpn-name ]
command to check statistics about the BFD sessions with reverse IP links.
– Run the display bfd statistics session ldp-lsp peer-ip peer-ip [ nexthop nexthop-ip
[ interface interface-type interface-number ] ] command to check statistics about
the BFD sessions with reverse LDP LSPs.
– Run the display bfd statistics session mpls-te interface interface-type interface-
number te-lsp command to check statistics about BFD sessions with reverse CR-
LSPs.
----End
Example
After completing the configurations, run the display bfd session all command. The command
output shows that the BFD session status is Up, and the BFD session type is S_TE_LSP.
<HUAWEI> display bfd session discriminator 10
(w): State in WTR
(*): State is invalid
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
10 20 3.3.3.3 Up S_TE_LSP Tunnel10
--------------------------------------------------------------------------------
Run the display bfd statistics session all command to view statistics about all BFD sessions.
<HUAWEI> display bfd statistics session all
(w): State in WTR
--------------------------------------------------------------------------------
State : Up Name : mainlsptope2
--------------------------------------------------------------------------------
Session Type : Static
Bind Type : TE_LSP
Local/Remote Discriminator : 413/314
Received Packets : 6
Send Packets : 58
Received Bad Packets : 0
Send Bad Packets : 0
Down Count : 0
ShortBreak Count : 0
Send Lsp Ping Count : 0
Create Time : 2012-12-07 05:28:33
Last Down Time : -
Total Time From Last DOWN : ---D:--H:--M:--S
Last Up Time : 2012-12-07 05:29:58
Last Up Lasting Time : 000D:00H:02M:04S
Total Time From Create : 000D:00H:04M:04S
--------------------------------------------------------------------------------
Total Session Number : 1

3.33 Configuring Dynamic BFD for CR-LSP

Static BFD for CR-LSP can be configured to monitor an RSVP CR-LSP and protect traffic
along a CR-LSP.
Usage Scenario
Compared with static BFD, dynamically creating BFD sessions simplifies configurations and
reduces configuration errors.
Currently, dynamic BFD for CR-LSP cannot detect faults in the entire TE tunnel.
NOTE
BFD for LSP can function properly though the forward path is an LSP and the reverse path is an IP link.
The forward and reverse paths must be established over the same link. If a fault occurs, BFD cannot
identify the faulty path. Before deploying BFD, ensure that the forward and reverse paths are over the
same link so that BFD can correctly identify the faulty path.
Before configuring dynamic BFD for CR-LSP, configure an RSVP-TE tunnel.

To configure dynamic BFD for CR-LSP, enable BFD globally on the ingress node and the
egress node of a tunnel.
Context
Perform the following steps on the ingress and the egress of a TE tunnel:
Procedure
Step 2 Run bfd
BFD is enabled globally.
Step 3 Run commit
----End
3.33.2 Enabling the Capability of Dynamically Creating BFD

Sessions on the Ingress
You can enable the ingress node to dynamically create BFD sessions on a TE tunnel either
globally or on a specified tunnel interface.

Context
Perform either of the following operations:
l Enable MPLS TE BFD globally if most TE tunnels on the ingress need to dynamically
create BFD sessions.
l Enable MPLS TE BFD on a tunnel interface if some TE tunnels on the ingress need to
dynamically create BFD sessions.
Procedure
l Enable MPLS TE BFD globally on the ingress.
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 LSP is enabled
on all tunnel interfaces, excluding the interfaces on which dynamic BFD for TE
LSP is 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 LSP.
i. Run interface tunnel interface-number
ii. Run mpls te bfd block
The capability of dynamically creating BFD sessions on the tunnel interface is
blocked.
e. Run commit
l Enable MPLS TE BFD on a tunnel interface of the ingress.
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.
d. Run commit
----End

3.33.3 Enabling the Capability of Passively Creating BFD Sessions

on the Egress
On a unidirectional LSP, creating a BFD session on the ingress playing the active role triggers
the sending of LSP ping request messages to the egress node playing the passive role. Only
after the passive role receives the ping packets, a BFD session can be automatically
established.
Context
Perform the following steps on the egress:
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 message containing the BFD TLV from the ingress.
Step 4 Run commit
----End
3.33.4 (Optional) Adjusting BFD Parameters

BFD parameters are adjusted on the ingress of a tunnel either globally or on a tunnel interface.
Context
l Adjust global BFD parameters if a majority of TE tunnels on the ingress use the same
BFD parameters.
l Adjust BFD parameters on an interface if someTE tunnels on the ingress need BFD
parameters different from global BFD parameters.

NOTE
l Effective local interval at which BFD packets are sent = MAX { Configured local interval at which
BFD packets are sent, Configured remote interval at which BFD packets are received }
l Effective local interval at which BFD packets are received = MAX { Configured remote interval at
which BFD packets are sent, Configured local interval at which BFD packets are received }
l Effective local detection interval = Effective local interval at which BFD packets are received x
Configured remote detection multiplier
On the egress of the TE tunnel enabled with the capability of passively creating BFD sessions, the
default values of the receiving interval, the sending interval, and the detection multiplier cannot be
adjusted. The default values of these three parameters are the configured minimum values on the ingress.
Therefore, the BFD detection interval on the ingress and that on the egress of a TE tunnel are as follows:
l Effective detection interval on the ingress = Configured interval at which BFD packets are received
on the ingress x 3
l Effective detection interval on the egress = Configured local interval at which BFD packets are sent
on the ingress x Configured detection multiplier on the ingress
Procedure
l Adjust global BFD parameters on the ingress of a TE tunnel.
a. Run system-view
b. Run mpls
c. Run mpls te bfd { min-tx-interval tx-interval | min-rx-interval tx-interval |
detect-multiplier multiplier }*
BFD time parameters are adjusted globally.
d. Run commit
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.
d. Run commit
----End
3.33.5 Verifying the Configuration of Dynamic BFD for CR-LSP

After configuring dynamic BFD for CR-LSP, you can verify that a CR-LSP is Up and a BFD
session is successfully established.

Procedure
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-ipremote-discriminator
discriminator ] [ 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 [ protocol rsvp-te | outgoing-interface interface-type
interface-number ] [ verbose ] command to check information about the MPLS BFD
session.
----End
Example
Run the display bfd session all verbose command on the ingress. The status of the BFD
sessions is Up, and the links bound to the sessions are TE LSPs.
<HUAWEI> display bfd session dynamic verbose
(w): State in WTR
--------------------------------------------------------------------------------
State : Up Name : dyn_16385
--------------------------------------------------------------------------------
Local Discriminator : 16385 Remote Discriminator : 16385
Session Detect Mode : Asynchronous Mode Without Echo Function
BFD Bind Type : TE_LSP
Bind Session Type : Dynamic
Bind Peer IP Address : 3.3.3.3
NextHop Ip Address : 172.16.12.2
Bind Interface : Tunnel3 TE LSP Type : Primary
Tunnel ID : 33
FSM Board Id : 3 TOS-EXP : 7
Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10
Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10
Local Detect Multi : 3 Detect Interval (ms) : 30
Echo Passive : Disable Acl Number : -
Destination Port : 3784 TTL : 1
Proc Interface Status : Disable Process PST : Enable
WTR Interval (ms) : - Config PST : Enable
Active Multi : 3
Last Local Diagnostic : No Diagnostic
Bind Application : TE
Session TX TmrID : - Session Detect TmrID : -
Session Init TmrID : - Session WTR TmrID : -
Session Echo Tx TmrID : -
Session Description : -
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
Run the display bfd session passive-dynamic verbose command on the egress. The BFD
session created on the egress is a multi-hop BFD session bound to the peer IP address.
<HUAWEI> display bfd session passive-dynamic verbose
(w): State in WTR
--------------------------------------------------------------------------------
(Multi Hop) State : Up Name : dyn_16385
--------------------------------------------------------------------------------


BFD Bind Type : Peer IP Address
Bind Session Type : Entire_Dynamic
Bind Peer IP Address : 1.1.1.1
Bind Interface : -
Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10
Local Detect Multi : 3 Detect Interval (ms) : 30
Echo Passive : Disable Acl Number : -
Proc Interface Status : Disable Process PST : Disable
WTR Interval (ms) : - Config PST : Disable
Active Multi : 3
Last Local Diagnostic : No Diagnostic
Bind Application : No Application Bind
Session TX TmrID : - Session Detect TmrID : -
Session Init TmrID : - Session WTR TmrID : -
Session Echo Tx TmrID : -
--------------------------------------------------------------------------------
3.34 Configuring Static BFD for TE

This section describes how to configure static BFD for TE to detect faults in a TE tunnel.
Usage Scenario
If a BFD session detects a fault in a TE tunnel, the BFD module instructs VPN FRR to
quickly switch traffic, which reduces the adverse impact on services.
Before configuring the static BFD for TE, configure a static CR-LSP or an MPLS TE tunnel.
Figure 3-18 Static BFD for TE configuration
Enable BFD globally.
Set BFD parameters on the ingress.
Set BFD parameters on the egress.
Mandatory
Optional


BFD must be enabled globally before configurations relevant to BFD are performed.
Procedure
Step 2 Run bfd
BFD is enabled globally on the local node, and the BFD view is displayed.
Configurations relevant to BFD can be performed only after the bfd command is run globally.
Step 3 Run commit
----End
3.34.2 Setting BFD Parameters on the Ingress

After setting BFD parameters on the ingress, you can use BFD sessions to monitor a TE
tunnel.
Procedure
Step 2 Run bfd session-name bind mpls-te interface interface-type interface-number [ one-arm-
echo ]
BFD is configured to monitor a TE tunnel.
When the TE tunnel is in the Down state, a BFD session cannot be established.
NOTE

The local minimum interval at which BFD packets are sent is set.

are received }
For example:
to 4.
is set to 5.
Then,
The local minimum interval at which BFD packets are received is set.
For a one-arm-echo session, run the min-echo-rx-interval interval command to configure the
minimum interval at which the local device receives BFD packets.
The BFD detection multiplier is set.
Step 8 Run commit
----End
3.34.3 Setting BFD Parameters on the Egress

This section describes how to set BFD parameters on the egress to monitor CR-LSPs using
BFD sessions.
Procedure

Step 2 The IP link, LSP, or TE tunnel can be used as the reverse tunnel to inform the ingress of a
fault. If there is a reverse LSP or a TE tunnel, use the reverse LSP or the TE tunnel. If no LSP
or TE tunnel is established, use an IP link as a reverse tunnel. If the configured reverse tunnel
requires BFD detection, you can configure a pair of BFD sessions for it. Run the following
commands as required:
l Configure a BFD session to monitor reverse channels.
– For an LDP LSP, run bfd session-name bind ldp-lsp peer-ip ip-address nexthop
ip-address [ interface interface-type interface-number ]
– For a CR-LSP, run bfd session-name bind mpls-te interface tunnel interface-
number te-lsp [ backup ]
– For a TE tunnel, run bfd session-name bind mpls-te interface tunnel interface-
number
For an IP link, run bfd session-name bind peer-ip ip-address [ vpn-instance vpn-name ]
[ source-ip ip-address ]
l Configure a BFD session group to monitor reverse channels.
a. Run the bfd session-name bind mpls-te interface interface-type interface-number
[ te-lsp [ backup ] ] group command to create binding information about a BFD
session group.
b. Run the sub-session discriminator local discr-value remote remote-value select-
c. Run the sub-session discriminator local discr-value remote remote-value select-
NOTE
– A BFD session group is used when two devices are connected through an Eth-Trunk link, and
the two member interfaces of the Eth-Trunk interface are located on different interfaces. That
is, a BFD session group is used for an inter-board Eth-Trunk interface.
– Two BFD sub-sessions created in a BFD session group are used to detect two inter-board Eth-
Trunk links. The status of a BFD session group depends on the status of the two BFD sub-
sessions. As long as one BFD sub-session is Up, the status of the BFD session group is Up.
When both sub-sessions are Down, the BFD session group is Down.

NOTE
A BFD session group does not need to be configured with a local discriminator. Each sub-session in a BFD
session group has its own discriminator.

NOTE
A BFD session group does not need to be configured with a remote discriminator. Each sub-session in a
BFD session group has its own discriminator.

The local minimum interval at which BFD packets are sent is configured.

If an IP link is used as a reverse tunnel, this parameter is inapplicable.
are received }
For example:
to 4.
is set to 5.
Then,
The BFD detection multiplier is configured.
Step 8 Run commit
----End
3.34.4 Verifying the Configuration of Static BFD for TE

After configuring static BFD for TE, you can view configurations, such as the status of the
BFD sessions.
Prerequisites
Static BFD for TE has been configured.
Procedure
l Run the display bfd session mpls-te interface tunnel-name [ verbose ] command to
check information about BFD sessions on the ingress.

l Run the following commands to check information about BFD sessions on the egress.
– Run the display bfd session all [ for-ip | for-lsp | for-te ] [ verbose ] command to
check information about all BFD sessions.
– Run the display bfd session static [ for-ip | for-lsp | for-te ] [ verbose ] command
to check information about static BFD sessions.
– Run the display bfd session peer-ip peer-ip [ vpn-instance vpn-name ] [ verbose ]
command to check information about BFD sessions with reverse IP links.
– Run the display bfd session ldp-lsp peer-ip peer-ip [ nexthop nexthop-ip
[ interface interface-type interface-number ] ] [ verbose ] command to check
information about BFD sessions with reverse LDP LSPs.
– Run the display bfd session mpls-te interface tunnel-name te-lsp [ verbose ]
command to check information about BFD sessions with reverse CR-LSPs.
– Run the display bfd session mpls-te interface tunnel-name [ verbose ] command
to check information about BFD sessions with reverse TE tunnels.
– Run the display bfd group session command to check the information about the
sessions and sub-sessions of BFD session groups with reverse TE tunnels or CR-
LSPs.
l Run the following commands to check BFD statistics.
– Run the display bfd statistics session all [ for-ip | for-lsp | for-te ] command to
check statistics about all BFD sessions.
– Run the display bfd statistics session static [ for-ip | for-lsp | for-te ] command to
check statistics about static BFD sessions.
– Run the display bfd statistics session peer-ip peer-ip [ vpn-instance vpn-name ]
command to check statistics about BFD sessions with reverse IP links.
– Run the display bfd statistics session ldp-lsp peer-ip peer-ip [ nexthop nexthop-ip
[ interface interface-type interface-number ] ] command to check statistics about
BFD sessions with reverse LDP LSPs.
– Run the display bfd statistics session mpls-te interface interface-type interface-
number te-lsp command to check statistics about BFD sessions with reverse CR-
LSPs.
----End
Example
After completing the configurations, run the display bfd session command. The command
output shows that the BFD session status is Up, and the BFD session type is S_TE_TNL.
<HUAWEI> display bfd session discriminator 10
(w): State in WTR
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
10 20 3.3.3.3 UpS_TE_TNL Tunnel10
--------------------------------------------------------------------------------
Run the display bfd statistics session all command to view statistics about all BFD sessions.
<HUAWEI> display bfd statistics session all
(w): State in WTR
------------------------------------------------------------------------------
State : Up Name : atob

------------------------------------------------------------------------------
Session Type : Static
Bind Type : TE_LSP
Local/Remote Discriminator : 10/20
Received Packets : 1710577
Sent Packets : 1710593
Received Bad Packets : 0
Sent Failed Packets : 0
Down Count : 0
ShortBreak Count : 0
Sent Lsp Ping Count : 0
Create Time : 2012-11-17 12:11:03
Last Down Time : 0000/00/00 00:00:00
Down Status Lasting Time : -D:--H:--M:--S
Last Up Time : 2012-11-17 21:14:50
Last Up Lasting Time : ---D:--H:--M:--S
Total Time From Create : 0D:09H:03M:47S
--------------------------------------------------------------------------------
Total Session Number : 1
3.35 Configuring BFD for P2MP TE

BFD for P2MP TE rapidly monitors P2MP TE tunnels, which helps speed up responses to
faults and improve network reliability.
Usage Scenario
If P2MP TE tunnels are established to transmit NG MVPN and multicast VPLS services,
BFD for P2MP TE can be configured to rapidly detect faults in P2MP TE tunnels, which
improves network reliability. To configure BFD for P2MP TE, run the bfd enable command
in the P2MP tunnel template view so that BFD sessions for P2MP TE can be automatically
established while P2MP TE tunnels are being established.
Context
Before configuring BFD for P2MP TE, configure an automatic P2MP TE tunnel.
Procedure
Step 1 Configure the ingress.
1. Run system-view

2. Run bfd
BFD is enabled.
3. Run quit

4. Run mpls te p2mp-template template-name
A P2MP tunnel template is created, and the P2MP tunnel template view is displayed.
5. Run bfd enable
BFD for P2MP TE is enabled.

6. (Optional) Run bfd { min-tx-interval tx-interval | min-rx-interval rx-interval | detect-

multiplier multiplier } *
BFD for P2MP TE parameters are set.

7. Run commit
Step 2 Configure each leaf node.

1. Run system-view

2. Run bfd
BFD is enabled, and the BFD view is displayed.

3. Run mpls-passive
The egress is enabled to create a BFD session passively.
The egress has to receive an LSP ping request carrying a BFD TLV before creating a
BFD session.
4. Run commit
----End

l Run the display bfd multicast session { all | p2mp-te [ p2mp-id p2mp-id ingress-lsr-id
tunnel-id tunnel-id ] } command to check BFD for P2MP TE session information.
<HUAWEI> display bfd multicast session p2mp-te
--------------------------------------------------------------------------------
(Multi Hop) State : Up Name : dyn_16385
--------------------------------------------------------------------------------
BFD Bind Type : P2MP_TE_TUNNEL
Bind Session Type : Dynamic
Bind Peer IP Address : -.-.-.-
Track Interface : -
MultiSessType : MultiHead P2MP ID : 33686018
Tunnel ID : 32769 Ingress LSR ID : 2.2.2.2
Actual Tx Interval (ms): 200 Actual Rx Interval (ms): -
Local Detect Multi : 3 Detect Interval (ms) : -
Active Multi : -
Last Local Diagnostic : Administratively Down
Bind Application : TE
--------------------------------------------------------------------------------
3.36 Configuring Dynamic BFD for RSVP

This section describes how to configure a dynamic BFD session to detect faults in links
between RSVP neighbors.

Usage Scenario
BFD for RSVP is used with TE FRR when a Layer 2 device exists on the primary LSP
between a PLR and its downstream RSVP neighbor.
The interval at which a neighbor is declared Down is three times as long as the interval at
which RSVP Hello messages are sent. This allows devices to detect a fault in an RSVP
neighbor in seconds.
If a Layer 2 device exists on a link between RSVP nodes, an RSVP node cannot rapidly detect
a link fault, which results in a great loss of data.
BFD rapidly detects faults in links or nodes on which RSVP adjacencies are deployed. If BFD
detects a fault, it notifies the RSVP module of the fault and instructs the RSVP module to
switch traffic to a bypass tunnel.
Before you configure BFD for RSVP, configure an RSVP-TE tunnel.

To configure dynamic BFD for RSVP, you must enable BFD on both ends of RSVP
neighbors.
Context
Perform the following steps on the two RSVP neighboring nodes between which a Layer 2
device resides:
Procedure
Step 2 Run bfd
BFD is enabled globally.
Step 3 Run commit
----End
3.36.2 Enabling BFD for RSVP

You can enable BFD for RSVP either globally or on a specified interface.
Context

l Enable BFD for RSVP globally if most RSVP interfaces on a node need BFD for
RSVP.
l Enable BFD for RSVP on an RSVP interface if some RSVP interfaces on a node need
BFD for RSVP.
Procedure
l Enable BFD for RSVP globally.
Perform the following steps on the two RSVP neighboring nodes between which a Layer
2 device resides:
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) Block BFD for RSVP on the RSVP interfaces that do not need BFD for
RSVP.
i. Run interface interface-type interface-number
The view of the RSVP-TE-enabled interface is displayed.
ii. Run mpls rsvp-te bfd block
BFD for RSVP is blocked on the interface.
e. Run commit

l Enable BFD for RSVP on the RSVP interface.
2 device resides:
a. Run system-view


c. Run mpls rsvp-te bfd enable
BFD for RSVP is enabled on the RSVP interface.

d. Run commit
----End

3.36.3 (Optional) Adjusting BFD Parameters

BFD parameters can be adjusted either globally or on a specific RSVP interface after BFD for
RSVP is configured.
Context
l Adjust global BFD parameters if most RSVP interfaces on a node use the same BFD
parameters
.
l Adjust BFD parameters on an RSVP interface if some RSVP interfaces require BFD
parameters different from global BFD parameters.
Procedure
l Adjust global BFD parameters globally.
2 device resides:
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.
NOTE
Parameters are described as follows:

l tx-interval is the Desired Min Tx Interval (DMTI). It specifies the desired minimum
interval at which BFD control packets are sent.
l rx-interval is the Required Min Rx Interval (RMRI). It specifies the supported
minimum interval at which BFD control packets are received.
l multiplier is the BFD detection multiplier.
BFD detection parameters that take effect on the local node may be different from the
configured parameters:
l Effective local interval at which BFD packets are received = MAX { Configured
remote interval at which BFD packets are sent, Configured local interval at which
BFD packets are received }
d. Run commit

l Adjust BFD parameters on an RSVP interface.

2 device resides:
a. Run system-view
c. Run mpls rsvp-te bfd { min-tx-interval tx-interval | min-rx-interval rx-interval |
BFD parameters on the RSVP interface are adjusted.
d. Run commit
----End
3.36.4 Verifying the Configuration of Dynamic BFD for RSVP

After configuring dynamic BFD for RSVP, you can view the status of a BFD session for
RSVP.
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 interface [ interface-type interface-number ] command to
view BFD for RSVP configurations on a specific interface.
----End
Example
Run the display mpls rsvp-te bfd session { all | interface interface-type interface-number |
peer ip-address } [ verbose ] command to view BFD for RSVP status. The command output
shows that the BFD session status is UP.
<HUAWEI> display mpls rsvp-te bfd session all
Total Nbrs/Rsvp triggered sessions : 3/1
-------------------------------------------------------------------------------
Local Remote Local Peer Interface Session
Discr Discr Addr Addr Name State
-------------------------------------------------------------------------------
16385 16385 10.2.1.1 10.2.1.2 GE3/0/0 UP
3.37 Maintaining MPLS TE

This section describes how to delete MPLS TE information and debug MPLS TE.
3.37.1 Checking Connectivity of a TE Tunnel

The connectivity of a TE tunnel between the ingress and egress is checked.

Context
After configuring an MPLS TE tunnel, you can run the ping lsp command on the ingress of
the TE tunnel to verify that the ping from the ingress to the egress is successful. If the ping
fails, run the tracert lsp command to locate the fault.
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 tunnel-number [ hot-standby ]
[ compatible-mode ]command to check the connectivity of a TE tunnel from the ingress
to the egress.
If hot-standby is configured, a hot-standby CR-LSP is checked.
l Run the tracert lsp [ -a source-ip | -exp exp-value | -h ttl-value | -r reply-mode | -t time-
out | -s size ] * te tunnel tunnel-number [ hot-standby ] [ compatible-mode ]
[detail ]command to check the nodes through which data packets pass along a TE tunnel
from the ingress to the egress.
If hot-standby is configured, a hot-standby CR-LSP is checked.
----End
3.37.2 Checking a TE Tunnel Using NQA

After configuring MPLS TE, you can use Network Quality Analysis (NQA) to check the
connectivity and jitters of a TE tunnel.
Context
For information about configurations for monitoring a TE tunnel using NQA, see "NQA
Configuration" in HUAWEI NetEngine40E Universal Service Router Configuration Guide -
System Management.
3.37.3 Checking Tunnel Error Information

If an RSVP-TE tunnel interface is Down, run display commands to view information about
faults.
Context
Run the display mpls te tunnel-interface last-error command on the ingress to view the last
five recorded errors that occurred on a TE tunnel. The following errors may occur:
l CSPF computation failures
l Errors that occurred when RSVP signaling was triggered
l Errors carried in received RSVP PathErr messages
Procedure
Step 1 Run the display mpls te tunnel-interface last-error [ tunnel-name ] command to check error
information on a tunnel interface.
----End

3.37.4 Deleting RSVP-TE Statistics

A reset command is used to delete RSVP-TE statistics.
Context
RSVP-TE statistics are deleted if you reset RSVP-TE statistics using the reset command.
Exercise caution when running the reset command.
To delete RSVP-TE statistics, run the reset command in the user view.
Procedure
Step 1 Run the reset mpls rsvp-te statistics { global | interface [ interface-type interface-
number ] } command in the user view to delete RSVP-TE statistics.
----End
3.37.5 Delete the traffic statistics of MPLS TE automatic tunnels

Delete the traffic statistics of MPLS TE automatic tunnels.
Context
After deleting the traffic statistics of the MPLS TE automatic tunnel.Exercise caution when
running the reset command.
After deleting the traffic statistics of the MPLS TE automatic tunnel,run the reset command
in the user view.
Procedure
Step 1 Run thereset mpls rsvp-te statistics tunnel-namecommand in the user view to delete the
traffic statistics of MPLS TE automatic tunnels.
----End
3.37.6 Resetting the RSVP Process

Resetting the RSVP process triggers a node to re-establish all RSVP CR-LSPs or verify the
RSVP process.

Context
Resetting the RSVP process causes all RSVP CR-LSPs to be torn down and re-established.
Procedure
Step 1 Run the reset mpls rsvp-te command in the user view to reset the RSVP process.
----End
3.37.7 Deleting an Automatic Bypass Tunnel and Re-establishing

a New One
If MPLS TE Auto FRR is enabled, a command is used to instruct a node to tear down an
automatic bypass tunnel and reestablish a new one.
Procedure
Step 1 Run the reset mpls te auto-frr { lsp-id ingress-lsrid tunnel-id | name bypass-tunnel-name }
command to tear down an automatic bypass tunnel and re-establish a new one.
----End
3.37.8 Deleting PCEP Session Statistics

PCEP session statistics can be deleted manually.
Prerequisites
Before you collect PCEP session statistics, run the reset pce protocol statistics command to
delete existing statistics and run the display pce protocol statistics command to view latest
PCEP session statistics.
Procedure
l Run the reset pce protocol statistics { ip-address | all } command to delete PCEP
session statistics.
----End
3.37.9 Loopback Detection for a Specified Static Bidirectional Co-

Routed CR-LSP
Loopback detection for a specified static bidirectional co-routed CR-LSP locates faults if a
few packets are dropped or bit errors occur on links along the CR-LSP.
Context
On a network with a static bidirectional co-routed CR-LSP used to transmit services, if a few
packets are dropped or bit errors occur on links, no alarms indicating link or LSP failures are

generated, which poses difficulties in locating the faults. To locate the faults, loopback
detection can be enabled for the static bidirectional co-routed CR-LSP.
Procedure
Step 1 (Optional) In the MPLS view, run lsp-loopback autoclear period period-value
The timeout period is set, after which loopback detection for a static bidirectional co-routed
LSP is automatically disabled.
Step 2 In the specified static bidirectional LSP transit view, run:

lsp-loopback start
Loopback detection is enabled for the specified static bidirectional co-routed CR-LSP.
Loopback detection enables a transit node on the CR-LSP to loop traffic back to the ingress.
A professional monitoring device connected to the ingress monitors data packets that the
ingress sends and receives and checks whether a fault occurs on the link between the ingress
and transit node. Figure 3-19illustrates the network on which loopback is enabled to monitor
a static bidirectional co-routed CR-LSP.
Figure 3-19 Loopback detection for a static bidirectional co-routed CR-LSP
PE1 P1 P2 PE2
(Ingress) (Transit) (Transit) (Egress)
Loopback
detection Loopback
detection
Static bidirectional
co-routed LSP
During loopback detection, a loop occurs, which adversely affects service transmission. After
loopback detection is complete, immediately run the lsp-loopback stop command to disable
loopback detection. If you do not manually disable loopback detection, loopback detection
will be automatically disabled after the specified timeout period elapses.
Step 3 Perform one of the following operations to check the loopback status on a transit node:
l Run the display mpls te bidirectional command.
l View the MPLS_LSPM_1.3.6.1.4.1.2011.5.25.121.2.1.75 hwMplsLspLoopBack alarm
that is generated after loopback detection is started.
l View the MPLS_LSPM_1.3.6.1.4.1.2011.5.25.121.2.1.76 hwMplsLspLoopBackClear
alarm that is generated after loopback detection is stopped.
----End

3.37.10 Enabling the Packet Loss-Free MPLS ECMP Switchback

The packet loss-free MPLS ECMP switchback can be enabled.
Context
In an L3VPN over BGP over TE or IP over BGP over TE scenario, after an MPLS TE tunnel
is configured, the mpls load-balance wtr command is run in the system view to prevent
packet loss during an MPLS ECMP switchback and set a switchback WTR time.
Procedure
Step 2 Run mpls load-balance wtr wtr-value
The packet loss-free MPLS ECMP switchback is enabled, and a switchback WTR time is set.
----End
3.38 Configuration Examples for MPLS TE

This section provides MPLS TE configuration examples.
3.38.1 Example for Establishing a Static MPLS TE Tunnel

This section provides an example for configuring a static MPLS TE tunnel, which involves
enabling MPLS TE, configuring the MPLS TE bandwidth, setting up an MPLS TE tunnel,
and setting up a static CR-LSP.
Networking Requirements
On the carrier network shown in Figure 3-20, some devices have low routing and processing
performance. The carrier hopes to use an MPLS TE tunnel to transmit services. To meet this
requirement, two static TE tunnels between LSRA and LSRC can be established to transmit
traffic in opposite directions. A static TE tunnel is manually established, without using a
dynamic signaling protocol or IGP routes, which consumes a few device resources and has
low requirement on device performance.
Figure 3-20 Networking diagram for static CR-LSP configuration

NOTE
Interfaces 1 through 2 in this example are GE 1/0/0, GE 2/0/0, respectively.
Loopback1 Loopback1 Loopback1

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
interface1 interface1 interface2 interface2
2.1.1.1/24 2.1.1.2/24 3.2.1.1/24 3.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, configure a loopback address as an
MPLS LSR ID, and configure OSPF to advertise the route to the network segment
connecting to each interface and LSR ID.
2. Configure the LSR ID and globally enable MPLS and MPLS TE on each node and
interface.
3. Configure the maximum reservable bandwidth and BC0 bandwidth for the link on each
outgoing interface of each LSR along the tunnel. (The tunnel obtains bandwidth from
BC0).
4. Create a tunnel interface on the ingress and specify the IP address of the tunnel, tunnel
protocol, destination address, tunnel ID, and the signaling protocol used to establish the
tunnel.
5. Configure a static CR-LSP associated with the tunnel and specify the following
parameters on each type of node:
– Ingress: outgoing label and next-hop address
– Transit node: inbound interface name, next-hop address, and outgoing label
– Egress: incoming label and inbound interface name
NOTE
l The outgoing label of each node is the incoming label of the 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 [ bandwidth [ ct0 ] bandwidth ] command to configure the
ingress of a CR-LSP, note that tunnel-name must be the same as the tunnel name created using the
interface tunnel interface -number command. tunnel-name is a case-sensitive character string with
no spaces. For example, the name of the tunnel created by using the interface Tunnel 20 command
is Tunnel20. In this case, the parameter of the static CR-LSP on the ingress is Tunnel20. This
restriction does not apply to transit nodes or egresses.
Data Preparation
To complete the configuration, you need the following data:
l OSPF process ID and area ID of each LSR
l Tunnel interface names, tunnel interface IP addresses, destination addresses, tunnel IDs,
and tunnel signaling protocol (CR-Static) on LSRA and LSRC
l The maximum reservable bandwidth and BC bandwidth for links
l Next-hop address and outgoing label of the ingress on the static CR-LSP
l Inbound interface name, next-hop address, and outgoing label of the transit node on the
static CR-LSP
l Inbound interface name of the egress on the static CR-LSP
Procedure
Step 1 Assign the IP address to each interface and configure a routing protocol.
# Assign the IP address to each interface and configure the routing protocol using the
information in Figure 3-20 to implement reachability between LSRs.

For configuration details, see Configuration Files in this section.

Step 2 Configure the basic MPLS functions and enable MPLS TE.
# Configure LSRA.
[~LSRA] mpls lsr-id 1.1.1.1
[*LSRA] mpls
[*LSRA-mpls] mpls te
[*LSRA-mpls] quit
[*LSRA] interface gigabitethernet 1/0/0
[*LSRA-GigabitEthernet1/0/0] mpls
[*LSRA-GigabitEthernet1/0/0] mpls te
[*LSRA-GigabitEthernet1/0/0] commit
[~LSRA-GigabitEthernet1/0/0] quit
Repeat this step for LSRB and LSRC. For configuration details, see Configuration Files in
this section.
Step 3 Configure MPLS-TE bandwidth attributes for links.
# Configure the maximum reservable link bandwidth and BC0 bandwidth on each outbound
interface of each LSR along the tunnel. The BC0 bandwidth for links must be greater than the
tunnel bandwidth (10 Mbit/s).
# Configure LSRA.
[~LSRA] interface gigabitethernet 1/0/0
[~LSRA-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*LSRA-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
# Configure LSRB.
[~LSRB] interface gigabitethernet 1/0/0
[~LSRB-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*LSRB-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
[*LSRB-GigabitEthernet1/0/0] quit
[*LSRB] interface gigabitethernet 2/0/0
[*LSRB-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*LSRB-GigabitEthernet2/0/0] commit
[~LSRB-GigabitEthernet2/0/0] quit
# Configure LSRC.
[~LSRC] interface gigabitethernet 2/0/0
[~LSRC-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*LSRC-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000
[*LSRC-GigabitEthernet2/0/0] commit
[~LSRC-GigabitEthernet2/0/0] quit
Step 4 Configure an MPLS TE tunnel.

# Create the MPLS TE tunnel from LSRA to LSRC on LSRA.
[~LSRA] interface Tunnel 10
[*LSRA-Tunnel10] ip address unnumbered interface loopback 1
[*LSRA-Tunnel10] tunnel-protocol mpls te
[*LSRA-Tunnel10] destination 3.3.3.3
[*LSRA-Tunnel10] mpls te tunnel-id 100
[*LSRA-Tunnel10] mpls te signal-protocol cr-static
[*LSRA-Tunnel10] commit
[~LSRA-Tunnel10] quit
# Create the MPLS TE tunnel from LSRC to LSRA on LSRC.

[~LSRC] interface Tunnel 20

[*LSRC-Tunnel20] ip address unnumbered interface loopback 1

[*LSRC-Tunnel20] tunnel-protocol mpls te
[*LSRC-Tunnel20] destination 1.1.1.1
[*LSRC-Tunnel20] mpls te tunnel-id 200
[*LSRC-Tunnel20] mpls te signal-protocol cr-static
[*LSRC-Tunnel20] commit
[~LSRC-Tunnel20] quit
Step 5 Create a static CR-LSP from LSRA to LSRC.
# Configure LSRA as the ingress of the static CR-LSP.

[~LSRA] static-cr-lsp ingress tunnel-interface Tunnel 10 destination 3.3.3.3
nexthop 2.1.1.2 out-label 20 bandwidth ct0 10000
[*LSRA] commit
# Configure LSRB as the transit node of the static CR-LSP.

[~LSRB] static-cr-lsp transit Tunnel10 incoming-interface gigabitethernet 1/0/0
in-label 20 nexthop 3.2.1.2 out-label 30 bandwidth ct0 10000
[*LSRB] commit
# Configure LSRC as the egress of the static CR-LSP.

[~LSRC] static-cr-lsp egress Tunnel10 incoming-interface gigabitethernet 2/0/0 in-
label 30
[*LSRC] commit
Step 6 Create a static CR-LSP from LSRC to LSRA.
# Configure LSRC as the ingress of the static CR-LSP.

[~LSRC] static-cr-lsp ingress tunnel-interface Tunnel 20 destination 1.1.1.1
nexthop 3.2.1.1 out-label 120 bandwidth ct0 10000
[*LSRC] commit
# Configure LSRB as the transit node of the static CR-LSP.

[~LSRB] static-cr-lsp transit Tunnel20 incoming-interface gigabitethernet 2/0/0
in-label 120 nexthop 2.1.1.1 out-label 130 bandwidth ct0 10000
[*LSRB] commit
# Configure LSRA as the egress of the static CR-LSP.

[~LSRA] static-cr-lsp egress Tunnel20 incoming-interface gigabitethernet 1/0/0 in-
label 130
[*LSRA] commit
Step 7 Verify the configuration.
After completing the configuration, run the display interface tunnel command on LSRA.
The command output shows that the status of the tunnel interface is Up.
Run the display mpls te tunnel command on each LSR to view the establishment status of
the MPLS TE tunnel.
[~LSRA] display mpls te tunnel
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 1 --/20 I Tunnel10
- - - 130/-- E Tunnel20
[~LSRB] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------

- - - 20/30 T Tunnel10
- - - 120/130 T Tunnel20
[~LSRC] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
- - - 30/-- E Tunnel10
3.3.3.3 1.1.1.1 1 --/120 I Tunnel20
Run the display mpls lsp or display mpls static-cr-lsp command on each LSR to view the
establishment status of the static CR-LSP.
# Display the configuration on LSRA.
[~LSRA] display mpls static-cr-lsp
Tunnel10 3.3.3.3/32 NULL/20 -/GE1/0/0 Up
Tunnel20 -/- 130/NULL GE1/0/0/- Up
# Display the configuration on LSRB.

[~LSRB] display mpls static-cr-lsp
Tunnel10 -/- 20/30 GE1/0/0/GE2/0/0 Up
Tunnel20 -/- 120/130 GE2/0/0/GE1/0/0 Up
# Display the configuration on LSRC.

[~LSRC] display mpls static-cr-lsp
Tunnel20 1.1.1.1/32 NULL/120 -/GE2/0/0 Up
Tunnel10 -/- 30/NULL GE2/0/0/- Up
When the static CR-LSP is used to establish the MPLS TE tunnel, the packets on the transit
node and the egress are forwarded directly based on the specified incoming and outgoing
labels. Therefore, no FEC information is displayed on LSRB or LSRC.
----End
Configuration Files
l LSRA configuration file
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
static-cr-lsp ingress tunnel-interface Tunnel10 destination 3.3.3.3 nexthop
2.1.1.2 out-label 20 bandwidth ct0 10000
#
static-cr-lsp egress Tunnel20 incoming-interface GigabitEthernet1/0/0 in-
label 130
#
interface GigabitEthernet1/0/0

undo shutdown
ip address 2.1.1.1 255.255.255.0
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 100000
mpls te bandwidth bc0 100000
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel10
ip address unnumbered interface LoopBack1
destination 3.3.3.3
mpls te signal-protocol cr-static
mpls te tunnel-id 100
#
return
l LSRB configuration file
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
static-cr-lsp transit Tunnel10 incoming-interface GigabitEthernet1/0/0 in-
label 20 nexthop 3.2.1.2 out-label 30 bandwidth ct0 10000
#
#
undo shutdown
ip address 3.2.1.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
return
l LSRC configuration file
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
#
label 30
#

undo shutdown
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Tunnel20
destination 1.1.1.1
#
return
3.38.2 Example for Configuring a Static Bidirectional Co-routed

CR-LSP
This section provides an example for configuring a static bidirectional co-routed CR-LSP,
including how to enable MPLS TE, configure MPLS TE bandwidth attributes, and configure
an MPLS TE tunnel.
Usage Scenario
Static bidirectional co-routed CR-LSPs are used to establish static bidirectional tunnel for
services on an MPLS network.
On a network shown in Figure 3-21, a static bidirectional co-routed CR-LSP originates from
LSRA and terminates on LSRC. The links for the static bidirectional co-routed CR-LSP
between LSRA and LSRC has 10 Mbit/s bandwidth.
Figure 3-21 Networking diagram for a static bidirectional co-routed CR-LSP

NOTE

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
2.1.1.1/24 2.1.1.2/24 3.2.1.1/24 3.2.1.2/24
LSRA LSRB LSRC
1. Assign an IP address to each interface and configure a routing protocol.

2. Configure basic MPLS functions and enable MPLS TE.

3. Configure MPLS TE attributes for links.

4. Configure MPLS TE tunnels.
5. Configure the ingress, a transit node, and the egress for the static bidirectional co-routed
CR-LSP.
6. Bind the tunnel interface configured on LSRC to the static bidirectional co-routed CR-
LSP.
Data Preparation
l Tunnel interface's name and IP address, destination address, tunnel ID, and static CR-
LSP signaling on LSRA and LSRC
l Maximum reservable bandwidth and BC bandwidth of each link
l Next-hop address and outgoing label on the ingress
l Inbound interface, next-hop address, and outgoing label on the transit node
l Inbound interface on the egress
Procedure
Step 1 Assign an IP address to each interface and configure a routing protocol.
# Assign an IP address and a mask to each interface and configure OSPF so that all LSRs are
interconnected.
Step 2 Configure basic MPLS functions and enable MPLS TE.
# Configure LSRA.
[*LSRA] mpls
[*LSRA-mpls] quit
Repeat this step for LSRB and LSRC.

Step 3 Configure MPLS TE attributes for links.
# Configure the maximum reservable bandwidth and BC0 bandwidth for the link on the
outbound interface of each LSR. The BC0 bandwidth of links must be greater than the tunnel
bandwidth (10 Mbit/s).
# Configure LSRA.
# Configure LSRB.


# Configure LSRC.
[*LSRC-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
Step 4 Configure MPLS TE tunnel interfaces.

# Create an MPLS TE tunnel from LSRA to LSRC.
[*LSRA-Tunnel10] mpls te bidirectional
# Create an MPLS TE tunnel from LSRC to LSRA.

Step 5 Configure the ingress, a transit node, and the egress for the static bidirectional co-routed CR-
LSP.
# Configure LSRA as the ingress.
[~LSRA] bidirectional static-cr-lsp ingress Tunnel 10
[*LSRA-bi-static-ingress-Tunnel10] forward nexthop 2.1.1.2 out-label 20 bandwidth
ct0 10000
[*LSRA-bi-static-ingress-Tunnel10] backward in-label 20
[*LSRA-bi-static-ingress-Tunnel10] commit
[~LSRA-bi-static-ingress-Tunnel10] quit
# Configure LSRB as a transit node.

[~LSRB]bidirectional static-cr-lsp transit lsp1
[*LSRB-bi-static-transit-lsp1] forward in-label 20 nexthop 3.2.1.2 out-label 40
bandwidth ct0 10000
[*LSRB-bi-static-transit-lsp1] backward in-label 16 nexthop 2.1.1.1 out-label 20
bandwidth ct0 10000
[*LSRB-bi-static-transit-lsp1] commit
[~LSRB-bi-static-transit-lsp1] quit
# Configure LSRC as the egress.

[~LSRC] bidirectional static-cr-lsp egress Tunnel20
[*LSRC-bi-static-egress-Tunnel20] forward in-label 40 lsrid 1.1.1.1 tunnel-id 100
[*LSRC-bi-static-egress-Tunnel20] backward nexthop 3.2.1.1 out-label 16 bandwidth
ct0 10000
[*LSRC-bi-static-egress-Tunnel20] commit
[~LSRC-bi-static-egress-Tunnel20] quit

Step 6 Bind the static bidirectional co-routed CR-LSP to the tunnel interface on LSRC.
[~LSRC] interface Tunnel20
[~LSRC-Tunnel20] mpls te passive-tunnel
[*LSRC-Tunnel20] mpls te binding bidirectional static-cr-lsp egress Tunnel20

The command output shows that the tunnel interface is Up.
Run the display mpls te tunnel command on each LSR. The command output shows that
MPLS TE tunnels have been established.
# Check the configuration on LSRA.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 0 --/20 I Tunnel10
20/--
-------------------------------------------------------------------------------
# Check the configuration on LSRB.

[~LSRB] display mpls te tunnel
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
- - - 20/40 T lsp1
16/20
-------------------------------------------------------------------------------
# Check the configuration results on LSRC.

[~LSRC] display mpls te tunnel
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 - 40/-- E Tunnel20
--/16
-------------------------------------------------------------------------------
Run the display mpls te bidirectional static-cr-lsp command on each LSR to view
information about the static bidirectional co-routed CR-LSP.
# Check the configuration on LSRA.
[~LSRA] display mpls te bidirectional static-cr-lsp
Tunnel10 3.3.3.3/32 NULL/20 -/GE1/0/0
20/NULL GE1/0/0/- Up
# Check the configuration on LSRB.

[~LSRB] display mpls te bidirectional static-cr-lsp


lsp1 -/32 20/40 GE1/0/0/GE2/0/0
16/20 GE2/0/0/GE1/0/0 Up
# Check the configuration on LSRC.

[~LSRC] display mpls te bidirectional static-cr-lsp
Tunnel20 1.1.1.1/32 40/NULL GE1/0/0/-
NULL/16 -/GE1/0/0 Up
After completing the configuration, run the ping command on LSRA. The static bidirectional
co-routed CR-LSP is reachable.
[~LSRA] ping lsp -a 1.1.1.1 te Tunnel 10
LSP PING FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel10 : 100 data bytes, press
CTRL_C to break
Reply from 3.3.3.3: bytes=100 Sequence=1 time = 56 ms
--- FEC: RSVP IPV4 SESSION QUERY Tunnel10 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 3/35/60 ms
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
bidirectional static-cr-lsp ingress Tunnel10
forward nexthop 2.1.1.2 out-label 20 bandwidth ct0 10000
backward in-label 20
#
undo shutdown
ip address 2.1.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel10
destination 3.3.3.3
mpls te bidirectional
#

ip route-static 2.2.2.2 255.255.255.255 2.1.1.2

ip route-static 3.3.3.3 255.255.255.255 2.1.1.2
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
bidirectional static-cr-lsp transit lsp1
forward in-label 20 nexthop 3.2.1.2 out-label 40 bandwidth ct0 10000
backward in-label 16 nexthop 2.1.1.1 out-label 20 bandwidth ct0 10000
#
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 3.2.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 2.1.1.1
ip route-static 3.3.3.3 255.255.255.255 3.2.1.2
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
bidirectional static-cr-lsp egress Tunnel20
forward in-label 40 lsrid 1.1.1.1 tunnel-id 100
backward nexthop 3.2.1.1 out-label 16 bandwidth ct0 10000
#
undo shutdown
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Tunnel20
destination 1.1.1.1


mpls te passive-tunnel
mpls te binding bidirectional static-cr-lsp egress Tunnel20
#
ip route-static 1.1.1.1 255.255.255.255 3.2.1.1
ip route-static 2.2.2.2 255.255.255.255 3.2.1.1
#
return
3.38.3 Example for Configuring an Associated Bidirectional Static

CR-LSP
This section provides an example for configuring an associated bidirectional static CR-LSP.
In Figure 3-22, a forward static CR-LSP is established along the path PE1 -> PE2, and a
reverse static CR-LSP is established along the path PE2 -> PE1. To allow a traffic switchover
to be performed on both CR-LSPs, bind the two static CR-LSPs to each other to form an
associated bidirectional static CR-LSP.
Figure 3-22 Associated bidirectional static CR-LSP

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
10.1.1.1/30 10.1.1.2/30 10.2.1.1/30 10.2.1.2/30
PE1 P PE2
Table 3-15 Interfaces and their IP addresses on each device

Devic Interface Name IP Address and Mask
e
Name
PE1 Loopback1 1.1.1.1/32
GE 1/0/0 10.1.1.1/30
P Loopback1 2.2.2.2/32
GE 1/0/0 10.1.1.2/30
GE 2/0/0 10.2.1.1/30
PE2 Loopback1 3.3.3.3/32
GE 2/0/0 10.2.1.2/30

1. Assign an IP address and its mask to every interface and configure a loopback interface
address as an LSR ID on every node.
2. Configure a forward static CR-LSP and a reverse static CR-LSP.
3. Bind the forward and reverse static CR-LSPs to each other.
Data Preparation
NOTE
In this example, a forward static CR-LSP is established along the path PE1 -> PE2, and a reverse static
CR-LSP is established along the path PE2 -> PE1.
Table 3-16 Data to be prepared
Device Parameter Value

Name
PE1 Number of a tunnel interface Tunnel10

on the forward CR-LSP
Tunnel ID of the forward CR- 100

LSP
Outgoing label of the forward 20

CR-LSP
Name of the reverse CR-LSP Tunnel20
Incoming label of the reverse 130

CR-LSP
P Name of the forward CR-LSP Tunnel10
Incoming label of the forward 20

CR-LSP
Outgoing label of the forward 30

CR-LSP
Name of the reverse CR-LSP Tunnel20
Incoming label of the reverse 120

CR-LSP
Outgoing label of the reverse 130

CR-LSP
PE2 Number of a tunnel interface Tunnel20

on the reverse CR-LSP
Tunnel ID of the reverse CR- 200

LSP
Outgoing label of the reverse 120

CR-LSP

Device Parameter Value

Name
Name of the forward CR-LSP Tunnel10
Incoming label of the forward 30

CR-LSP
Procedure
Step 1 Assign an IP address and a mask to each interface.
Assign IP addresses and masks to interfaces. For configuration details, see Configuration
Files in this section.
Step 2 Configure a forward static CR-LSP and a reverse static CR-LSP.
Step 3 Bind the forward and reverse static CR-LSPs to each other.
# Configure PE1.
[~PE1] interface Tunnel 10
[~PE1-Tunnel10] mpls te reverse-lsp protocol static lsp-name Tunnel20
[*PE1-Tunnel10] commit
# Configure PE2.
[~PE2-Tunnel20] mpls te reverse-lsp protocol static lsp-name Tunnel10

After completing the preceding configurations, run the display mpls te reverse-lsp verbose
command on PE1 and PE2 to view reserve static CR-LSP information. The following
example uses the display on PE1.
[~PE1] display mpls te reverse-lsp verbose
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Obverse Tunnel : Tunnel10 //Tunnel interface on the forward CR-
LSP
Reverse LSP Name : Tunnel20 //Name of the reverse CR-LSP
Reverse LSP State : Up //Status of the reverse CR-LSP
----End
Configuration Files
l PE1 configuration file
#
sysname PE1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te

#
undo shutdown
ip address 10.1.1.1 255.255.255.252
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel10
destination 3.3.3.3
mpls te reverse-lsp protocol static lsp-name Tunnel20
#
#
label 130
#
return
l P configuration file
#
sysname P
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
undo shutdown
ip address 10.1.1.2 255.255.255.252
mpls
mpls te
#
undo shutdown
ip address 10.2.1.1 255.255.255.252
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
#
#
return
#
sysname PE2
#
mpls lsr-id 3.3.3.3
#

mpls
mpls te
#
s#
undo shutdown
ip address 10.2.1.2 255.255.255.252
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Tunnel20
destination 1.1.1.1
mpls te reverse-lsp protocol static lsp-name Tunnel10
#
#
label 30
#
return
3.38.4 Example for Configuring an RSVP-TE Tunnel

On the network shown in Figure 3-23, LSRA, LSRB, LSRC, and LSRD are level-2 routers
that run IS-IS.
RSVP-TE is used to establish a TE tunnel with 20 Mbit/s bandwidth between LSRA and
LSRD. The maximum reservable bandwidth for every link along the TE tunnel is 100 Mbit/s
and the BC0 bandwidth is 100 Mbit/s.
Figure 3-23 Networking diagram for an RSVP-TE tunnel

NOTE
Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
LSRA LSRD
interface1 interface1
10.1.1.1/24 10.3.1.2/24
10.1.1.2/24 interface2 interface2 10.3.1.1/24
Loopback1 10.2.1.1/24 10.2.1.2/24 Loopback1
2.2.2.9/32 3.3.3.9/32
LSRB LSRC

Configuration Notes
None.
2. Enable IS-IS globally; configure the network entity name; set the cost type of TE to
enable IS-IS TE; enable IS-IS on every interface, including a loopback interface.
3. Set an MPLS LSR ID for every LSR and enable MPLS, MPLS TE, RSVP-TE, and
CSPF globally.
4. Enable MPLS, MPLS TE, and RSVP-TE on every interface.
5. Set the maximum reservable bandwidth and BC bandwidth on an outbound interface of
every link along the TE tunnel.
6. Create a tunnel interface on the ingress and configure the source and destination IP
addresses for the tunnel, tunnel protocol, destination address, and tunnel bandwidth.
Data Preparation
l Origin AS number, IS-IS level, and area ID of every LSR
l BC bandwidth and maximum reservable bandwidth on every link along the TE tunnel
l Tunnel interface name, IP address, destination address, tunnel ID and tunnel bandwidth
Procedure
Step 1 Assign an IP address and its mask to every interface.
Assign the IP address and its mask to every interface as according to Figure 3-23. For
configuration details, see Configuration Files in this section.
Step 2 Configure IS-IS.
# 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-GigabitEthernet1/0/0] isis enable 1
[*LSRA-GigabitEthernet1/0/0] quit
[*LSRA] interface loopback 1
[*LSRA-LoopBack1] isis enable 1
[*LSRA-LoopBack1] commit
[~LSRA-LoopBack1] 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-GigabitEthernet1/0/0] isis enable 1
[*LSRB] interface loopback 1
[*LSRB-LoopBack1] isis enable 1
[*LSRB-LoopBack1] commit
[~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 gigabitethernet 1/0/0
[*LSRC-GigabitEthernet1/0/0] isis enable 1
[*LSRC-GigabitEthernet1/0/0] quit
[*LSRC] interface loopback 1
[*LSRC-LoopBack1] isis enable 1
[*LSRC-LoopBack1] commit
[~LSRC-LoopBack1] quit
# Configure LSRD.
[~LSRD] isis 1
[*LSRD-isis-1] network-entity 00.0005.0000.0000.0004.00
[*LSRD-isis-1] is-level level-2
[*LSRD-isis-1] quit
[*LSRD] interface gigabitethernet 1/0/0
[*LSRD-GigabitEthernet1/0/0] isis enable 1
[*LSRD-GigabitEthernet1/0/0] quit
[*LSRD] interface loopback 1
[*LSRD-LoopBack1] isis enable 1
[*LSRD-LoopBack1] commit
[~LSRD-LoopBack1] quit
After completing the configurations, run the display ip routing-table command on every
LSR. All LSRs have learned routes from one another. The following example uses the
command output on LSRA.
[~LSRA] display ip routing-table
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table : _public_
Destinations : 13 Routes : 13
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 10.1.1.2
GigabitEthernet1/0/0
3.3.3.9/32 ISIS-L2 15 20 D 10.1.1.2
4.4.4.9/32 ISIS-L2 15 30 D 10.1.1.2
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1

10.2.1.0/24 ISIS-L2 15 20 D 10.1.1.2
10.3.1.0/24 ISIS-L2 15 30 D 10.1.1.2
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
Step 3 Configure basic MPLS functions and enable MPLS TE, RSVP-TE, and CSPF.
# Enable MPLS, MPLS TE, and RSVP-TE on every LSR and their interfaces along a tunnel,
and enable CSPF in the system view of the ingress.
# Configure LSRA.
[*LSRA] mpls
[*LSRA-mpls] mpls rsvp-te
[*LSRA-mpls] mpls te cspf
[*LSRA-mpls] quit
[*LSRA-GigabitEthernet1/0/0] mpls rsvp-te
# Configure LSRB.
[~LSRB] mpls lsr-id 2.2.2.9
[*LSRB] mpls
[*LSRB-mpls] mpls te
[*LSRB-mpls] mpls rsvp-te
[*LSRB-mpls] quit
[*LSRB-GigabitEthernet1/0/0] mpls
[*LSRB-GigabitEthernet1/0/0] mpls te
[*LSRB-GigabitEthernet1/0/0] mpls rsvp-te
# Configure LSRC.
[~LSRC] mpls lsr-id 3.3.3.9
[*LSRC] mpls
[*LSRC-mpls] mpls te
[*LSRC-mpls] mpls rsvp-te
[*LSRC-mpls] quit
[*LSRC-GigabitEthernet1/0/0] mpls
[*LSRC-GigabitEthernet1/0/0] mpls te
[*LSRC-GigabitEthernet1/0/0] mpls rsvp-te
# Configure LSRD.

[~LSRD] mpls lsr-id 4.4.4.9

[*LSRD] mpls
[*LSRD-mpls] mpls te
[*LSRD-mpls] mpls rsvp-te
[*LSRD-mpls] quit
[*LSRD-GigabitEthernet1/0/0] mpls
[*LSRD-GigabitEthernet1/0/0] mpls te
[*LSRD-GigabitEthernet1/0/0] mpls rsvp-te
[*LSRD-GigabitEthernet1/0/0] commit
[~LSRD-GigabitEthernet1/0/0] quit
Step 4 Configure IS-IS TE.

# Configure LSRA.
[~LSRA] isis 1
[~LSRA-isis-1] cost-style wide
[*LSRA-isis-1] traffic-eng level-2
[*LSRA-isis-1] commit
[~LSRA-isis-1] quit
# Configure LSRB.
[~LSRB] isis 1
[~LSRB-isis-1] cost-style wide
[*LSRB-isis-1] traffic-eng level-2
[*LSRB-isis-1] commit
[~LSRB-isis-1] quit
# Configure LSRC.
[~LSRC] isis 1
[~LSRC-isis-1] cost-style wide
[*LSRC-isis-1] traffic-eng level-2
[*LSRC-isis-1] commit
[~LSRC-isis-1] quit
# Configure LSRD.
[~LSRD] isis 1
[~LSRD-isis-1] cost-style wide
[*LSRD-isis-1] traffic-eng level-2
[*LSRD-isis-1] commit
[~LSRD-isis-1] quit
Step 5 Set MPLS TE bandwidth attributes for links.

# Set the maximum reservable bandwidth and BC0 bandwidth for a link on every interface
along the TE tunnel.
# Configure LSRA.
# Configure LSRB.
# Configure LSRC.


Step 6 Configure an MPLS TE tunnel interface.

# Create a tunnel interface on the ingress; configure the source and destination IP addresses
for the tunnel, tunnel protocol, tunnel ID, and RSVP-TE signaling protocol; run the commit
command to make the configurations take effect.
# Configure LSRA.
[~LSRA] interface tunnel 1
[*LSRA-Tunnel1] mpls te bandwidth ct0 20000

After completing the preceding configurations, run the display interface tunnel command on
LSRA. The tunnel interface is Up.
[~LSRA] display interface tunnel 1
Tunnel1 current state : Up (ifindex: 29)
Line protocol current state : Up
Last line protocol up time : 2012-11-30 05:58:08
Description:
Route Port,The Maximum Transmit Unit is 1500, Current BW: 20Mbps
Internet Address is unnumbered, using address of LoopBack1(1.1.1.9/32)
Encapsulation is TUNNEL, loopback not set
Tunnel destination 4.4.4.9
Tunnel up/down statistics 1
Tunnel protocol/transport MPLS/MPLS, ILM is available,
primary tunnel id is 0x61, secondary tunnel id is 0x0
Current system time: 2012-11-30 05:58:10
300 seconds output rate 0 bits/sec, 0 packets/sec
126 packets output, 34204 bytes
0 output error
18 output drop
Last 300 seconds input utility rate: 0.00%
Last 300 seconds output utility rate: 0.00%
Run the display mpls te tunnel-interface command on LSRA. Detailed information about
the tunnel interface is displayed.
[~LSRA] display mpls te tunnel-interface tunnel1
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None


Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
Run the display mpls te cspf tedb all command on LSRA. Link information in the TEDB is
displayed.
[~LSRA] display mpls te cspf tedb all
Maximum Nodes Supported: 2000 Current Total Node Number: 4

Maximum Links Supported: 8000 Current Total Link Number: 6

Maximum SRLGs supported: 10000 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 2
4 4.4.4.9 ISIS 1 Level-2 1
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
isis enable 1
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 bandwidth ct0 20000
mpls te tunnel-id 1
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0002.00
#

undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
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
traffic-eng level-2
network-entity 00.0005.0000.0000.0003.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
l LSRD configuration file
#
sysname LSRD
#
mpls lsr-id 4.4.4.9
#

mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0004.00
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
3.38.5 Example for Configuring the IP-Prefix Tunnel Function to

Automatically Establish MPLS TE Tunnels in a Batch
This section provides an example for configuring the ip-prefix tunnel function to
automatically establish MPLS TE tunnels in a batch.
In Figure 3-24, a customer expects to establish MPLS TE tunnels to form a full-mesh
network and configure Auto FRR for each tunnel. Establishing tunnels one by one is
laborious and complex. In this case, the ip-prefix tunnel function can be configured to
automatically establish MPLS tunnels in a batch.

Figure 3-24 Configuring the ip-prefix tunnel function to automatically establish MPLS TE
tunnels in a batch
Loopback0
2.2.2.9/32
10
.1
.3
24
.1
2/
LSRB /2
1.
4
1.
.
10
24
10
1/
.1
1.
.3
1.
.2
.
/2
10
4
LSRA LSRC
10.1.2.1/24 10.1.2.2/24
Loopback0 Loopback0
1.1.1.9/32 3.3.3.9/32
TE tunnel
Table 3-17 Interfaces and their IP addresses on each device
Device Interface Name IP Address and Mask

Name
LSRA Loopback0 1.1.1.9/32
GE 1/0/0 10.1.1.1/24
GE 1/0/1 10.1.2.1/24
LSRB Loopback0 2.2.2.9/32
GE 1/0/0 10.1.1.2/24
GE 1/0/1 10.1.3.1/24
LSRC Loopback0 3.3.3.9/32
GE 1/0/1 10.1.2.2/24
GE 1/0/2 10.1.3.2/24
1. Configure IS-IS and IS-IS TE.

2. Enable MPLS TE and BFD globally on each device.

3. Configure an IP prefix list.

4. Configure a P2P TE tunnel template.
5. Configure the automatic primary tunnel function.
Data Preparation
l IP address of each interface on each node: values shown in Figure 3-24
l LSR ID of each node: loopback addresses shown in Figure 3-24
l IS-IS process number (1), IS-IS level (level-2), and network entity name of each node:
– LSRA: 10.0000.0000.0001.00
– LSRC: 10.0000.0000.0002.00
– LSRB: 10.0000.0000.0003.00
l IP prefix name on each node: te-tunnel
l P2P TE tunnel template name on each node: te-tunnel
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure IS-IS and IS-IS TE. For configuration details, see Configuration Files in this
section.
Step 3 Enable MPLS TE and Auto FRR globally on each device. For configuration details, see
Configuration Files in this section.
Step 4 Configure an IP prefix list.
# Configure LSRA.
[~LSRA] ip ip-prefix te-tunnel permit 2.2.2.9 32
[*LSRA] ip ip-prefix te-tunnel permit 3.3.3.9 32
[*LSRA] commit
The configurations on LSRB and LSRC are similar to the configuration on LSRA. For
Step 5 Configure a P2P TE tunnel template.
# Configure LSRA.
[~LSRA] mpls te p2p-template te-tunnel
[*LSRA-te-p2p-template-te-tunnel] bandwidth ct0 1000
[*LSRA-te-p2p-template-te-tunnel] fast-reroute
[*LSRA-te-p2p-template-te-tunnel] commit
[~LSRA-te-p2p-template-te-tunnel] quit
Step 6 Configure the automatic primary tunnel function.
# Configure LSRA.
[~LSRA] mpls te auto-primary-tunnel ip-prefix te-tunnel p2p-template te-tunnel
[*LSRA] commit

# After completing the preceding configuration, run the display mpls te tunnel command on
LSRA. The command output shows that MPLS TE tunnels have been established.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9 2.2.2.9 1 -/3 I AutoTunnel32769
2.2.2.9 1.1.1.9 1 3/- E AutoTunnel32769
3.3.3.9 1.1.1.9 1 3/- E AutoTunnel32769
1.1.1.9 3.3.3.9 2 -/3 I AutoTunnel32770
1.1.1.9 3.3.3.9 3 -/32828 I AutoTunnel32771
2.2.2.9 3.3.3.9 3 32828/3 T AutoTunnel32771
3.3.3.9 2.2.2.9 3 32829/3 T AutoTunnel32771
1.1.1.9 2.2.2.9 4 -/32828 I AutoTunnel32772
2.2.2.9 1.1.1.9 4 3/- E AutoTunnel32772
3.3.3.9 1.1.1.9 4 3/- E AutoTunnel32772
-------------------------------------------------------------------------------
Obtain a tunnel name, for example, AutoTunnel32769, displayed in the Tunnel-name

column. Run the display mpls te tunnel-interface auto-primary-tunnel AutoTunnel32769
command to view detailed information about the specified tunnel.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
#
mpls te p2p-template te-tunnel
record-route label
bandwidth ct0 1000
fast-reroute
#
mpls te auto-primary-tunnel ip-prefix te-tunnel p2p-template te-tunnel
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te

#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
ip ip-prefix te-tunnel index 10 permit 2.2.2.9 32
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.9
#
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
#
record-route label
bandwidth ct0 1000
fast-reroute
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
isis enable 1
#


#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
#
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
#
record-route label
bandwidth ct0 1000
fast-reroute
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
#
return
3.38.6 Example for Configuring RSVP Authentication

On the network shown in Figure 3-25, GE 1/0/0, GE 2/0/0, and GE 3/0/0 on LSRA and
LSRB join Eth-Trunk1. An MPLS TE tunnel between LSRA and LSRC is established.
The handshake function, RSVP key authentication, and message window are configured for
LSRA and LSRB. The handshake function allows LSRA and LSRB to perform RSVP key

authentication. RSVP key authentication prevents forged packets from requesting network
resource usage. The message window function prevents RSVP message mis-sequence.
Figure 3-25 Networking diagram for RSVP authentication

NOTE
Interfaces 1 through 4 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, GE 4/0/0, respectively.

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
Eth-Trunk 1 Eth-Trunk 1
10.1.1.1/24 10.1.1.2/24
interface1 interface1 LSRB interface4 interface1 LSRC

LSRA 20.1.1.1/24 20.1.1.2/24
Configuration Notes
None.
1. Configure MPLS and establish an MPLS TE tunnel.
2. Configure RSVP authentication on interfaces.
3. Configure the handshake function on interfaces.
4. Set the size for the message window to allow interfaces to store 32 sequence numbers.
NOTE
The window size to 32 is recommended. If the window size is too small, received RSVP messages
outside the window are discarded, which terminates RSVP neighbor relationships.
Data Preparation
l OSPF process ID and area ID for every LSR
l Password and key for RSVP authentication
l RSVP message window size
Procedure
Assign an IP address and its mask to every interface as shown in Figure 3-25. For
Step 2 Configure OSPF.

Configure OSPF to advertise every network segment route and host route. For configuration
details, see Configuration Files in this section.
node. All nodes have learned routes from each other.
# Configure LSRA.
[*LSRA] mpls
[*LSRA-mpls] quit
[*LSRA] interface eth-trunk 1
[*LSRA-Eth-Trunk1] mpls
[*LSRA-Eth-Trunk1] mpls te
[*LSRA-Eth-Trunk1] mpls rsvp-te
[*LSRA-Eth-Trunk1] commit
[~LSRA-Eth-Trunk1] quit
NOTE
Repeat this step for LSRB and LSRC. For configuration details, see Configuration Files in this section.
Step 4 Configure OSPF TE.
# Configure LSRA.
[~LSRA] ospf 1
[~LSRA-ospf-1] opaque-capability enable
[*LSRA-ospf-1] area 0
[*LSRA-ospf-1-area-0.0.0.0] mpls-te enable
[*LSRA-ospf-1-area-0.0.0.0] commit
[~LSRA-ospf-1-area-0.0.0.0] quit
# Configure LSRB.
[~LSRB] ospf 1
[~LSRB-ospf-1] opaque-capability enable
[*LSRB-ospf-1] area 0
[*LSRB-ospf-1-area-0.0.0.0] mpls-te enable
[*LSRB-ospf-1-area-0.0.0.0] commit
[~LSRB-ospf-1-area-0.0.0.0] quit
# Configure LSRC.
[~LSRC] ospf 1
[~LSRC-ospf-1] opaque-capability enable
[*LSRC-ospf-1] area 0
[*LSRC-ospf-1-area-0.0.0.0] mpls-te enable
[*LSRC-ospf-1-area-0.0.0.0] commit
[~LSRC-ospf-1-area-0.0.0.0] quit
Step 5 Configure an MPLS RSVP-TE tunnel.
# Configure the MPLS TE tunnel on LSRA.


The tunnel interface is Up.
[~LSRA] display interface tunnel1
Tunnel1 current state : UP (ifindex: 18)
Line protocol current state : UP
Description:
0 output error
18 output drop
Step 6 Configure RSVP authentication on MPLS TE interfaces of LSRA and LSRB.
# Configure LSRA.
[~LSRA] interface eth-trunk 1
[~LSRA-Eth-Trunk1] mpls rsvp-te authentication cipher Huawei-123
[*LSRA-Eth-Trunk1] mpls rsvp-te authentication handshake
[*LSRA-Eth-Trunk1] mpls rsvp-te authentication window-size 32
[*LSRA-Eth-Trunk1] commit
# Configure LSRB.
[~LSRB] interface eth-trunk 1
[~LSRB-Eth-Trunk1] mpls rsvp-te authentication cipher Huawei-123
[*LSRB-Eth-Trunk1] mpls rsvp-te authentication handshake
[*LSRB-Eth-Trunk1] mpls rsvp-te authentication window-size 32
[*LSRB-Eth-Trunk1] commit
Run the reset mpls rsvp-te and display interface tunnel commands in sequence on LSRA.
Run the display mpls rsvp-te interface command on LSRA or LSRB. RSVP authentication
information is displayed.
[~LSRA] display mpls rsvp-te interface eth-trunk 1
Interface: Eth-Trunk1
Interface Address: 10.1.1.1
Interface state: UP Interface Index: 0x15
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: 500 msec
Increment Value: 1
Challenge: ENABLE WindowSize: 32
Next Seq # to be sent: 486866945 12 Key ID: 0x0101051d0101
Bfd Enabled: -- Bfd Min-Tx: --
Bfd Min-Rx: -- Bfd Detect-Multi: --
RSVP instance name: RSVP0
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
interface Eth-Trunk1
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
mpls rsvp-te authentication cipher O'W3[_\M"`!./a!1$H@GYA!!
mpls rsvp-te authentication handshake
mpls rsvp-te authentication window-size 32
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
#
interface Eth-Trunk1
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
mpls rsvp-te authentication cipher O'W3[_\M"`!./a!1$H@GYA!!
mpls rsvp-te authentication handshake

mpls rsvp-te authentication window-size 32

#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
mpls-te enable
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
#
interface GigabiEthernet1/0/0
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
mpls-te enable
network 3.3.3.3 0.0.0.0
network 20.1.1.0 0.0.0.255
#
return

3.38.7 Example for Configuring the Affinity Property of an MPLS

TE Tunnel
Figure 3-26 Networking diagram for an MPLS TE tunnel with the affinity property
NOTE
Interfaces 1 through 3 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, respectively.

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
interface1 interface2 interface1
192.168.1.1/24 192.168.2.1/24 192.168.2.2/24
interface1
LSRA 192.168.1.2/24 LSRB interface3 interface2
LSRC
192.168.3.1/24 192.168.3.2/24
On the network shown in Figure 3-26, the bandwidth of the link between LSRA and LSRB is
50 Mbit/s. The maximum reservable bandwidth of other links is 100 Mbit/s, and BC0
bandwidth is 100 Mbit/s.
Two tunnels named Tunnel1 and Tunnel2 from LSRA to LSRC are established on LSRA.
Both tunnels require 40 Mbit/s of bandwidth. The combined bandwidth of these two tunnels is
80 Mbit/s, higher than the bandwidth of 50 Mbit/s provided by the shared link between LSRA
and LSRB. In addition, Tunnel2 has a higher priority than Tunnel1, and preemption is
enabled.
In this example, SRLG attributes, affinities, and masks for links are used to allow Tunnel1
and Tunnel2 on LSRA to use separate links between LSRB and LSRC.
Configuration Notes
None.
1. Configure an RSVP-TE tunnel. See "Configuration Roadmap" in Example for
Configuring an RSVP-TE Tunnel.
2. Configure an SRLG attribute on an outbound interface of every LSR along each RSVP
TE tunnel.
3. Configure the affinity and mask for each tunnel based on the administrative groups of
links and networking requirements.
4. Set a priority value for each tunnel.
Data Preparation


l Maximum reservable bandwidth and BFD bandwidth for every link along each tunnel
l Administrative groups for links between LSRA and LSRB and between LSRB and
LSRC
l Affinity and mask for each tunnel
l Tunnel interface number, source and destination IP addresses, bandwidth, priority values,
and RSVP-TE signaling protocol of the tunnel
Procedure
Assign an IP address and its mask to every physical interface and configure a loopback
interface address as an LSR ID on every node according to Figure 3-26.
Step 2 Configure an IGP.
Configure OSPF on every LSR to advertise every network segment route and host route.
Step 3 Configure basic MPLS functions, enable MPLS TE, RSVP-TE, and OSPF TE on every LSR,
and enable CSPF on the ingress.
# Configure basic MPLS functions and enable MPLS TE and RSVP-TE on every LSR.
The following example uses the command output on LSRA.
[*LSRA] mpls
[*LSRA-mpls] quit
# Enable OSPF TE on every LSR. The following example uses the command output on
LSRA.
[*LSRA] ospf
[*LSRA-ospf-1] opaque-capability enable
[*LSRA-ospf-1-area-0.0.0.0] quit
[*LSRA-ospf-1] quit
Repeat this step for LSRB and LSRC. For configuration details, see Configuration Files in
this section.
# Enable CSPF on the ingress LSRA.
[*LSRA] mpls
[*LSRA-mpls] commit
[~LSRA-mpls] quit
Step 4 Configure MPLS TE attributes on the outbound interface of every LSR.

# Set the maximum reservable link bandwidth and BC0 bandwidth to 50 Mbit/s on LSRA.
# Se the administrative group to 0x10001 on LSRA.

[*LSRA-GigabitEthernet1/0/0] mpls te link administrative group 10001
# Configure MPLS TE attributes on LSRB.

[*LSRB-GigabitEthernet2/0/0] mpls te link administrative group 10101
[*LSRB-GigabitEthernet3/0/0] mpls te link administrative group 10011
After completing the configurations, run the display mpls te cspf tedb node command on
LSRA. TEDB information contains maximum available and reservable bandwidth for every
link, and the administrative group attribute in the Color field.
[~LSRA] display mpls te cspf tedb node
Router ID: 1.1.1.1
IGP Type: OSPF Process ID: 1 IGP Area: 0
MPLS-TE Link Count: 1
Link[1]:
OSPF Router ID: 192.168.1.1 Opaque LSA ID: 1.0.0.1
Interface IP Address: 192.168.1.1
DR Address: 192.168.1.2
IGP Area: 0
Link Type: Multi-access Link Status: Active
IGP Metric: 1 TE Metric: 1 Color: 0x10001
Bandwidth Allocation Model : -
Maximum Link-Bandwidth: 50000 (kbps)
Maximum Reservable Bandwidth: 50000 (kbps)
Operational Mode of Router: TE
Bandwidth Constraints: Local Overbooking Multiplier:
BC[0]: 50000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 50000 (kbps), [1]: 50000 (kbps)
[2]: 50000 (kbps), [3]: 50000 (kbps)
[4]: 50000 (kbps), [5]: 50000 (kbps)
[6]: 50000 (kbps), [7]: 50000 (kbps)
Router ID: 2.2.2.2
Link[1]:
DR Address: 192.168.1.2
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1

BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
Link[2]:
DR Address: 192.168.2.1
IGP Area: 0
BC[0]: 100000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 100000 (kbps)
Link[3]:
DR Address: 192.168.3.1
IGP Area: 0
BC[0]: 100000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 100000 (kbps)
Router ID: 3.3.3.3
Link[1]:
DR Address: 192.168.2.1
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
Link[2]:

DR Address: 192.168.3.1
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)

# Configure a tunnel named Tunnel1 on LSRA.
[*LSRA-Tunnel1] mpls te affinity property 10101 mask 11011
The default lowest setup and holding priorities are used. The priority values are 7.
The affinity mask of Tunnel1 is 0x11011, indicating that the left-most two bits and right-most
two bits are to be compared. The affinity of Tunnel1 is 0x10101. Tunnel1 selects a path whose
administrative group has the left-most two bits of 10 and right-most two bits of 01. Based on
the preceding rule, Tunnel1 selects LSA's GE 1/0/0 (whose administrative group value is
0x10001) and LSRB's GE 2/0/0 (whose administrative group value is 0x10101).
After completing the configurations, run the display mpls te tunnel-interface command on
LSRA. The tunnel status is displayed.
[~LSRA] display mpls te tunnel-interface
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -


Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
Run the display mpls te cspf tedb node command on LSRA. TEDB information contains
bandwidth for every link.
[~LSRA] display mpls te cspf tedb node
Router ID: 1.1.1.1
Link[1]:
DR Address: 192.168.1.2
IGP Area: 0


BC[0]: 50000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 50000 (kbps), [1]: 50000 (kbps)
[2]: 50000 (kbps), [3]: 50000 (kbps)
[4]: 50000 (kbps), [5]: 50000 (kbps)
[6]: 50000 (kbps), [7]: 10000 (kbps)
Router ID: 2.2.2.2
Link[1]:
DR Address: 192.168.1.2
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
Link[2]:
DR Address: 192.168.2.1
IGP Area: 0
BC[0]: 100000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 60000 (kbps)
Link[3]:
DR Address: 192.168.3.1
IGP Area: 0
BC[0]: 100000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)

[6]: 100000 (kbps), [7]: 100000 (kbps)

Router ID: 3.3.3.3
Link[1]:
DR Address: 192.168.2.1
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
Link[2]:
DR Address: 192.168.3.1
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
The BW Unreserved field indicates the remaining bandwidth reserved for tunnel links with
various priorities. [7] indicates that bandwidth of 40 Mbit/s has been successfully reserved for
a tunnel. The bandwidth information also matches the path of a tunnel. This proves that the
affinity and mask match the administrative group of every link.
Alternatively, run the display mpls te tunnel diagnostic command to check the outbound
interfaces of links along the tunnel on LSRB.
[~LSRB]display mpls te tunnel diagnostic
--------------------------------------------------------------------------------
LSP-Id Destination In/Out-If
--------------------------------------------------------------------------------
1.1.1.1:1:3 3.3.3.3 GE1/0/0/GE2/0/0
--------------------------------------------------------------------------------

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

The affinity mask of Tunnel2 is 0x11101, indicating that the left-most three bits and right-
most one bit are to be compared. The affinity of Tunnel2 is 0x10011. Tunnel2 selects a path
whose administrative group has the left-most three bits of 100 and right-most one bit of 1.
Based on the preceding rule, Tunnel2 selects LSA's GE 1/0/0 (whose administrative group
value is 0x10001) and LSRB's GE 3/0/0 (whose administrative group value is 0x10011).
After completing the configurations, run the display interface tunnel or display mpls te
tunnel diagnostic command on LSRA. The status of Tunnel1 is Down. This is because since
the maximum reservable bandwidth is insufficient, Tunnel2 is of a higher priority and has
preempted the bandwidth reserved for Tunnel1.
Run the display mpls te cspf tedb node command. TEDB information contains the
bandwidth for every link, which indicates that Tunnel2 does pass through GE 3/0/0 of LSRB.
Alternatively, run the display mpls te tunnel command to check outbound interfaces of links
along the tunnel on LSRB.
[~LSRB] display mpls te tunnel diagnostic
--------------------------------------------------------------------------------
LSP-Id Destination In/Out-If
--------------------------------------------------------------------------------
1.1.1.1:1:4 3.3.3.3 GE1/0/0/GE3/0/0
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
ospf 1
area 0.0.0.0
mpls-te enable
network 1.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
#
undo shutdown
ip address 192.168.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.1 255.255.255.255
#

interface Tunnel1
destination 3.3.3.3
mpls te tunnel-id 1
mpls te affinity property 10101 mask 11011
#
interface Tunnel2
destination 3.3.3.3
mpls te priority 6
mpls te affinity property 10011 mask 11101
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
mpls-te enable
network 2.2.2.2 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 192.168.3.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
return


#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
mpls-te enable
network 3.3.3.3 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 192.168.3.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
return
3.38.8 Example for Configuring an Inter-area Tunnel

Figure 3-27 illustrates a network:
l IS-IS runs on LSRA, LSRB, LSRC, LSRD, and LSRE.
– LSRA and LSRE are level-1 routers.
– LSRB and LSRD are level-1-2 routers.
– LSRC is a level-2 router.
l RSVP-TE is used to establish a TE tunnel between LSRA and LSRE over IS-IS areas.
The bandwidth for the TE tunnel is 20 Mbit/s.
l Both the maximum reservable bandwidth and BC0 bandwidth for every link along the
TE tunnel are 100 Mbit/s.
Figure 3-27 Inter-area tunnel networking

NOTE

Area address: 00.0005 Area address: 00.0006 Area address: 00.0007

2.2.2.2/32 3.3.3.3/32 4.4.4.4/32
interface1
LSRB interface2 LSRD
10.3.1.1/24
L1/2 10.2.1.1/24 L1/2
interface2
interface1 LSRC interface1 interface2
10.2.1.2/24
10.1.1.2/24 L2 10.3.1.2/24 10.4.1.1/24
10.1.1.1/24 10.4.1.2/24
LSRA LSRE
L1 L1
Loopback1 Loopback1
1.1.1.1/32 5.5.5.5/32
Configuration Notes
None.
1. Assign an IP address and its mask to every interface and configure a loopback address
that is used as an LSR ID on every LSR.
2. Enable IS-IS globally and enable IS-IS TE.
3. Configure a loose explicit path on which LSRB, LSRC, and LSRD functioning as area
border routers (ABRs) are located.
4. Configure MPLS RSVP-TE.
5. Set bandwidth attributes for every outbound interface on every LSR along the TE tunnel.
6. Create a tunnel interface on the ingress and configure the source and destination IP
addresses, protocol, RSVP-TE signaling protocol, and bandwidth for the tunnel.
Data Preparation
l Maximum reservable bandwidth and BC bandwidth for every link along the TE tunnel
l Tunnel interface number, source and destination addresses, ID, RSVP-TE signaling
protocol, and bandwidth of the tunnel
Procedure
Assign an IP address and its mask to every interface and configure a loopback address that is
used as an LSR ID on every LSR according to Figure 3-27.

Step 2 Configure IS-IS.

# Configure LSRA.
[~LSRA] isis 1
[*LSRA-isis-1] network-entity 00.0005.0000.0000.0001.00
[*LSRA-isis-1] is-level level-1
[*LSRA-isis-1] quit
[*LSRA-GigabitEthernet1/0/0] isis enable 1
[*LSRA] interface loopback 1
[*LSRA-LoopBack1] isis enable 1
[*LSRA-LoopBack1] commit
[~LSRA-LoopBack1] quit
# Configure LSRB.
[~LSRB] isis 1
[*LSRB-isis-1] network-entity 00.0005.0000.0000.0002.00
[*LSRB-isis-1] is-level level-1-2
[*LSRB-isis-1] import-route isis level-2 into level-1
[*LSRB-isis-1] quit
[*LSRB] interface loopback 1
[*LSRB-LoopBack1] isis enable 1
[*LSRB-LoopBack1] commit
[~LSRB-LoopBack1] quit
# Configure LSRC.
[~LSRC] isis 1
[*LSRC-isis-1] network-entity 00.0006.0000.0000.0003.00
[*LSRC-isis-1] is-level level-2
[*LSRC-isis-1] quit
[*LSRC] interface loopback 1
[*LSRC-LoopBack1] isis enable 1
[*LSRC-LoopBack1] commit
[~LSRC-LoopBack1] quit
# Configure LSRD.
[~LSRD] isis 1
[*LSRD-isis-1] network-entity 00.0007.0000.0000.0004.00
[*LSRD-isis-1] is-level level-1-2
[*LSRD-isis-1] import-route isis level-2 into level-1
[*LSRD-isis-1] quit
[*LSRD] interface loopback 1
[*LSRD-LoopBack1] isis enable 1
[*LSRD-LoopBack1] commit
[~LSRD-LoopBack1] quit
# Configure LSRE.

[~LSRE] isis 1
[*LSRE-isis-1] network-entity 00.0007.0000.0000.0005.00
[*LSRE-isis-1] is-level level-1
[*LSRE-isis-1] quit
[*LSRE] interface gigabitethernet 1/0/0
[*LSRE-GigabitEthernet1/0/0] isis enable 1
[*LSRE-GigabitEthernet1/0/0] quit
[*LSRE] interface loopback 1
[*LSRE-LoopBack1] isis enable 1
[*LSRE-LoopBack1] commit
[~LSRE-LoopBack1] quit
node. All nodes have learned routes from one another.
Step 3 Configure basic MPLS functions and enable MPLS TE, RSVP-TE, and CSPF on the ingress
of the TE tunnel.
# Configure LSRA.
[*LSRA] mpls
[*LSRA-mpls] quit
# Configure LSRB.
[*LSRB] mpls
[*LSRB-mpls] quit
# Configure LSRC.
[*LSRC] mpls
[*LSRC-mpls] quit

# Configure LSRD.
[*LSRD] mpls
[*LSRD-mpls] quit
# Configure LSRE.
[~LSRE] mpls lsr-id 5.5.5.5
[*LSRE] mpls
[*LSRE-mpls] mpls te
[*LSRE-mpls] mpls rsvp-te
[*LSRE-mpls] quit
[*LSRE] interface gigabitethernet 1/0/0
[*LSRE-GigabitEthernet1/0/0] mpls
[*LSRE-GigabitEthernet1/0/0] mpls te
[*LSRE-GigabitEthernet1/0/0] mpls rsvp-te
[*LSRE-GigabitEthernet1/0/0] commit
[~LSRE-GigabitEthernet1/0/0] quit

# Configure LSRA.
[~LSRA] isis 1
[~LSRA-isis-1] quit
# Configure LSRB.
[~LSRB] isis 1
[~sLSRB-isis-1] cost-style wide
[*LSRB-isis-1] traffic-eng level-1-2
[~LSRB-isis-1] quit
# Configure LSRC.
[~LSRC] isis 1
[~LSRC-isis-1] quit
# Configure LSRD.
[~LSRD] isis 1
[*LSRD-isis-1] traffic-eng level-1-2
[~LSRD-isis-1] quit
# Configure LSRE.

[~LSRE] isis 1
[~LSRE-isis-1] cost-style wide
[*LSRE-isis-1] traffic-eng level-1
[*LSRE-isis-1] commit
[~LSRE-isis-1] quit
Step 5 Configure a loose explicit path.

[~LSRA] explicit-path atoe enable
[*LSRA-explicit-path-atoe] next hop 10.1.1.2 include loose
[*LSRA-explicit-path-atoe] commit
[~LSRE-isis-1] quit

# Set the maximum reservable bandwidth and BC0 bandwidth for links on LSRA.
# Set the maximum bandwidth and reservable bandwidth for links on LSRB.
# Set the maximum bandwidth and reservable bandwidth for links on LSRC.
# Set the maximum bandwidth and reservable bandwidth for links on LSRD.
[~LSRD] interface gigabitethernet 2/0/0
[~LSRD-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*LSRD-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000
Step 7 Configure an MPLS RSVP-TE tunnel.

# Configure the MPLS TE tunnel on LSRA.
[*LSRA-Tunnel1] mpls te path explicit-path atoe

[~LSRA] display interface Tunnel


Description:
Route Port,The Maximum Transmit Unit is 1500
0 output error
18 output drop
# Run the display mpls te tunnel-interface command on LSRA. Detailed information about
the TE tunnel interface is displayed.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -

Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
explicit-path atoe
next hop 10.1.1.2 include loose
#
isis 1
is-level level-1
cost-style wide
traffic-eng level-1
network-entity 00.0005.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
isis enable 1

mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 5.5.5.5
mpls te tunnel-id 1
mpls te path explicit-path atoe
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-1-2
cost-style wide
traffic-eng level-1-2
import-route isis level-2 into level-1
network-entity 00.0005.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide

traffic-eng level-2
network-entity 00.0006.0000.0000.0003.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
#
sysname LSRD
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-1-2
cost-style wide
network-entity 00.0007.0000.0000.0004.00
import-route isis level-2 into level-1
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return
l LSRE configuration file
#

sysname LSRE
#
mpls lsr-id 5.5.5.5
#
mpls
mpls te
mpls rsvp-te
isis 1
is-level level-1
cost-style wide
traffic-eng level-1
network-entity 00.0007.0000.0000.0005.00
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
3.38.9 Example for Configuring the Threshold for Flooding

Bandwidth Information
On the network shown in Figure 3-28, an RSVP-TE tunnel between LSRA and LSRD is
established. The bandwidth is 50 Mbit/s. The maximum reservable bandwidth and BC0
bandwidth for every link are 100 Mbit/s. The RDM is used.
The threshold for flooding bandwidth information is set to 20%. This reduces the number of
attempts to flood bandwidth information and saves network resources. If the proportion of the
bandwidth used or released by an MPLS TE tunnel to the available bandwidth in the TEDB is
greater than or equal to 20%, an IGP floods the bandwidth information, and CSPF updates
TEDB information.
Figure 3-28 Networking diagram for the threshold for flooding bandwidth information
NOTE

Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
LSRA LSRD
10.1.1.1/24 10.3.1.2/24
2.2.2.9/32 3.3.3.9/32
LSRB LSRC
Configuration Notes
None.
1. Configure an RSVP-TE tunnel. See "Configuration Roadmap" in Example for
Configuring an RSVP-TE Tunnel.
2. Configure bandwidth and the threshold for flooding bandwidth information
Data Preparation
l Tunnel interface type and number, source and destination addresses, ID, and RSVP-TE
signaling protocol of the tunnel
l Threshold for flooding bandwidth information
Procedure
interface address as an LSR ID on every node according to Figure 3-28.
Configure OSPF or IS-IS on every node to implement connectivity between them. IS-IS is
used in this example.

# Enable MPLS, MPLS TE, and RSVP-TE on every LSR and their interfaces along a tunnel,
and enable CSPF in the system view of the ingress.
Step 4 Set MPLS TE bandwidth for links.
# Set the maximum reservable bandwidth and BC0 bandwidth for a link on every interface
along the TE tunnel.
Step 5 Configure the threshold for flooding bandwidth information.
# Set the threshold for flooding bandwidth information to 20% on a physical interface on
LSRA. If the proportion of the bandwidth used or released by an MPLS TE tunnel to the
available bandwidth in the TEDB is greater than or equal to 20%, an IGP floods the
bandwidth information, and CSPF updates TEDB information.
[~LSRA-GigabitEthernet1/0/0] mpls te bandwidth change thresholds up 20
[*LSRA-GigabitEthernet1/0/0] mpls te bandwidth change thresholds down 20
Run the display mpls te cspf tedb command on LSRA. TEDB information is displayed.
[~LSRA] display mpls te cspf tedb interface 10.1.1.1
Router ID: 1.1.1.9

IGP Type: ISIS Process Id: 1
Link[1]:
ISIS System ID: 0000.0000.0001.00 Opaque LSA ID: 0000.0000.0001.00:00
DR Address: 10.1.1.1
DR ISIS System ID: 0000.0000.0001.01
IGP Area: Level-2
Operational Mode of Router : TE
BC[0]: 100000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 100000 (kbps)

[~LSRA]interface tunnel 1

After the configuration, run the display mpls te tunnel-interface command on LSRA. The
tunnel interface is Up.
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0


FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
Run the display mpls te cspf tedb command on LSRA. Bandwidth information is unchanged.
Router ID: 1.1.1.9

Link[1]:
DR ISIS System ID: 0000.0000.0001.01
IGP Area: Level-2
BC[0]: 100000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 100000 (kbps)

After the configurations are complete, change the bandwidth to 20000 kbit/s.
[~LSRA-Tunnel1] mpls te bandwidth ct0 20000
Run the display mpls te cspf tedb interface 10.1.1.1 command on LSRA. TEDB information
shows that the TE tunnel named Tunnel1 has been reestablished successfully. Its bandwidth is
20 kbit/s, reaching 20%, the threshold for flooding bandwidth information. Therefore, CSPF
TEDB information has been updated.
Router ID: 1.1.1.9

Link[1]:
DR ISIS System ID: 0000.0000.0001.01
IGP Area: Level-2


BC[0]: 100000 (kbps) LOM[0]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 80000 (kbps)
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls te bandwidth change thresholds up 20
mpls te bandwidth change thresholds down 20
isis enable 1
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 tunnel-id 1
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
#
mpls
mpls te
mpls rsvp-te
#
isis 1

is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
mpls te bandwidth change thresholds up 20
mpls te bandwidth change thresholds down 20
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
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
traffic-eng level-2
network-entity 00.0005.0000.0000.0003.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return


#
sysname LSRD
#
mpls lsr-id 4.4.4.9
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0004.00
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
3.38.10 Example for Configuring MPLS TE Manual FRR

On the network shown in Figure 3-29, a primary tunnel is along the path LSRA -> LSRB ->
LSRC -> LSRD. FRR is enabled on LSRB to protect traffic on the link between LSRB and
LSRC.
A bypass CR-LSP is established over the path LSRB -> LSRE -> LSRC. LSRB is a PLR, and
LSRC is an MP.
Explicit paths are used to establish the primary and bypass CR-LSPs. RSVP-TE is used as a
signaling protocol.
Figure 3-29 Networking diagram for MPLS TE manual FRR

NOTE

Loopback1
4.4.4.4/32
LSRD
interface1
4.1.1.2/24
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32 Loopback1
3.3.3.3/32 interface1
LSRA LSRB 4.1.1.1/24
interface2 interface2 LSRC

2.1.1.1/24 2.1.1.2/24 3.1.1.1/24 3.1.1.2/24 interface3
interface3 Loopback1 3.3.1.2/24
3.2.1.1/24 5.5.5.5/32
Primary LSP interface1 interface2
Bypass LSP 3.2.1.2/24 3.3.1.1/24
LSRE
Configuration Notes
None.
1. Configure a primary CR-LSP and enable TE FRR on the tunnel interface of the primary
CR-LSP.
2. Configure a bypass CR-LSP on the PLR (ingress) and specify the protected bandwidth
and the interface of the protected link.
Data Preparation

l Explicit paths for the primary and bypass CR-LSPs
l Tunnel interface number, source and destination IP addresses, ID, and RSVP-TE
signaling protocol for each of the primary and bypass CR-LSPs
l Protected bandwidth and type and number of the interface on the protected link

Procedure
interface address as an LSR ID on every node shown in Figure 3-29. For configuration
Enable IS-IS on all nodes to advertise host routes. For configuration details, see
node. All nodes have learned routes from each other.
Step 3 Configure basic MPLS functions and enable MPLS TE, CSPF, RSVP-TE, and IS-IS TE.
# Configure LSRA.
[*LSRA] mpls
[*LSRA-mpls] quit
[*LSRA] isis
[*LSRA-isis-1] cost-style wide
NOTE
Repeat this step for LSRB, LSRC, LSRD, and LSRE. For configuration details, see Configuration Files
in this section. CSPF is enabled only on LSRA and LSRB, which are ingress nodes of the primary and
bypass CR-LSPs respectively.
# Set both the maximum reservable bandwidth and BC0 bandwidth to 100 Mbit/s for links on
LSRA, LSRB, LSRC and LSRE.
# Configure LSRA.
# Configure LSRB.

# Configure LSRC.
# Configure LSRE.
[~LSRE] interface gigabitethernet 2/0/0
[~LSRE-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*LSRE-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000
Step 5 Configure an MPLS TE tunnel on LSRA.

# Configure an explicit path for the primary CR-LSP.
[~LSRA] explicit-path pri-path
[*LSRA-explicit-path-pri-path] next hop 2.1.1.2
[*LSRA-explicit-path-pri-path] quit
# Configure the MPLS TE tunnel for the primary CR-LSP.

[*LSRA] interface tunnel 1
[*LSRA-Tunnel1] mpls te path explicit-path pri-path
# Enable FRR.
[*LSRA-Tunnel1] mpls te fast-reroute
After completing the configurations, run the display interface tunnel command on LSRA.
Tunnel1 is Up.
[~LSRA] display interface tunnel

Description:
0 output error
18 output drop
# Run the display mpls te tunnel-interface command on LSRA. Detailed information about
the TE tunnel interface is displayed.

[~LSRA] display mpls te tunnel-interface

Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0


FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
Step 6 Configure a bypass CR-LSP on LSRB.

# Configure an explicit path for the bypass CR-LSP.
[~LSRB] explicit-path by-path
[*LSRB-explicit-path-by-path] next hop 3.2.1.2
[*LSRB-explicit-path-by-path] quit
# Configure the bypass CR-LSP.

[*LSRB] interface tunnel 3
[*LSRB-Tunnel3] ip address unnumbered interface loopback 1
[*LSRB-Tunnel3] tunnel-protocol mpls te
[*LSRB-Tunnel3] destination 3.3.3.3
[*LSRB-Tunnel3] mpls te tunnel-id 2
[*LSRB-Tunnel3] mpls te path explicit-path by-path
[*LSRB-Tunnel3] mpls te bandwidth ct0 100000
[*LSRB-Tunnel3] mpls te bypass-tunnel
# Bind the bypass CR-LSP to the interface of the protected link.

[*LSRB-Tunnel3] mpls te protected-interface gigabitethernet 2/0/0
[*LSRB-Tunnel3] commit
[~LSRB-Tunnel3] quit
After completing the configuration, run the display interface tunnel command on LSRB.
The tunnel named Tunnel3 is Up.
Run the display mpls te tunnel name tunnel1 verbose command on LSRB. The bypass
tunnel is bound to the outbound interface GE 2/0/0 and is not in use.
[~LSRB] display mpls te tunnel name Tunnel1 verbose
No : 1
TunnelIndex : -
Lsr Role : Transit
In-Interface : GE1/0/0
IncludeAllAff : 0x0
ER-Hop Table Index : - AR-Hop Table Index: -
PSB Handle : -
Created Time : 2012/02/01 04:53:22
--------------------------------
DS-TE Information
--------------------------------


--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass Attribute
HopLimit : 32 Bandwidth : 0
IncludeAnyGroup : 0 ExcludeAnyGroup : 0
IncludeAllGroup : 0
--------------------------------
BFD Information
--------------------------------

# Shut down the outbound interface of the protected link on the PLR.
[~LSRB-GigabitEthernet2/0/0] shutdown
Run the display interface tunnel 1 command on LSRA. The tunnel interface of the primary
CR-LSP is still Up.
Run the tracert lsp te tunnel1 command on LSRA. The path through which the primary CR-
LSP passes is displayed.
[~LSRA] tracert lsp te tunnel1
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C to
break.
TTL Replier Time Type Downstream
0 Ingress 2.1.1.2/[25 ]
1 2.1.1.2 3 Transit 3.2.1.2/[16 16 ]
2 3.2.1.2 4 Transit 3.3.1.2/[3 ]
3 3.3.1.2 4 Transit 4.1.1.2/[3 ]
4 4.4.4.4 3 Egress
The preceding command output shows that traffic has switched to the bypass CR-LSP.
NOTE
If the display mpls te tunnel-interface command is run immediately after FRR switching has been
performed, two CR-LSPs are both Up. This is because FRR uses the make-before-break mechanism to
establish a bypass CR-LSP. The original CR-LSP will be deleted after a new CR-LSP has been
established.
Run the display mpls te tunnel name Tunnel1 verbose command on LSRB. The bypass CR-
LSP is being used.
No : 1


TunnelIndex : -
Lsr Role : Transit
IncludeAllAff : 0x0
PSB Handle : -
Created Time : 2012/02/01 04:53:22
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass In Use : In Use
Bypass Attribute
IncludeAllGroup : 0
--------------------------------
BFD Information
--------------------------------
# Start the outbound interface of the protected link on the PLR.

[~LSRB] intrface gigabitethernet 2/0/0
[~LSRB-GigabitEthernet2/0/0] undo shutdown
Run the display interface tunnel 1 command on LSRA. The tunnel interface of the primary
CR-LSP is Up.
After specified period of time elapses, run the display mpls te tunnel name tunnel1 verbose
command on LSRB. Tunnel1's Bypass In Use status is Not Used, indicating that traffic has
switched back to GE 2/0/0.
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
explicit-path pri-path
next hop 2.1.1.2
next hop 3.1.1.2
next hop 4.1.1.2
next hop 4.4.4.4
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0001.00
#
undo shutdown
ip address 2.1.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 4.4.4.4
mpls te tunnel-id 1
mpls te record-route label
mpls te path explicit-path pri-path
mpls te fast-reroute
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
explicit-path by-path
next hop 3.2.1.2
next hop 3.3.1.2
next hop 3.3.3.3
#
isis 1
is-level level-2

cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0002.00
#
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 3.1.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 3.2.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface Tunnel3
destination 3.3.3.3
mpls te tunnel-id 2
mpls te record-route
mpls te path explicit-path by-path
mpls te bypass-tunnel
mpls te protected-interface GigabitEthernet 2/0/0
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0003.00
#
undo shutdown
ip address 4.1.1.1 255.255.255.0
mpls
mpls te


isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 3.1.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 3.3.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
#
sysname LSRD
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0004.00
#
undo shutdown
ip address 4.1.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return
#
sysname LSRE
#
mpls lsr-id 5.5.5.5
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide

traffic-eng level-2
network-entity 00.0005.0000.0000.0005.00
#
undo shutdown
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 3.3.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
3.38.11 Example for Configuring MPLS TE Auto FRR

On the network shown in Figure 3-30, a primary CR-LSP is established over an explicit path
LSRA -> LSRB -> LSRC. Bypass CR-LSPs need to be established on the ingress LSRA and
the transit node LSR B respectively. These bypass CR-LSPs are required to provide
bandwidth protection.A node protection tunnel is a bypass tunnel that originates from LSA's
inbound interface, terminates at LSRC's outbound interface, and passes through the
intermediate LSRB. A link protection tunnel is a bypass tunnel that originates from LSRB's
outbound interface, terminates at LSRC's inbound interface, and passes through the
intermediate LSRD or is a direct link between LSRB's outbound interface and LSRC's
inbound interface.
Figure 3-30 Networking diagram for MPLS TE Auto FRR

NOTE


1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
interface3 interface2 interface3

LSRA LSRC
2.1.1.2/24 3.1.1.1/24 3.1.1.2/24
interface1 interface2 LSRB interface1
10.1.1.2/24 2.1.1.1/24 interface1 10.1.1.1/24
Loopback1 interface2
3.2.1.1/24 4.4.4.4/32 4.1.1.2/24
3.2.1.2/24 4.1.1.1/24
LSRD
Configuration Notes
None.
1. Configure a primary CR-LSP and enable MPLS Auto FRR in the MPLS and tunnel
interface views.
2. Set the protected bandwidth and priorities for the bypass CR-LSP in the tunnel interface
view.
Data Preparation
l OSPF process ID and OSPF area ID for every node
l Path for the primary CR-LSP
l Tunnel interface number, source and destination addresses of the primary tunnel, tunnel
ID, RSVP-TE signaling protocol, and tunnel bandwidth
Procedure
interface address as an LSR ID on every node shown in Figure 3-30. For configuration
Step 2 Configure OSPF to advertise every network segment route and host route.
Configure OSPF on all nodes to advertise host routes. For configuration details, see

node. All nodes have learned routes from one another.
# Configure LSRA.
[*LSRA] mpls
[*LSRA-mpls] quit
NOTE
Repeat this step for LSRB, LSRC, and LSRD. For configuration details, see Configuration Files in this
section.
Step 4 Configure OSPF TE.

# Configure LSRA.
[~LSRA] ospf
[~LSRA-ospf-1] opaque-capability enable
[~LSRA-ospf-1] quit
NOTE
Repeat this step for LSRB, LSRC, and LSRD. For configuration details, see Configuration Files in this
section.

Set the maximum reservable bandwidth and BC0 bandwidth both to 10 Mbit/s.
# Configure LSRA.
Repeat this step for LSRB, LSRC, and LSRD. For configuration details, see Configuration
Files in this section.
Step 6 Configure an explicit path for the primary CR-LSP.
[~LSRA] explicit-path master
[*LSRA-explicit-path-master] next hop 2.1.1.1
[*LSRA-explicit-path-master] next hop 3.1.1.1
[*LSRA-explicit-path-master] commit
[~LSRA-explicit-path-master] quit

Step 7 Configure TE Auto FRR.

# Configure LSRA.
[~LSRA] mpls
[~LSRA-mpls] mpls te auto-frr
[*LSRA-mpls] commit
[~LSRA-mpls] quit
# Configure LSRB.
[~LSRB] mpls
[~LSRB-mpls] mpls te auto-frr
[*LSRB-mpls] commit
[~LSRB-mpls] quit
Step 8 Configure a primary tunnel.

[~LSRA] interface tunnel2
[*LSRA-Tunnel2] ip address unnumbered interface loopback1
[*LSRA-Tunnel2] mpls te record-route label
[*LSRA-Tunnel2] mpls te path explicit-path master
[*LSRA-Tunnel2] mpls te priority 4 3
[*LSRA-Tunnel2] mpls te fast-reroute bandwidth
[*LSRA-Tunnel2] mpls te bypass-attributes bandwidth 200 priority 5 4

Run the display mpls te tunnel name Tunnel2 verbose command on LSRA. Information
about the primary and bypass CR-LSPs is displayed.
[~LSRA] display mpls te tunnel name Tunnel2 verbose
No : 1
TunnelIndex : -
LSR Role : Ingress
In-Interface : -
IncludeAllAff : 0x0
ER-Hop Table Index : 1 AR-Hop Table Index: 674
C-Hop Table Index : 579
PSB Handle : -
Created Time : 2015-01-28 11:10:32
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info


Bypass LSP ID : 165 FrrNextHop : 10.1.1.1
Bypass Attribute
IncludeAllGroup : 0
--------------------------------
BFD Information
--------------------------------
The primary CR-LSP has been bound to a bypass CR-LSP named AutoTunnel32866.
Run the display mpls te tunnel-interface auto-bypass-tunnel command. Detailed

information about the automatic bypass CR-LSP is displayed. Its bandwidth, and setup and
holding priorities are the same as bypass attributes in the primary CR-LSP information.
[~LSRA] display mpls te tunnel-interface auto-bypass-tunnel AutoTunnel32866
Tunnel Name : AutoTunnel32866
Tunnel Attributes :
Traffic Switch : -
Session ID : 32866
FTid : 130
Bfd Cap : None
Auto BW : Disabled Threshold : -
Current Collected BW: - Auto BW Freq : -
Min BW : - Max BW : -
Readjust Value : -
Offload Explicit Path Name: -
Tunnel Group : Primary
Interfaces Protected: GigabitEthernet2/0/0
Excluded IP Address : 2.1.1.1
2.1.1.2
2.2.2.2
Backup Tunnel : -
Group Status : Down Oam Status : None
IPTN InLabel : -


Ip-Prefix Name : -
PCE Delegate : No LSP Control Status : Local control
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Soft Preemption : Disabled
The automatic bypass CR-LSP protects traffic on GE 2/0/0, the outbound interface of the
primary CR-LSP, not other three interfaces. The bandwidth is 200 kbit/s, and the setup and
holding priority values are 5 and 4, respectively.
Run the display mpls te tunnel path command on LSRA. The bypass CR-LSP is providing
both node and bandwidth protection for the primary CR-LSP.
[~LSRA] display mpls te tunnel path
Lsp ID : 1.1.1.1 :200 :164
Hop Information
Hop 1 2.1.1.2 Label 32846
Hop 2 2.2.2.2 Label 32846
Hop 4 3.1.1.2 Label 3
Hop 5 3.3.3.3 Label 3

Lsp ID : 1.1.1.1 :32866 :165
Hop Information
Hop 0 10.1.1.2
Hop 1 10.1.1.1 Label 3
Hop 2 3.3.3.3 Label 3
Run the display mpls te tunnel name Tunnel2 verbose command on the transit LSRB.
Information about the primary and bypass CR-LSPs is displayed.
No : 1
Tunnel Interface Name : -
TunnelIndex : -

LSR Role : Transit

IncludeAllAff : 0x0
PSB Handle : -
Created Time : 2015-01-28 11:10:32
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass LSP ID : 6 FrrNextHop : 4.1.1.2
Bypass Attribute
IncludeAllGroup : 0
--------------------------------
BFD Information
--------------------------------
The primary CR-LSP has been bound to a bypass CR-LSP named AutoTunnel32865.
Run the display mpls te tunnel-interface auto-bypass-tunnel command. Detailed

information about the automatic bypass CR-LSP is displayed. Its bandwidth, and setup and
holding priorities are the same as bypass attributes in the primary CR-LSP information.
[~LSRB] display mpls te tunnel-interface auto-bypass-tunnel AutoTunnel32865
Tunnel Name : AutoTunnel32865
Tunnel Attributes :
Traffic Switch : -
Session ID : 32865
FTid : 97
Bfd Cap : None


Auto BW : Disabled Threshold : -
Current Collected BW: - Auto BW Freq : -
Min BW : - Max BW : -
Readjust Value : -
Offload Explicit Path Name: -
Tunnel Group : Primary
Interfaces Protected: GigabitEthernet2/0/0
Excluded IP Address : 3.1.1.1
3.1.1.2
Backup Tunnel : -
Group Status : Down Oam Status : None
IPTN InLabel : -
Ip-Prefix Name : -
PCE Delegate : No LSP Control Status : Local control

Entropy Label :None
IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Soft Preemption : Disabled
The automatic bypass CR-LSP protects traffic on GE 2/0/0, the outbound interface of the
primary CR-LSP. The bandwidth is 200 kbit/s, and the setup and holding priority values are 5
and 4, respectively.
Run the display mpls te tunnel path command on LSRB. Information about the path of both
primary CR-LSP and automatic bypass CR-LSP is displayed.
[~LSRB] display mpls te tunnel path


Lsp ID : 1.1.1.1 :200 :164
Hop Information
Hop 0 1.1.1.1
Hop 2 2.1.1.2 Label 32846
Hop 3 2.2.2.2 Label 32846
Hop 5 3.1.1.2 Label 3
Hop 6 3.3.3.3 Label 3

Lsp ID : 2.2.2.2 :32865 :6
Hop Information
Hop 0 3.2.1.1
Hop 1 3.2.1.2 Label 32839
Hop 2 4.4.4.4 Label 32839
Hop 3 4.1.1.1
Hop 4 4.1.1.2 Label 3
Hop 5 3.3.3.3 Label 3
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls te auto-frr
mpls te cspf
mpls rsvp-te
#
explicit-path master
next hop 2.1.1.1
next hop 3.1.1.1
#
ospf 1
area 0.0.0.0
mpls-te enable
network 10.1.1.0 0.0.0.255
network 2.1.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 2.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1

ip address 1.1.1.1 255.255.255.255

#
interface Tunnel2
destination 3.3.3.3
mpls te priority 4 3
mpls te path explicit-path master
mpls te fast-reroute bandwidth
mpls te bypass-attributes bandwidth 200 priority 5 4
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls te auto-frr
mpls te cspf
mpls rsvp-te
#
ospf 1
area 0.0.0.0
mpls-te enable
network 3.1.1.0 0.0.0.255
network 3.2.1.0 0.0.0.255
network 2.1.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
undo shutdown
ip address 3.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 3.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
return
#
sysname LSRC

#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
mpls-te enable
network 10.1.1.0 0.0.0.255
network 3.1.1.0 0.0.0.255
network 4.1.1.0 0.0.0.255
network 3.3.3.3 0.0.0.0
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 4.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 3.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
return
#
sysname LSRD
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
mpls-te enable
network 3.2.1.0 0.0.0.255
network 4.1.1.0 0.0.0.255
network 4.4.4.4 0.0.0.0
#
undo shutdown
mpls
ip address 4.1.1.1 255.255.255.0
mpls te
mpls rsvp-te
#

undo shutdown
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
Return
3.38.12 Example for Configuring MPLS Detour FRR

This section provides an example for configuring MPLS detour FRR on an RSVP-TE tunnel.
Traffic engineering (TE) fast reroute (FRR) provides local link and node protection for MPLS
TE tunnels. If a link or node fails, traffic is rapidly switched to a backup path, which
minimizes traffic loss. TE FRR is working in facility or one-to-one backup mode. TE FRR in
one-to-one backup mode is also called MPLS detour FRR. MPLS detour FRR automatically
creates a detour LSP on each eligible node along primary CR-LSP to protect downstream
links or nodes. This mode is easy to configure, eliminates manual network planning, and
provides flexibility on a complex network.
Figure 3-31 shows a primary RSVP-TE tunnel along the path LSRA -> LSRC -> LSRE. To
improve tunnel reliability, MPLS detour FRR must be configured.
NOTE
For information about how to configure TE FRR in facility backup mode, see 3.38.10 Example for
Configuring MPLS TE Manual FRR and 3.38.11 Example for Configuring MPLS TE Auto FRR.
Figure 3-31 MPLS detour FRR networking
LSRA LSRC LSRE

10.1.1.1/24 10.1.1.2/24 10.1.3.1/24 10.1.3.2/24
10.1.2.1/24 10.1.4.1/24 10.1.5.1/24
10.1.2.2/24 10.1.4.2/24 10.1.5.2/24

10.1.6.2/24 10.1.7.2/24
10.1.6.1/24 10.1.7.1/24
LSRB LSRD LSRF
Primary LSP Detour LSP

Table 3-18 Device names, interface names, and IP addresses
Device Interface IP Address Device Interface IP Address

Name Name Name Name
LSRA GE 1/0/1 10.1.1.1/24 LSRB GE 1/0/1 10.1.2.2/24
GE 1/0/2 10.1.2.1/24 GE 1/0/2 10.1.6.1/24
Loopback1 1.1.1.1/32 Loopback1 2.2.2.2/32
LSRC GE 1/0/1 10.1.1.2/24 LSRD GE 1/0/1 10.1.6.2/24
GE 1/0/2 10.1.4.1/24 GE 1/0/2 10.1.4.2/24
GE 1/0/3 10.1.3.1/24 GE 1/0/3 10.1.7.1/24
LSRE GE 1/0/1 10.1.3.2/24 LSRF GE 1/0/1 10.1.7.2/24
GE 1/0/2 10.1.5.1/24 GE 1/0/2 10.1.5.2/24
Precautions
l The facility backup and one-to-one backup modes are mutually exclusive on the same
TE tunnel interface. If both modes are configured, the latest configured mode overrides
the previous one.
l The shared explicit (SE) style must be used for the MPLS detour FRR-enabled tunnel.
l CSPF must be enabled on each node along both the primary and backup RSVP-TE
tunnels.
1. Configure an RSVP-TE tunnel.

2. Enable MPLS detour FRR on an RSVP-TE tunnel interface.
Data Preparation
l IP address of each interface on every node listed in Table 3-18

l IGP protocol (IS-IS), process ID (1), system ID (converted using loopback1 address),
and IS-IS level (level-2)
l LSR ID (loopback interface address) of every MPLS node
l Tunnel interface name (Tunnel1), tunnel IP address (loopback interface IP address),
tunnel ID (100), and destination IP address (5.5.5.5)

Procedure
Step 1 Assign an IP address and a mask to each interface.
Assign an IP address to each interface according to Table 3-18 and create a loopback
interface on each node. For detailed configurations, see Configuration Files in this section.
Step 2 Configure IS-IS to advertise the route to each network segment to which each interface is
connected and to advertise the host route to each loopback address that is used as an LSR ID.
Configure IS-IS on each node to implement network layer connectivity. For detailed
configurations, see Configuration Files in this section.
Step 3 Enable MPLS, MPLS TE, MPLS RSVP-TE, and CSPF globally on each node.
# Configure LSRA.
<LSRA> system-view
[*LSRA] mpls
[*LSRA-mpls] commit
[~LSRA-mpls] quit
Repeat this step for LSRB, LSRC, LSRD, LSRE, and LSRF. For detailed configurations, see
Step 4 Enable IGP TE on each node.
# Configure LSRA.
[~LSRA] isis 1
[~LSRA-isis-1] quit
Step 5 Enable RSVP-TE on interfaces of each node.
# Configure LSRA.
[~LSRA-GigabitEthernet1/0/1] mpls
Step 6 Configure an RSVP-TE tunnel interface on LSRA (ingress).
# Configure LSRA.


Step 7 Enable MPLS detour FRR on the RSVP-TE tunnel interface.

# Configure LSRA.
[*LSRA-Tunnel1] mpls te detour
Step 8 Verify the configurations.

After completing the configurations, run the display mpls te tunnel command on LSRA to
view detour LSP information.
* means the LSP is detour LSP
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1 5.5.5.5 25 -/32832 I Tunnel1
1.1.1.1 5.5.5.5 25 *-/32831 I Tunnel1
-------------------------------------------------------------------------------
Run the display mpls te tunnel path command on LSRA to view the primary CR-LSP and
detour LSP information. The command output shows that a detour LSP has been established
to provide node protection on LSRA, and another detour LSP has been established to provide
link protection on LSRC.
[~LSRA] display mpls te tunnel path
Lsp ID : 1.1.1.1 :100 :25
Hop Information
Hop 0 10.1.1.1 Local-Protection available | node
Hop 1 10.1.1.2 Label 32832
Hop 2 3.3.3.3 Label 32832
Hop 4 10.1.3.2 Label 3
Hop 5 5.5.5.5 Label 3

Lsp ID : 1.1.1.1 :100 :25
Detour Lsp PLR ID :10.1.2.1
Hop Information
Hop 0 10.1.2.1
Hop 1 10.1.2.2 Label 32831
Hop 2 2.2.2.2 Label 32831
Hop 3 10.1.6.1
Hop 4 10.1.6.2 Label 32832
Hop 5 4.4.4.4 Label 32832
Hop 6 10.1.7.1
Hop 7 10.1.7.2 Label 32831
Hop 8 6.6.6.6 Label 32831
Hop 9 10.1.5.2
Hop 10 10.1.5.1 Label 3
Hop 11 5.5.5.5 Label 3
----End
Configuration Files
#
sysname LSRA

#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0010.0100.1001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 5.5.5.5
mpls te detour
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0020.0200.2002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#

undo shutdown
ip address 10.1.6.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0030.0300.3003.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
#
sysname LSRD
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
mpls te cspf

#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0040.0400.4004.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.6.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.7.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return
#
sysname LSRE
#
mpls lsr-id 5.5.5.5
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0050.0500.5005.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te

#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
l LSRF configuration file

#
sysname LSRF
#
mpls lsr-id 6.6.6.6
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0060.0600.6006.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.5.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.7.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
isis enable 1
#
return
3.38.13 Example for Configure a Hot-standby CR-LSP
Figure 3-32 illustrates an MPLS VPN network. A TE tunnel is established from PE1 to PE2.
A hot-standby CR-LSP and a best-effort path are configured. The networking is as follows:
l The primary CR-LSP is along the path PE1 -> P1 -> PE2.
l The hot-standby CR-LSP is along the path PE1 -> P2 -> PE2.
If 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 after a 15-second delay. If both
the primary and backup CR-LSPs 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 PE1 -> P2 -> P1 -> PE2. The calculated
best-effort path varies according to the faulty node.

Figure 3-32 Networking diagram for a hot-standby CR-LSP

NOTE
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
P1 10.1.1.1/30 10.1.1.2/30 P2
interface2 10.2.1.1/30 10.3.1.2/30 interface2
10.4.1.2/30 10.5.1.1/30
10.4.1.1/30 10.5.1.2 /30
PE1 PE2
10.3.1.1/30 10.2.1.2/30
Loopback1 Loopback1
4.4.4.4/32 3.3.3.3/32
: Primary path
: Backup path
: Best-effort path
Configuration Notes
None.
1. Assign an IP address to every interface and configure an IGP to implement connectivity.

2. Configure basic MPLS and MPLS TE functions.
3. Configure explicit paths on PE1 for the primary and hot-standby CR-LSPs.
4. Create a tunnel destined for PE2; specify explicit paths; enable hot standby; configure a
best-effort path; set the switchback delay time to 15 seconds on PE1.
Data Preparation
l IGP type and data

l MPLS LSR IDs

l Bandwidth attributes
l Tunnel interface number and bandwidth
l Explicit paths for the primary and hot-standby CR-LSPs
Procedure
Assign an IP address and its mask to every interface and configure a loopback interface
address as an LSR ID on every node. For configuration details, see Configuration Files in
this section.
Configure OSPF or IS-IS on every node to implement connectivity between them. IS-IS is
used in this example. For configuration details, see Configuration Files in this section.
Step 3 Configure basic MPLS functions.
Set an LSR ID in the system view, and enable MPLS in the system and interface views on
every node. For configuration details, see Configuration Files in this section.
Enable MPLS TE and RSVP-TE in the MPLS and interface views on every node. Set the
maximum reservable bandwidth to 100 Mbit/s.And set the BC0 bandwidth to 50 Mbit/s. For
Step 5 Configure IS-IS TE and CSPF.
Configure IS-IS TE on all nodes and enable CSPF on PE1. For information about the
configuration procedure, see Configuring an RSVP-TE Tunnel.
Step 6 Configure explicit paths for the primary and hot-standby CR-LSPs.
# Configure an explicit path for the primary CR-LSP on PE1.
<PE1> system-view
[~PE1] explicit-path main
[*PE1-explicit-path-main] next hop 10.4.1.2
[*PE1-explicit-path-main] quit
# Configure an explicit path for the hot-standby CR-LSP on PE1.

[*PE1] explicit-path backup
[*PE1-explicit-path-backup] next hop 10.3.1.2
[*PE1-explicit-path-backup] commit
[~PE1-explicit-path-backup] quit
# After completing the configurations, run the display explicit-path main command on PE1.
Information about the explicit paths for the primary and hot-standby CR-LSPs is displayed.
[~PE1] display explicit-path main
Path Name : main Path Status : Enabled
1 10.4.1.2 Strict Include
[~PE1] display explicit-path backup
Path Name : backup Path Status : Enabled


Step 7 Configure tunnel interfaces.

# Create a tunnel interface; specify an explicit path; set the tunnel bandwidth to 10 Mbit/s on
PE1.
[~PE1] interface tunnel 1
[*PE1-Tunnel1] ip address unnumbered interface loopback 1
[*PE1-Tunnel1] tunnel-protocol mpls te
[*PE1-Tunnel1] destination 3.3.3.3
[*PE1-Tunnel1] mpls te tunnel-id 502
[*PE1-Tunnel1] mpls te path explicit-path main
[*PE1-Tunnel1] mpls te bandwidth ct0 10000
# Configure hot standby on the tunnel interface; set the switchback delay time to 15 seconds;
specify an explicit path; configure a best-effort path.
[*PE1-Tunnel1] mpls te backup hot-standby wtr 15
[*PE1-Tunnel1] mpls te path explicit-path backup secondary
[*PE1-Tunnel1] mpls te backup ordinary best-effort
[~PE1-Tunnel1] quit
After completing the configurations, run the display mpls te tunnel-interface tunnel1
command on PE1. Both the primary and hot-standby CR-LSPs have been established.
[~PE1] display mpls te tunnel-interface tunnel1
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -
Backup Tunnel : -
-


Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
# Run the display mpls te hot-standby state command on PE1. Hot standby information is
displayed.
[~PE1] display mpls te hot-standby state interface tunnel1
----------------------------------------------------------------
----------------------------------------------------------------
Session ID : 502
Main LSP index : 0xC1
Hot-Standby LSP index : 0xE1
HSB switch result : main LSP
HSB switch reason : -
WTR remain time : -
# Run the ping lsp te command. The hot-standby CR-LSP is reachable.

[~PE1] ping lsp te tunnel1 hot-standby
LSP PING FEC: RSVP IPV4 SESSION QUERY Tunnel1 : 100 data bytes, press CTR
L_C to break
--- FEC: RSVP IPV4 SESSION QUERY Tunnel1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 3/3/6 ms
# Run the tracert lsp te command on PE1. The path for the hot-standby CR-LSP is reachable.
[*PE1] tracert lsp te tunnel1 hot-standby
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1 , press CTRL_C to
break.
TTL Replier Time Type Downstream
0 Ingress 10.3.1.2/[13313 ]
1 10.3.1.2 90 ms Transit 10.5.1.2/[3 ]
2 3.3.3.3 130 ms Egress

Connect Port1 and Port2 on a tester to PE1 and PE2, respectively; set correct labels; inject
MPLS traffic destined for Port 2 into Port 1. After the cable is removed from GE 2/0/0 on PE1
or GE 2/0/0 on P1, traffic is restored within milliseconds. Run the display mpls te hot-
standby state interface tunnel1 command on PE1. Traffic has switched to the hot-standby
CR-LSP.
[~PE1] display mpls te hot-standby state interface tunnel1
----------------------------------------------------------------
----------------------------------------------------------------
Session ID : 502
Main LSP index : 0x0
Hot-Standby LSP index : 0xE1
HSB switch result : hot-standby LSP
HSB switch reason : signal fail
WTR remain time : -
Insert the cable into GE 2/0/0 and wait 15 seconds. Traffic switches back to the primary CR-
LSP.
If the cables to GE 2/0/0 on PE1 (or GE 2/0/0 on P1) and PE2 (or P2) are removed, the tunnel
interface goes Down and then Up. A best-effort path is established and takes over traffic.
[~PE1] display mpls te tunnel-interface tunnel1
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -

Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
[~PE1] display mpls te tunnel path
Lsp ID : 4.4.4.4 :502 :32776
Hop Information
Hop 0 10.3.1.1
Hop 1 10.3.1.2
Hop 2 2.2.2.2
Hop 3 10.1.1.2
Hop 4 10.1.1.1
Hop 5 1.1.1.1
Hop 6 10.2.1.1
Hop 7 10.2.1.2
Hop 8 3.3.3.3
----End

Configuration Files
#
sysname PE1
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
explicit-path backup
next hop 10.3.1.2
next hop 10.5.1.2
next hop 3.3.3.3
#
explicit-path main
next hop 10.4.1.2
next hop 10.2.1.2
next hop 3.3.3.3
#
isis 1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.4.1.1 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface Tunnel1
tunnel-protocol mpls
te
destination
3.3.3.3
mpls te record-
route
mpls te bandwidth ct0
10000
mpls te backup hot-standby wtr
15
mpls te backup ordinary best-
effort
mpls te path explicit-path
main

mpls te path explicit-path backup

secondary
#
return
l P1 configuration file
#
sysname P1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.4.1.2 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.1 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
isis enable 1
ip address 1.1.1.1 255.255.255.255
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.252

mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.5.1.1 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.3.1.2 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.5.1.2 255.255.255.252
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

3.38.14 Example for Configuring a 1:1 Tunnel Protection Group

Consisting of Bidirectional Co-routed CR-LSPs
This section provides an example for configuring a 1:1 tunnel protection group consisting of
static bidirectional co-routed CR-LSPs. A tunnel protection group provides end-to-end
protection for MPLS TE traffic if a network fault occurs.
A tunnel protection group consists of static bidirectional co-routed CR-LSPs. If the working
tunnel fails, switches traffic to the protection tunnel, which helps improve network reliability.
On the MPLS network shown in Figure 3-33, a working tunnel is established over the path
LSRA -> LSRB -> LSRC, and a protection tunnel is established over the path LSRA ->
LSRD -> LSRC. To ensure that MPLS TE traffic is not interrupted if a fault occurs, configure
static bidirectional co-routed CR-LSPs for both the working and protection tunnels and
combine them into a tunnel protection group.
Figure 3-33 Networking diagram for a 1:1 tunnel protection group consisting of static
bidirectional co-routed CR-LSPs
NOTE
Loopback1
2.2.2.2/32
1 inte
Loopback1 t e r face 4 r
3.2. face2 Loopback1
1 in .2 /2 1 .1 / inte
1.1.1.1/32 terface 4 2.1.1 24
3 .2 .
rfac 3.3.3.3/32
e
in 2 1 .2 / 1
1 .1 /
2 .1 . LSRB 24
in e2
LSRA 4 terface t e rfac 4 LSRC
.1 .1 2 in 2
.1 /2 inte 1 .2 /
4 r
4.1. face1 r fa c
e2 3 .4 .
1 .2 / inte .1/24
24 1
3 .4 .
Loopback1 Working tunnel
4.4.4.4/32 Protection tunnel
LSRD
1. Assign an IP address to each interface and configure a routing protocol.

2. Configure basic MPLS functions and enable MPLS TE.
3. Set MPLS TE bandwidth attributes for links.
4. Configure the ingress, transit nodes, and egress for each static bidirectional co-routed
CR-LSP.

5. Configure MPLS TE tunnel interfaces for the working and protection tunnels and bind a
specific static bidirectional co-routed CR-LSP to each tunnel interface.
6. Configure a tunnel protection group.
7. Configure a detection mechanism to monitor the configured tunnel protection group.
MPLS-TP OAM is used in this example.
Data Preparation
l Tunnel interface's name and IP address, destination address, tunnel ID, and static CR-
LSP signaling on LSRA and LSRC
l Maximum reservable bandwidth and BC bandwidth of each link
l Next-hop address and outgoing label on the ingress
l Inbound interface, next-hop address, and outgoing label on the transit node
l Inbound interface on the egress
Procedure
Step 1 Assign an IP address to each interface and configure a routing protocol.
# Assign an IP address and a mask to each interface and configure static routes so that all
LSRs can interconnect with each other.
Step 2 Configure basic MPLS functions and enable MPLS TE.
# Configure LSRA.
[*LSRA] mpls
[*LSRA-mpls] quit
Repeat this step for LSRB, LSRC, and LSRD.

outbound interface of each LSR. The BC0 bandwidth of links must be greater than the tunnel
bandwidth (10 Mbit/s).
# Configure LSRA.
[*LSRA-GigabitEthernet1/0/1] mpls te bandwidth max-reservable-bandwidth 100000


# Configure LSRB.
# Configure LSRC.
# Configure LSRD.
[~LSRD-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[*LSRD-GigabitEthernet1/0/1] mpls te bandwidth max-reservable-bandwidth 100000
Step 4 Configure the ingress, transit nodes, and egress for each static bidirectional co-routed CR-
LSP.
# Configure LSRA as the ingress on both the working and protection static bidirectional co-
routed CR-LSPs.
[~LSRA] bidirectional static-cr-lsp ingress Tunnel 10
ct0 10000
[*LSRA-bi-static-ingress-Tunnel10] quit
[*LSRA] bidirectional static-cr-lsp ingress Tunnel 20
ct0 10000
[*LSRA-bi-static-ingress-Tunnel20] commit
[~LSRA-bi-static-ingress-Tunnel20] quit
# Configure LSRB as a transit node on the working static bidirectional co-routed CR-LSP.
[~LSRB]bidirectional static-cr-lsp transit lsp1
[*LSRB-bi-static-transit-lsp1] forward in-label 20 nexthop 3.2.1.2 out-label 40
bandwidth ct0 10000
[*LSRB-bi-static-transit-lsp1] backward in-label 16 nexthop 2.1.1.1 out-label 20
bandwidth ct0 10000
[*LSRB-bi-static-transit-lsp1] commit
[~LSRB-bi-static-transit-lsp1] quit
# Configure LSRD as a transit node on the protection static bidirectional co-routed CR-LSP.
[~LSRD]bidirectional static-cr-lsp transit lsp2
[*LSRD-bi-static-transit-lsp2] forward in-label 21 nexthop 3.4.1.2 out-label 41

bandwidth ct0 10000

[*LSRD-bi-static-transit-lsp2] backward in-label 17 nexthop 4.1.1.1 out-label 21
bandwidth ct0 10000
[*LSRD-bi-static-transit-lsp2] commit
[~LSRD-bi-static-transit-lsp2] quit
# Configure LSRC as the egress on both the working and protection static bidirectional co-
routed CR-LSPs.
[~LSRC] bidirectional static-cr-lsp egress lsp1
[*LSRC-bi-static-egress-lsp1] forward in-label 40 lsrid 1.1.1.1 tunnel-id 100
[*LSRC-bi-static-egress-lsp1] backward nexthop 3.2.1.1 out-label 16 bandwidth ct0
10000
[*LSRC-bi-static-egress-lsp1] quit
[*LSRC] bidirectional static-cr-lsp egress lsp2
[*LSRC-bi-static-egress-lsp2] forward in-label 41 lsrid 1.1.1.1 tunnel-id 101
[*LSRC-bi-static-egress-lsp2] backward nexthop 3.4.1.1 out-label 17 bandwidth ct0
10000
[*LSRC-bi-static-egress-lsp2] commit
[~LSRC-bi-static-egress-lsp2] quit
Step 5 Configure MPLS TE tunnel interfaces for the working and protection tunnels and bind a
specific static bidirectional co-routed CR-LSP to each tunnel interface.
# On LSRA, configure MPLS TE tunnel interfaces named Tunnel 10 and Tunnel 11.
[*LSRA-Tunnel10] quit
[*LSRA] interface Tunnel 11
# On LSRC, configure MPLS TE tunnel interfaces named Tunnel 20 and Tunnel 21.
[*LSRC-Tunnel20] mpls te passive-tunnel
[*LSRC-Tunnel20] mpls te binding bidirectional static-cr-lsp egress lsp1
[*LSRC-Tunnel20] quit
[*LSRC] interface Tunnel 21
[*LSRC-Tunnel21] mpls te passive-tunnel
[*LSRC-Tunnel21] mpls te binding bidirectional static-cr-lsp egress lsp2
Step 6 Configure a tunnel protection group.

# On LSRA, configure a tunnel protection group that consists of a working tunnel named
Tunnel 10 and its protection tunnel named Tunnel 11.


[~LSRA-Tunnel10] mpls te protection tunnel 101 mode revertive wtr 0
# On LSRC, configure a tunnel protection group that consists of a working tunnel named
Tunnel 20 and its protection tunnel named Tunnel 21.
[~LSRC-Tunnel20] mpls te protection tunnel 201 mode revertive wtr 0
Step 7 Configure a detection mechanism to monitor the configured tunnel protection group. MPLS-
TP OAM is used in this example.
On LSRA, configure MPLS-TP OAM on Tunnel10:

[~LSRA] mpls-tp meg abc
[~LSRA-Tunnel10] me te interface Tunnel 10 mep-id 1 remote-mep-id 2
On LSRC, configure MPLS-TP OAM on Tunnel20:

[~LSRC] mpls-tp meg abc
[~LSRC-Tunnel20] me te interface Tunnel 20 mep-id 2 remote-mep-id 1
After completing the configuration, run the display mpls te protection tunnel all verbose
command on LSRA. The command output shows that the tunnel interfaces are working
properly.
[~LSRA] display mpls te protection tunnel all verbose
----------------------------------------------------------------
Verbose information about the No."1" protection-group
----------------------------------------------------------------
Work-tunnel id : 100
Protect-tunnel id : 101
Work-tunnel name : Tunnel10
Protect-tunnel name : Tunnel11
Work-tunnel reverse-lsp : -
Protect-tunnel reverse-lsp : -
Bridge type : 1:1
Switch type : bidirectional
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 config time : 0s
WTR remain time : -
Mode : revertive
Using same path : -
Local state : no request
Far end request : no request
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
#
#
undo shutdown
ip address 2.1.1.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 4.1.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel10
destination 3.3.3.3
mpls te protection tunnel 101 mode revertive wtr 0
#
interface Tunnel11
destination 3.3.3.3
#
ip route-static 2.2.2.2 255.255.255.255 2.1.1.2
ip route-static 3.3.3.3 255.255.255.255 2.1.1.2
ip route-static 3.3.3.3 255.255.255.255 4.1.1.2
ip route-static 4.4.4.4 255.255.255.255 4.1.1.2
#
mpls-tp meg Tunnel10
me te interface Tunnel10 mep-id 1 remote-mep-id 2
#
return

#
sysname LSRB
#

mpls lsr-id 2.2.2.2

#
mpls
mpls te
#
#
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 3.2.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 2.1.1.1
ip route-static 3.3.3.3 255.255.255.255 3.2.1.2
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
#
bidirectional static-cr-lsp egress lsp1
#
bidirectional static-cr-lsp egress lsp2
#
undo shutdown
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 3.4.1.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Tunnel20


destination 1.1.1.1
mpls te binding bidirectional static-cr-lsp egress lsp1
mpls te protection tunnel 201 mode revertive wtr 0
#
interface Tunnel21
destination 1.1.1.1
mpls te binding bidirectional static-cr-lsp egress lsp2
#
ip route-static 1.1.1.1 255.255.255.255 3.2.1.1
ip route-static 1.1.1.1 255.255.255.255 3.4.1.1
ip route-static 2.2.2.2 255.255.255.255 3.2.1.1
ip route-static 4.4.4.4 255.255.255.255 3.4.1.1
#
mpls-tp meg Tunnel20
me te interface Tunnel20 mep-id 2 remote-mep-id 1
#
return
#
sysname LSRD
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
#
##
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 4.1.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 3.4.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 4.1.1.1
ip route-static 3.3.3.3 255.255.255.255 3.4.1.2

#
return
3.38.15 Example for Configuring Isolated LSP Computation

This section provides an example for configuring isolated label switched path (LSP)
computation.
Isolated primary and hot-standby LSPs are necessary to improve the LSP reliability on IP
radio access networks (IP RANs) that use Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE). The constrained shortest path first (CSPF) algorithm does not meet this
reliability requirement because CSPF may compute two LSPs that intersect at aggregation
nodes. Specifying explicit paths for LSPs can improve reliability but this method does not
adapt to topology changes. Each time a node is added to or deleted from the IP RAN,
operators must configure new explicit paths, which is time-consuming and laborious. Isolated
LSP computation is another method to improve reliability. After this function is configured,
the device uses both the disjoint and CSPF algorithms to compute isolated primary and hot-
standby LSPs.
Figure 3-34 illustrates an IP RAN that uses a Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) tunnel. Devices on this network use the Open Shortest Path First
(OSPF) protocol for communication. The numeral on each link represents the link TE metric.
An RSVP-TE tunnel needs to be established between LSRA and LSRF. The constraint-based
routed label switched path (CR-LSP) hot standby function needs to be enabled.
Two isolated LSPs exist on this topology: LSRA -> LSRC -> LSRE -> LSRF and LSRA ->
LSRB -> LSRD -> LSRF. However, if the disjoint algorithm is not enabled, CSPF computes
LSRA -> LSRC-> LSRD-> LSRF as the primary LSP and cannot compute an isolated hot-
standby LSP. To improve LSP reliability, configure isolated LSP computation.
Figure 3-34 RSVP-TE tunnel networking

LSRC
10.1.1.2/24 10.1.4.1/24
1 5
LSRA10.1.1.1/24 10.1.3.1/24
10.1.4.2/24 LSRE
1
10.1.2.1/24 RSV 10.1.5.1/24
NodeB P-TE
10 Tunn 10
e l
10.1.2.2/24 10.1.5.2/24
10.1.3.2/24
LSRB 10 LSRF
10.1.6.1/24 1 10.1.7.2/24 RNC
10.1.6.2/24 10.1.7.1/24
LSRD

Table 3-19 Interfaces and IP addresses

Name Name Name Name
LSRA Loopback1 1.1.1.1/32 LSRB Loopback1 2.2.2.2/32
GE 1/0/0 10.1.1.1/24 GE 1/0/0 10.1.2.2/24
GE 1/0/1 10.1.2.1/24 GE 1/0/1 10.1.6.1/24
LSRC Loopback1 3.3.3.3/32 LSRD Loopback1 4.4.4.4/32
GE 1/0/0 10.1.1.2/24 GE 1/0/0 10.1.6.2/24
GE 1/0/1 10.1.3.1/24 GE 1/0/1 10.1.3.2/24
GE 1/0/2 10.1.4.1/24 GE 1/0/2 10.1.7.1/24
LSRE Loopback1 5.5.5.5/32 LSRF Loopback1 6.6.6.6/32
GE 1/0/0 10.1.4.2/24 GE 1/0/0 10.1.7.2/24
GE 1/0/1 10.1.5.1/24 GE 1/0/1 10.1.5.2/24
1. Set addresses for all physical and loopback interfaces listed in Table 3-19.
2. Globally enable OSPF on each device so that OSPF advertises segment routes of each
physical and loopback interface. Enable OSPF TE in the area where the devices reside.
3. Set MPLS label switching router (LSR) IDs for all devices and globally enable MPLS,
TE, RSVP-TE, and CSPF.
4. Enable MPLS, TE, and RSVP-TE on the outbound interfaces of all links along the TE
tunnel. Set a TE metric for each link according to Figure 3-34.
5. Create a tunnel interface on LSRA and specify the IP address, tunnel protocol,
destination address, tunnel ID, and signaling protocol for the tunnel interface.
6. Enable the CR-LSP hot standby function and the disjoint algorithm on the tunnel
interface.
Data Preparation
l IP address for each interface (see Table 3-19.)

l OSPF process ID (1) and area ID (0.0.0.0)
l TE metric for each link (see Figure 3-34.)
l Loopback interface address for each MPLS LSR ID
l Tunnel interface number (Tunnel1), tunnel ID (1), loopback interface address to be
borrowed, destination address (6.6.6.6), and signaling protocol (RSVP-TE)

Procedure
Step 1 Assign an IP address to each interface.
Assign an IP address to each interface and create a loopback interface on each device. For
detailed configurations, see Table 3-19.
Step 2 Enable OSPF on each device.
Enable basic OSPF functions and MPLS TE on each device.
# Configure LSRA.
[~LSRA] ospf 1
[*LSRA-ospf-1] opaque-capability enable
[*LSRA-ospf-1] area 0.0.0.0
[*LSRA-ospf-1-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[~LSRA-ospf-1] quit
Repeat this step for LSRB, LSRC, LSRD, LSRE, and LSRF. For configuration details, see
Enable MPLS, MPLS TE, RSVP-TE, and CSPF on each device. Enable MPLS, TE, and
RSVP-TE on the outbound interface of each link. Set a TE metric for each link.
# Configure LSRA.
[*LSRA] mpls
[*LSRA-mpls] quit
[*LSRA-GigabitEthernet1/0/0] mpls te metric 1
[*LSRA-GigabitEthernet1/0/1] mpls te metric 10
[*LSRA] commit
Repeat this step for LSRB, LSRC, LSRD, LSRE, and LSRF. For configuration details, see
Step 4 Configure an MPLS TE tunnel interface.
# Configure LSRA.
[~LSRA] interface tunnel1
[*LSRA-Tunnel1] ip address unnumbered interface LoopBack1
[*LSRA-Tunnel1] mpls te signal-protocol rsvp-te

Step 5 Configure isolated LSP computation.

Enable the CR-LSP hot standby feature and then the disjoint algorithm on the tunnel
interface.
# Configure LSRA.
[~LSRA-Tunnel1] mpls te backup hot-standby
[*LSRA-Tunnel1] mpls te cspf disjoint

# Run the display mpls te cspf destination 6.6.6.6 computation-mode disjoint command on
LSRA. The command output shows that the primary LSP is LSRA -> LSRC -> LSRE ->
LSRF and the hot-standby LSP is LSRA-> LSRB-> LSRD-> LSRF. The two LSPs do not
intersect.
[~LSRA] display mpls te cspf destination 6.6.6.6 computation-mode disjoint
Main path for the given constraints is:
10.1.1.1 Include
10.1.1.2 Include
10.1.4.1 Include
10.1.4.2 Include
10.1.5.1 Include
10.1.5.2 Include
The total metrics of the calculated path is : 16
Hot-standby path for the given constraints is:

10.1.2.1 Include
10.1.2.2 Include
10.1.6.1 Include
10.1.6.2 Include
10.1.7.1 Include
10.1.7.2 Include
Complete disjoint path computed and the total metrics of the calculated path
is : 21
# Run the display mpls te tunnel-interface Tunnel1 and display mpls te tunnel path
Tunnel1 commands on LSRA to view information about the primary and hot-standby LSPs.
[~LSRA] display mpls te tunnel-interface Tunnel1
Tunnel Attributes :
Traffic Switch : -
Session ID : 1
FTid : 1
Bfd Cap : None
Readjust Value : -
Tunnel Group : -

Backup Tunnel : -
-
Ip-Prefix Name : -
Entropy Label :None

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
FRR Flag : Disabled
IdleTime Remain : -
BFD Status : -
Pce Flag : Normal
[~LSRA] display mpls te tunnel path Tunnel1
Lsp ID : 1.1.1.1 :1 :2
Hop Information
Hop 0 10.1.1.1
Hop 1 10.1.1.2
Hop 2 3.3.3.3
Hop 3 10.1.4.1
Hop 4 10.1.4.2
Hop 5 5.5.5.5
Hop 6 10.1.5.1
Hop 7 10.1.5.2
Hop 8 6.6.6.6


Lsp ID : 1.1.1.1 :1 :3
Hop Information
Hop 0 10.1.2.1
Hop 1 10.1.2.2
Hop 2 2.2.2.2
Hop 3 10.1.6.1
Hop 4 10.1.6.2
Hop 5 4.4.4.4
Hop 6 10.1.7.1
Hop 7 10.1.7.2
Hop 8 6.6.6.6
The command outputs show that the computed primary and hot-standby LSPs are the same as
the actual primary and hot-standby LSPs, indicating that the device has computed two isolated
LSPs.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls te metric 1
mpls rsvp-te
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
mpls
mpls te
mpls te metric 10
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 6.6.6.6
mpls te backup hot-standby
mpls te tunnel-id 1
mpls te cspf disjoint
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255

mpls-te enable
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.6.1 255.255.255.0
mpls
mpls te
mpls te metric 10
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.6.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
mpls
mpls te
mpls te metric 1
mpls rsvp-te
#

undo shutdown
ip address 10.1.4.1 255.255.255.0
mpls
mpls te
mpls te metric 5
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.3.0 0.0.0.255
network 10.1.4.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.6.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.7.1 255.255.255.0
mpls
mpls te
mpls te metric 1
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.1.3.0 0.0.0.255
network 10.1.6.0 0.0.0.255
network 10.1.7.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRE
#
mpls lsr-id 5.5.5.5
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.4.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.1 255.255.255.0
mpls
mpls te
mpls te metric 10
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 10.1.4.0 0.0.0.255
network 10.1.5.0 0.0.0.255
mpls-te enable
#
return
#
sysname LSRF
#
mpls lsr-id 6.6.6.6
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.7.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
#
ospf 1
area 0.0.0.0
network 6.6.6.6 0.0.0.0

network 10.1.5.0 0.0.0.255

network 10.1.7.0 0.0.0.255
mpls-te enable
#
return
3.38.16 Example for Configuring Static BFD for CR-LSP

By configuring static BFD for CR-LSP, enable a device to switch traffic to the backup CR-
LSP if the primary CR-LSP fails. When the primary CR-LSP recovers, the traffic can switch
back from the backup CR-LSP to the primary CR-LSP.
Figure 3-35 illustrates CR-LSP hot standby. A TE tunnel between PE1 and PE2 is
established. The tunnel is enabled with hot standby and configured with the best-effort path.
Where,
l The primary CR-LSP is PE1 → P1 → PE2.
l The backup CR-LSP is PE1 → P2 → PE2.
If 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 after a 15-second delay. If both
the primary and backup CR-LSPs 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 PE1 -> P2 -> P1 -> PE2. The calculated
best-effort path varies according to the faulty node.
Two static BFD sessions are established to monitor the primary and backup CR-LSPs. After
the configuration, the following objects are achieved:
l If the primary CR-LSP fails, traffic switches to the backup CR-LSP.
l If the primary CR-LSP recovers and the backup CR-LSP fails during the switchover time
(15s), traffic switches back to the primary CR-LSP.
Figure 3-35 Networking diagram for CR-LSP hot standby

NOTE

Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
P1 10.1.1.1/30 10.1.1.2/30 P2
10.4.1.2/30 10.5.1.1/30
10.4.1.1/30 10.5.1.2 /30
PE1 PE2
10.3.1.1/30 10.2.1.2/30
Loopback1 Loopback1
4.4.4.4/32 3.3.3.3/32
: Primary path
: Backup path
: Best-effort path
Configuration Notes
None.
1. Configure CR-LSP hot standby.
2. Configure reverse CR-LSPs for a BFD session.
NOTE
A reverse CR-LSP must be established for each of the primary and hot-standby CR-LSPs.
3. On PE1, establish two BFD sessions and bind one to the primary CR-LSP and the other
to the hot-standby CR-LSP; on PE2, establish two BFD sessions and bind both sessions
to the IP link (PE2 → PE1).
4. On PE1, establish two BFD sessions and bind the two sessions to the primary and hot-
standby CR-LSPs separately; on PE2, establish two BFD sessions and bind each session
to a reverse CR-LSP for each forward CR-LSP.
Data Preparation
l Name of a BFD session

l Local and remote discriminators of BFD sessions

l Minimum intervals at which BFD packets are sent and received
l Other data as described in the section "Example for Configuring CR-LSP Hot Standby"
in HUAWEI NetEngine40E Universal Service Router Configuration Guide - MPLS.
Procedure
Step 1 Configure CR-LSP hot standby.
NOTE
For configuration details, see the section "Example for Configuring CR-LSP Hot Standby" in HUAWEI
NetEngine40E Universal Service Router Configuration Guide - MPLS.
Step 2 Configure reverse CR-LSPs.

The reverse CR-LSP configuration on PE2 is similar to the forward CR-LSP configuration on
PE1. For configuration details, see Configuration Files in this section.
Step 3 Configure BFD for CR-LSP.
# Establish BFD sessions between PE1 and PE2 to monitor the primary and backup CR-LSPs.
Bind the BFD sessions on PE1 to the primary and backup CR-LSP and the BFD session on
PE2 to the IP link. Set the minimum interval at which BFD packets are sent and received to
100 milliseconds and the local BFD detection multiplier to 3.
# Configure PE1.
<HUAWEI> system-view
[~HUAWEI] sysname PE1
[*HUAWEI] commit
[*PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd mainlsptope2 bind mpls-te interface tunnel 1 te-lsp
[*PE1-bfd-lsp-session-mainlsptope2] discriminator local 413
[*PE1-bfd-lsp-session-mainlsptope2] discriminator remote 314
[*PE1-bfd-lsp-session-mainlsptope2] min-tx-interval 100
[*PE1-bfd-lsp-session-mainlsptope2] min-rx-interval 100
[*PE1-bfd-lsp-session-mainlsptope2] process-pst
[*PE1-bfd-lsp-session-mainlsptope2] quit
[*PE1] bfd backuplsptope2 bind mpls-te interface tunnel 1 te-lsp backup
[*PE1-bfd-lsp-session-backuplsptope2] discriminator local 423
[*PE1-bfd-lsp-session-backuplsptope2] discriminator remote 324
[*PE1-bfd-lsp-session-backuplsptope2] min-tx-interval 100
[*PE1-bfd-lsp-session-backuplsptope2] min-rx-interval 100
[*PE1-bfd-lsp-session-backuplsptope2] process-pst
[*PE1-bfd-lsp-session-backuplsptope2] commit
[~PE1-bfd-lsp-session-backuplsptope2] quit
# Configure PE2.
<HUAWEI> system-view
[~HUAWEI] sysname PE2
[*HUAWEI] commit
[*PE2] bfd
[*PE2-bfd] quit
[*PE2] bfd mainlsptope2 bind mpls-te interface Tunnel 2 te-lsp
[*PE2-bfd-lsp-session-mainlsptope2] discriminator local 314
[*PE2-bfd-lsp-session-mainlsptope2] discriminator remote 413
[*PE2-bfd-lsp-session-mainlsptope2] min-tx-interval 100
[*PE2-bfd-lsp-session-mainlsptope2] min-rx-interval 100
[*PE2-bfd-lsp-session-mainlsptope2] quit
[*PE2] bfd backuplsptope2 bind mpls-te interface Tunnel 2 te-lsp backup
[*PE2-bfd-lsp-session-backuplsptope2] discriminator local 324
[*PE2-bfd-lsp-session-backuplsptope2] discriminator remote 423

[*PE2-bfd-lsp-session-backuplsptope2] min-tx-interval 100

[*PE2-bfd-lsp-session-backuplsptope2] min-rx-interval 100
[*PE2-bfd-lsp-session-backuplsptope2] commit
[~PE2-bfd-lsp-session-backuplsptope2] quit
# After completing the preceding configurations, run the display bfd session discriminator
local-discriminator-value command on PE1 and PE2. The status of BFD sessions is Up.
The following example uses the command output on PE1.
[~PE1] display bfd session discriminator 413
(w): State in WTR
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
[~PE1] display bfd session discriminator 423
(w): State in WTR
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

Connect Port 1 and Port 2 on the tester to PE1 and PE2, respectively. Inject MPLS traffic
destined for Port 2 into Port 1. Write down the label setting in MPLS packets. After the cable
to GE 2/0/0 on PE1 or GE 2/0/0 on P1 is removed, the fault is rectified in milliseconds.
After inserting the cable into GE 2/0/0 and then removing the cable from GE 1/0/0 on PE1
within 15 seconds, the fault is rectified in milliseconds.
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 10.3.1.2
next hop 10.5.1.2
next hop 3.3.3.3
#
explicit-path main
next hop 10.4.1.2
next hop 10.2.1.2
next hop 3.3.3.3
#
isis 1
cost-style wide
network-entity 10.0000.0000.0004.00

#
ip address 10.3.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface Tunnel 1
destination 3.3.3.3
mpls te path explicit-path main
mpls te path explicit-path backup secondary
mpls te backup hot-standby wtr 15
mpls te backup ordinary best-effort
#
bfd mainlsptope2 bind mpls-te interface Tunnel1 te-lsp
discriminator local 413
discriminator remote 314
min-tx-interval 100
min-rx-interval 100
process-pst
#
bfd backuplsptope2 bind mpls-te interface Tunnel1 te-lsp backup
min-tx-interval 100
min-rx-interval 100
process-pst
#
return
#
sysname P1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls

mpls te
mpls rsvp-te
#
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
return
#
sysname P2
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
return

#
sysname PE2
#
bfd
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
interface Tunnel2
destination 4.4.4.4
mpls te path explicit-path back secondary
#
bfd mainlsptope2 bind mpls-te interface Tunnel2 te-lsp
min-tx-interval 100
min-rx-interval 100
process-pst
#
bfd backuplsptope2 bind mpls-te interface Tunnel2 te-lsp backup
min-tx-interval 100
min-rx-interval 100
process-pst
3.38.17 Example for Configuring Dynamic BFD for CR-LSP

This section provides an example for configuring dynamic BFD for CR-LSP to ensure that
hot standby is enabled and a best-effect LSP is established in a tunnel.

Figure 3-36 illustrates a dynamic BFD for CR-LSP network. A TE tunnel between PE1 and
PE2 is established. Hot standby and a best-effort LSP are configured for the TE tunnel. If the
primary CR-LSP fails, traffic is switched to the backup CR-LSP. After the primary CR-LSP
recovers, traffic is switched back to the primary CR-LSP after a 15-second delay. If both the
primary and backup CR-LSPs fail, traffic switches to the best-effort LSP.
Dynamic BFD for CR-LSP is required to detect the primary and backup CR-LSPs. After the
configuration, the following objects should be achieved:
l If the primary CR-LSP fails, traffic is switched to the backup CR-LSP at the millisecond
level.
l If the backup CR-LSP fails within 15 seconds after the primary CR-LSP recovers, traffic
is switched back to the primary CR-LSP.
NOTE
Dynamic BFD configuration is simpler than static BFD configuration. In addition, dynamic BFD
reduces the number of BFD sessions and uses less network resources because only a single BFD session
can be created on a tunnel interface.
Figure 3-36 Networking diagram for CR-LSP hot backup

NOTE
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
P1 10.1.1.1/30 10.1.1.2/30 P2
10.4.1.2/30 10.5.1.1/30
10.4.1.1/30 10.5.1.2 /30
PE1 PE2
10.3.1.1/30 10.2.1.2/30
Loopback1 Loopback1
4.4.4.4/32 3.3.3.3/32
: Primary path
: Backup path
: Best-effort path

1. Configure CR-LSP hot standby based on Example for Configuring CR-LSP Hot
Standby.
2. Enable BFD on the ingress of the tunnel. Configure MPLS TE BFD. Set the minimum
intervals at which BFD packets are sent and received, and the local BFD detection
multiplier.
3. Enable the capability of passively creating BFD sessions on the egress.
Data Preparation
l Minimum intervals at which BFD packets are sent and received on the ingress
l Local BFD detection multiplier
l For other data, see Example for Configuring CR-LSP Hot Standby
Procedure
Step 1 Configure CR-LSP hot standby.
Configure the primary CR-LSP, backup CR-LSP, and best-effort LSP based on Example for
Configuring CR-LSP Hot Standby.
Step 2 Enable BFD on the ingress of the tunnel and configure MPLS TE BFD.
# Enable MPLS TE BFD on the tunnel interface of PE1. Set the minimum intervals at which
BFD packets are sent and received to 100 milliseconds and the local BFD detection multiplier
to 3.
<PE1> system-view
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] interface Tunnel 10
[*PE1-Tunnel10] mpls te bfd enable
[*PE1-Tunenl10] mpls te bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 3
[*PE1-Tunenl10] commit
Step 3 Enable the capability of passively creating BFD sessions on the egress of the tunnel.
<PE2> system-view
[~PE2] bfd
[*PE2-bfd] mpls-passive
[*PE2-bfd] commit
[~PE2-bfd] quit
# Run the display bfd session mpls-te interface Tunnel command on PE1 and PE2. The
status of BFD sessions is Up.
[~PE1] display bfd session mpls-te interface Tunnel 10 te-lsp
(w): State in WTR
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
16385 16385 3.3.3.3 Up D_TE_LSP Tunnel10
--------------------------------------------------------------------------------

Connect port 1 and port 2 on a tester to PE1 and PE2, respectively. Inject traffic destined for
port 2 into port 1. After the cable is removed from GE 2/0/0 on PE1 or P1, the fault recovers
within milliseconds.
After the cable is inserted into GE 2/0/0 and the cable is removed from GE 1/0/0 on PE1 after
a 15-second delay, the fault recovers within milliseconds.
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 10.3.1.2
next hop 10.5.1.2
next hop 3.3.3.3
#
explicit-path main
next hop 10.4.1.2
next hop 10.2.1.2
next hop 3.3.3.3
#
#
isis 1
cost-style wide
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface Tunnel10

destination 3.3.3.3
mpls te path explicit-path backup secondary
mpls te bfd enable
mpls te bfd min-tx-interval 100 min-rx-interval 100
#
return
#
sysname P1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
#

isis 1
cost-style wide
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
bfd
mpls-passive
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls

mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
3.38.18 Example for Configuring Static BFD for TE

After static BFD for TE is configured, the VPN is enabled to rapidly detect tunnel faults and
perform traffic switchover.
Figure 3-37 illustrates an MPLS network on which a switch (a Layer 2 device) exists between
PE1 and PE2. PE1 is configured with VPN FRR and the MPLS TE tunnel. The primary path
of VPN FRR is PE1 → Switch → PE2; the backup path of VPN FRR is PE1 → PE3. In a
normal situation, VPN traffic is transmitted over the primary path. If the primary path fails,
VPN traffic is switched to the backup path. BFD for TE is required to monitor the TE tunnel
over the primary path and enable VPN to rapidly detect tunnel faults. Traffic rapidly switches
between the primary and backup paths, and fault recovery is sped up.
Figure 3-37 Static BFD for TE networking

NOTE
Loopback1
2.2.2.2/32
e1
r fa c
inte .2/30
.1
1 0 .1
el PE3
e1
r fa c /3 0 r y tunn
in t e nda
.1 o
.1 .1 Se c
CE1 PE1 10
CE2
Prim
inter a
r y tu
face2 nnel
10.2 PE2
.1.1/
Loopback1 24
inte
1.1.1.1/32 Switch 10 rface2
.2.1.
2/24
Loopback1
3.3.3.3/32
NOTE
For simplicity, the IP addresses of the interfaces connected the PEs and the CEs are not shown in the
diagram.
Configuration Notes
None.

1. Configure an MPLS network and establish bidirectional TE tunnels between PE1 and
PE2, and between PE1 and PE3.
2. Configure VPN FRR on PE1.
3. Enable global BFD on PE1, PE2, and PE3.
4. Establish a BFD session on PE1 to monitor the TE tunnel over the primary path.
5. Establish a BFD session on PE2 and PE3, and specify the TE tunnel as the BFD reverse
tunnel.
Data Preparation
l An IGP and its parameters

l BGP AS number and interface names used by BGP sessions
l MPLS LSR ID
l Maximum BC bandwidth and maximum reservable bandwidth on the outbound interface
of the link along the tunnel
l Tunnel interface number, bandwidth used by the tunnel, and explicit paths
l VPN instance name, RD, and route target (RT)
l Name of the tunnel policy
l Name of a BFD session
l Local and remote discriminators of BFD sessions
Procedure
Assign an IP address to each interface according to Figure 3-37, create loopback interfaces on
routers, and configure the IP addresses of the loopback interfaces as MPLS LSR IDs. For
Configure OSPF or IS-IS on each router to ensure interworking between PE1 and PE2, and
between PE1 and PE3. OSPF is used in the example. For configuration details, see
Step 3 Enable the basic MPLS functions.
On each router, configure an LSR ID and enable MPLS in the system and interface views. For
Step 4 Configure the basic MPLS TE functions.
On each router, enable MPLS-TE and MPLS RSVP-TE in the MPLS and interface views.
Configure the maximum bandwidth for the MPLS TE reserved on each outbound interface of
the link along the tunnel to 100 Mbit/s and the BC bandwidth to 100 Mbit/s. For configuration

Step 5 Enable OSPF TE and configure the CSPF.

Enable OSPF TE on each router and configure CSPF on PE1 and PE2. For configuration
Specify explicit paths between PE1 and PE2 and between PE1 and PE3. For PE1, two explicit
paths must be specified.
# Configure the explicit paths between PE1 and PE2 and between PE2 and PE3 .
[~PE1] explicit-path tope2
[*PE1-explicit-path-tope2] next hop 10.2.1.2
[*PE1-explicit-path-tope2] quit
[*PE1] explicit-path tope3
[*PE1-explicit-path-tope3] commit
[~PE1-explicit-path-tope3] quit
# Configure an explicit path between PE2 and PE1.

# Configure an explicit path between PE3 and PE1.

Create tunnel interfaces on PE1, PE2, and PE3, specify explicit paths, and configure the
tunnel bandwidth to 10 Mbit/s. Bind the tunnel to the specified VPN. For PE1, two tunnel
interfaces must be created.
# Configure PE1.
[*PE1-Tunnel2] mpls te path explicit-path tope2
[*PE1-Tunnel2] mpls te reserved-for-binding
[*PE1-Tunnel2] quit
[*PE1] interface tunnel 1
[~PE1-Tunnel1] quit
# Configure PE2.


[~PE2-Tunnel2] quit
# Configure PE3.
[~PE3-Tunnel1] quit
After completing the preceding configuration, run the display mpls te tunnel-interface
tunnel interface-number command on the PEs. The command output shows that the status of
tunnel 1 and tunnel 2 on PE1, tunnel 2 on PE2, and tunnel 1 on PE3 is Up.
Step 7 Configure VPN FRR.
# Configure VPN instances on PE1, PE2, and PE3. Configure all VPN instance names to
vpn1, RDs to 100:1, 100:2, and 100:3 respectively, and all RTs to 100:1. Configure the CEs to
access the PEs. For configuration details, see Configuration Files in this section.
# Establish MP IBGP peer relationship between PE1 and PE2, and between PE1 and PE3.
The BGP AS number of PE1, PE2, and PE3 are 100. The loopback interface Loopback1 on
PE1, PE2, and PE3 is used as the interface to establish BGP sessions. For configuration
# Configure tunnel policies for PE1, PE2, and PE3 and apply the policies to the VPN
instances.
# Configure PE1.
[~PE1] tunnel-policy policy1
[*PE1-tunnel-policy-policy1] tunnel binding destination 3.3.3.3 te tunnel 2
[*PE1-tunnel-policy-policy1] quit
[*PE1] ip vpn-instance vpn1
[*PE1-ip-vpn-instance-vpn1] tnl-policy policy1
[*PE1-ip-vpn-instance-vpn1] quit
# Configure PE2.
[*PE2-ip-vpn-instance-vpn1] commit
[~PE2-ip-vpn-instance-vpn1] quit
# Configure PE3.

[*PE3-ip-vpn-instance-vpn1] commit
[~PE3-ip-vpn-instance-vpn1] quit
# Configure VPN on PE1. FRR.

[~PE1] bgp 100
[*PE1-bgp] ipv4-family vpn-instance vpn1
[*PE1-bgp-vpn1] auto-frr
[*PE1-bgp-vpn1] commit
[~PE1-bgp-vpn1] quit
[~PE1-bgp] quit
After the configuration is complete, CEs can communicate, and traffic flows through PE1, the
switch, and PE2. If the cable to any interface connecting PE1 to PE2 is removed, or the switch
fails, or PE2 fails, VPN traffic is switched to the backup path between PE1 and PE3. Time
taken in fault recovery is close to the IGP convergence time.
Step 8 Configure BFD for TE.
# Configure a BFD session on PE1 to detect the TE tunnel of the primary path. Set the
minimum interval at which BFD packets are sent and received.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd pe1tope2 bind mpls-te interface tunnel2
[*PE1-bfd-lsp-session-pe1tope2] discriminator local 12
[*PE1-bfd-lsp-session-pe1tope2] discriminator remote 21
[*PE1-bfd-lsp-session-pe1tope2] min-tx-interval 100
[*PE1-bfd-lsp-session-pe1tope2] min-rx-interval 100
[*PE1-bfd-lsp-session-pe1tope2] process-pst
[*PE1-bfd-lsp-session-pe1tope2] commit
# Establish a BFD session on PE2 and specify the TE tunnel as the reverse BFD tunnel. Set
the minimum interval at which BFD packets are sent and received.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] bfd pe2tope1 bind mpls-te interface tunnel2
[*PE2-bfd-lsp-session-pe2tope1] discriminator local 21
[*PE2-bfd-lsp-session-pe2tope1] discriminator remote 12
[*PE2-bfd-lsp-session-pe2tope1] min-tx-interval 100
[*PE2-bfd-lsp-session-pe2tope1] min-rx-interval 100
[*PE2-bfd-lsp-session-pe2tope1] commit
# After completing the configuration, run the display bfd session { all | discriminator discr-
value | mpls-te interface interface-type interface-number } [ verbose ] command on PE1 and
PE2. The command output shows that the status of the BFD session is Up.
Connect tester's Port 1 and Port 2 to CE1 and CE2 respectively. Inject traffic destined for Port
2 into Port 1. The test shows that a fault can be rectified in milliseconds.
----End
Configuration Files
NOTE
Configuration files of CE1, CE2 and the switch and the configuration of PE accessing CE are not
provided.
#
sysname PE1
#

ip vpn-instance vpn1
route-distinguisher 100:1
tnl-policy policy1
vpn-target 100:1 export-extcommunity
vpn-target 100:1 import-extcommunity
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path tope2
next hop 10.2.1.2
next hop 3.3.3.3
#
explicit-path tope3
next hop 10.1.1.2
next hop 2.2.2.2
#
interface gigabitethernet2/0/0
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface Tunnel1
destination 2.2.2.2
mpls te tunnel-id 1
mpls te path explicit-path tope3
mpls te reserved-for-binding
commit
#
interface Tunnel2
destination 3.3.3.3
mpls te tunnel-id 2
commit
#
bgp 100
peer 2.2.2.2 as-number 100
peer 2.2.2.2 connect-interface LoopBack1
#

ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
import-route direct
auto-frr
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
mpls-te enable
#
tunnel-policy policy1
tunnel binding destination 3.3.3.3 te Tunnel2
#
bfd pe1tope2 bind mpls-te interface Tunnel2
min-tx-interval 100
min-rx-interval 100
process-pst
return
#
sysname PE2
#
tnl-policy policy1
#
bfd
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path tope1
next hop 10.2.1.1
next hop 1.1.1.1
#
interface gigabitethernet2/0/0
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Tunnel2

destination 1.1.1.1
mpls te tunnel-id 3
commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.2.1.0 0.0.0.255
network 3.3.3.3 0.0.0.0
mpls-te enable
#
#
bfd pe2tope1 bind mpls-te interface Tunnel2
min-tx-interval 100
min-rx-interval 100
return
#
sysname PE3
#
tnl-policy policy1
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path tope1
next hop 10.1.1.1
next hop 1.1.1.1
#
undo shutdown
ip address 10.1.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#

interface Tunnel1
destination 1.1.1.1
mpls te tunnel-id 4
commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
mpls-te enable
#
return
3.38.19 Example for Configuring BFD for RSVP

This section provides an example for configuring BFD for RSVP for nodes to detect link
failures and perform TE FRR switching on a network with Layer 2 devices between two
RSVP nodes.
On the MPLS network shown in Figure 3-38, a Layer 2 device (switch) is deployed on a link
between P1 and P2. A primary MPLS TE tunnel between PE1 and PE2 is established over a
path PE1 -> P1 -> switch -> P2 -> PE2. A TE FRR bypass tunnel between P1 and PE2 is
established over the path P1 -> P3 -> PE2. P1 functions as the point of local repair (PLR), and
PE2 functions as the merge point (MP).
If the link between the switch and P2 fails, P1 keeps sending the switch RSVP messages
(including Hello messages) destined for P2 and detects the fault only after P1 fails to receive
replies to RSVP Hello messages sent to P2.
The timeout period of RSVP neighbor relationships is three times as long as the interval ()
between Hello message transmissions. After the timeout period elapses, P1 declares its
neighbor Down, which is seconds slower than it does when there is no Layer 2 device. The
fault detection latency causes a large number of packets to be dropped. To minimize traffic
loss, BFD can be configured to rapidly detect the fault in the link between P2 and the switch.
After a BFD session detects the fault, it advertises the fault to trigger TE FRR switching.

Figure 3-38 BFD for RSVP

NOTE
Loopback1
4.4.4.4/32
e1 i n te
e r fa c /3 0 10. rface
t
in 1.2 5 .1 2
3. .1 /3
e3 10. P3
0 i n te
Loopback1
rfac 1/30 10. rface
1.1.1.1/32 t e
i n 3 .1 . 5 .1 2
.2 /3
10. 0
interface1
10.1.1.1/30 P1 PE2
inte Switch
1
PE1 interface1 r
1 0 .2 fa c e 2 P2 e rf ace 0
10.1.1.2/30 . 1 .1 / i n t 1 .2 /3
24 4.
Loopback1
inte ce 1 10. Loopback1
10.2 rface2 r f a 3 0
2.2.2.2/32 .1 .2
/2 4 inte .1.1/ 5.5.5.5/32
. 4
10
Loopback1
3.3.3.3/32
: Primary CR-LSP
: Bypass CR-LSP
1. Configure an IP address for each interface and enable IGP on each LSR so that LSRs can
communicate. Enable IGP GR to support RSVP GR.
2. Configure the MPLS network and basic MPLS TE functions.
3. Configure explicit paths for the primary and bypass tunnels.
4. Create the primary tunnel interface and enable TE FRR on PE1. Configure the bypass
tunnel on P1.
5. Configure BFD for RSVP on P1 and P2.
Data Preparation
l IGP protocol and parameters

l MPLS LSR IDs
l Bandwidth attributes of the outbound interfaces of links along the tunnel
l Primary tunnel interface number and explicit path
l Bypass tunnel interface number and explicit path
l Physical interfaces to be protected by the bypass tunnel
l Minimum intervals at which BFD packets are sent and received
l Local BFD detection multiplier

Procedure
Assign an IP address to each interface according to Figure 3-38, create loopback interfaces on
LSRs, and configure the loopback interface addresses as MPLS LSR IDs. For configuration
Step 2 Configure the switch.
Configure the switch so that P1 and P2 can communicate. For configuration details, see
Configure OSPF or IS-IS on each LSR so that LSRs can communicate. In this example, IS-IS
is used. For configuration details, see Configuration Files in this section.
Configure the LSR ID and enable MPLS in the system and interface views on each LSR. For
Step 5 Configure basic MPLS TE functions.
Enable MPLS TE and MPLS RSVP-TE in the MPLS and interface views on each LSR. For
Step 6 Configure IS-IS TE and CSPF.
Enable IS-IS TE on each node and configure CSPF on PE1 and PE2. For configuration
Step 7 Configure the primary tunnel.
# Specify an explicit path for the primary tunnel on PE1.
<PE1> system-view
# Create a tunnel interface on PE1, specify an explicit path, and enable TE FRR.
[*PE1-Tunnel10] mpls te fast-reroute
[~PE1-Tunnel10] quit
# Run the display mpls te tunnel-interface tunnel command on PE1. The status of Tunnel
10 on PE1 is Up.
Step 8 Configure the bypass tunnel.
# Specify the explicit path for the bypass tunnel on P1.

<P1> system-view
[~P1] explicit-path tope2
[*P1-explicit-path-tope2] next hop 10.3.1.2
[*P1-explicit-path-tope2] commit
[~P1-explicit-path-tope2] quit
# Configure a bypass tunnel interface and specify an explicit path for the bypass tunnel.
Specify the physical interface to be protected by the bypass tunnel.
[~P1] interface Tunnel 30
[*P1-Tunnel30] ip address unnumbered interface loopback 1
[*P1-Tunnel30] tunnel-protocol mpls te
[*P1-Tunnel30] destination 5.5.5.5
[*P1-Tunnel30] mpls te tunnel-id 300
[*P1-Tunnel30] mpls te path explicit-path tope2
[*P1-Tunnel30] mpls te bypass-tunnel
[*P1-Tunnel30] mpls te protected-interface gigabitethernet 2/0/0
[*P1-Tunnel30] commit
[~P1-Tunnel30] quit
Step 9 Configure BFD for RSVP.

# Enable BFD for RSVP on GE 2/0/0 on P1 and P2. Set the minimum interval at which BFD
packets are sent and received and the local BFD detection multiplier.
# Configure P1.
[~P1] bfd
[*P1-bfd] quit
[*P1] interface gigabitethernet 2/0/0
[*P1-GigabitEthernet2/0/0] mpls rsvp-te bfd enable
[*P1-GigabitEthernet2/0/0] mpls rsvp-te bfd min-tx-interval 100 min-rx-interval
100 detect-multiplier 3
[*P1-GigabitEthernet2/0/0] commit
[~P1-GigabitEthernet2/0/0] quit
# Configure P2.
[~P2] bfd
[*P2-bfd] quit
[*P2-GigabitEthernet2/0/0] mpls rsvp-te bfd enable
[*P2-GigabitEthernet2/0/0] mpls rsvp-te bfd min-tx-interval 100 min-rx-interval
100 detect-multiplier 3

# Run the display mpls rsvp-te bfd session { all | interface interface-type interface-number |
peer ip-address } [ verbose ] command on P1 and P2. The BFD session status is Up.
<P1> display mpls rsvp-te bfd session all
Total Nbrs/Rsvp triggered sessions : 3/1
-------------------------------------------------------------------------------
Local Remote Local Peer Interface Session
Discr Discr Addr Addr Name State
-------------------------------------------------------------------------------
16385 16385 10.2.1.1 10.2.1.2 GE2/0/0 UP
----End

Configuration Files
NOTE
The switch configuration file is not provided here.

#
sysname PE1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls te cspf
#
explicit-path tope2
next hop 10.1.1.2
next hop 10.2.1.2
next hop 10.4.1.2
next hop 5.5.5.5
#
isis 1
is-level level-2
cost-style wide
network-entity 86.4501.0010.0100.1001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel10
destination 5.5.5.5
mpls te fast-reroute
#
return
#
sysname P1
#
bfd
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
mpls rsvp-te bfd all-interfaces enable
mpls rsvp-te bfd all-interfaces min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
mpls rsvp-te hello

mpls te cspf
#
explicit-path tope2
next hop 10.3.1.2
next hop 10.5.1.2
next hop 5.5.5.5
#
isis 1
is-level level-2
cost-style wide
network-entity 86.4501.0020.0200.2002.00
traffic-eng level-2
#
undo shutdown
#
undo shutdown
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
undo shutdown
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te bfd enable
mpls rsvp-te bfd min-tx-interval 100 min-rx-interval 100
mpls rsvp-te hello
#
undo shutdown
ip address 10.3.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface Tunnel30
destination 5.5.5.5
mpls te bypass-tunnel
mpls te protected-interface Gigabitethernet 2/0/0
#
return
#
sysname P2
#
bfd
#
mpls lsr-id 3.3.3.3
#
mpls

mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 86.4501.0030.0300.3003.00
traffic-eng level-2
#
undo shutdown
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
undo shutdown
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te bfd enable
mpls rsvp-te bfd min-tx-interval 100 min-rx-interval 100
mpls rsvp-te hello
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
#
sysname P3
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 86.4501.0040.0400.4004.00
traffic-eng level-2
#
undo shutdown
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
undo shutdown
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls
mpls te

mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 5.5.5.5
#
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 86.4501.0050.0500.5005.00
traffic-eng level-2
#
undo shutdown
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
undo shutdown
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
3.38.20 Example for Configuring a P2MP TE Tunnel

This section provides an example for configuring a P2MP TE tunnel on an IP/MPLS
backbone network.
The IP multicast service bearer technology used on the current IP/MPLS backbone network
relies on the IP unicast technology. Like IP unicast, IP multicast fails to provide sufficient
bandwidth, QoS capabilities, reliability and high real-time performance for multicast services
such as IPTV and massively multiplayer online role-playing games (MMORPGs). A P2MP
TE tunnel can solve this problem. A P2MP TE tunnel can be configured on a live IP/MPLS
backbone network. It supports the P2MP TE FRR function, meeting multicast service
requirements.

A P2MP TE tunnel is established on the network shown in Figure 3-39. LSRA is the tunnel
ingress. LSRC, LSRE, and LSRF are leaf nodes, and the tunnel bandwidth is 1,000 kbit/s. For
the IP address of each node, see Table 3-20.
Figure 3-39 P2MP TE tunnel networking
LSRA LSRB LSRD LSRE

10.1.1.1/24 10.2.1.1/24 10.4.1.1/24
10.1.1.2/24 10.2.1.2/24 10.4.1.2/24
10.5.1.1/24
10.3.1.1/24
10.3.1.2/24 10.5.1.2/24
LSRC LSRF
P2MP TE tunnel
Table 3-20 Interface IP addresses

Name Name Name Name
LSRA GE 1/0/1 10.1.1.1/24 LSRE GE 1/0/0 10.4.1.2/24
LSRB GE 1/0/1 10.1.1.2/24 LSRD GE 1/0/0 10.2.1.2/24
GE 1/0/0 10.2.1.1/24 GE 1/0/2 10.4.1.1/24
GE 1/0/2 10.3.1.1/24 GE 1/0/1 10.5.1.1/24
LSRC GE 1/0/2 10.3.1.2/24 LSRF GE 1/0/1 10.5.1.2/24
Precautions
None.
1. Assign an IP address to each interface and configure a loopback interface address as an
LSR ID on each node.

2. Configure Intermediate System to Intermediate System (IS-IS) to advertise the route to

each network segment to which each interface is connected and the host route to each
loopback interface address that is an LSR ID.
3. Enable MPLS, MPLS TE, P2MP TE, and MPLS RSVP globally on each node and
constraint shortest path first (CSPF) on the ingress to enable all nodes to have MPLS
forwarding capabilities.
4. Enable the IS-IS TE capability to ensure that MPLS TE can advertise information about
link status.
5. Enable the MPLS TE capability on the interfaces of each node and configure link
attributes for the interfaces so that the interfaces can send RSVP signaling packets.
6. Configure explicit paths and a leaf list on the ingress LSRA to specify the leaf nodes on
the P2MP TE tunnel.
7. Configure a P2MP TE tunnel interface on LSRA to ensure that the ingress establishes a
P2MP TE tunnel based on all configuration information on the interface.
Data Preparation
l IP addresses of all interfaces shown in Figure 3-39
l IS-IS (used as an IGP protocol), IS-IS process ID (1), IS-IS system ID of each node
(obtained by translating the IP address of loopback1 of each node), and IS-IS level
(Level-2)
l MPLS LSR ID of each node using the corresponding loopback interface address
l Maximum reservable bandwidth (10000 kbit/s) of the outbound interface along the path
and BC0 bandwidth (10000 kbit/s)
l Name of an explicit path used by each leaf node (toLSRB, toLSRE, and toLSRF), name
of the leaf list (iptv1), and addresses of each leaf node (MPLS LSR ID of each leaf node)
l Tunnel interface number (Tunnel 10), tunnel ID (100), loopback interface address used
as the IP address of the tunnel interface, and tunnel bandwidth (1000 kbit/s)
Procedure
Assign an IP address to each interface according to Figure 3-39 and create a loopback
interface on each node. For configuration details, see Configuration Files in this section.
Step 2 Configure IS-IS to advertise the route to each network segment to which each interface is
connected and to advertise the host route to each LSR ID.
Configure IS-IS on each node to allow the nodes to communicate at the network layer. For
Step 3 Enable MPLS, MPLS TE, P2MP TE, and MPLS RSVP globally on each node and CSPF on
the ingress.
# Configure LSRA.
<LSRA> system-view
[*LSRA] mpls
[*LSRA-mpls] mpls te p2mp-te


[*LSRA-mpls] commit
[~LSRA-mpls] quit
# Configure LSRB.
<LSRB> system-view
[*LSRB] mpls
[*LSRB-mpls] mpls te p2mp-te
[*LSRB-mpls] commit
[~LSRB-mpls] quit
# Configure LSRC.
<LSRC> system-view
[*LSRC] mpls
[*LSRC-mpls] mpls te p2mp-te
[*LSRC-mpls] commit
[~LSRC-mpls] quit
# Configure LSRD.
<LSRD> system-view
[*LSRD] mpls
[*LSRD-mpls] mpls te p2mp-te
[*LSRD-mpls] commit
[~LSRD-mpls] quit
# Configure LSRE.
<LSRE> system-view
[~LSRE] mpls lsr-id 5.5.5.5
[*LSRE] mpls
[*LSRE-mpls] mpls te
[*LSRE-mpls] mpls te p2mp-te
[*LSRE-mpls] mpls rsvp-te
[*LSRE-mpls] commit
[~LSRE-mpls] quit
# Configure LSRF.
<LSRF> system-view
[~LSRF] mpls lsr-id 6.6.6.6
[*LSRF] mpls
[*LSRF-mpls] mpls te
[*LSRF-mpls] mpls te p2mp-te
[*LSRF-mpls] mpls rsvp-te
[*LSRF-mpls] commit
[~LSRF-mpls] quit
Step 4 Enable IS-IS TE on each node.
# Configure LSRA.
[~LSRA] isis 1
[~LSRA-isis-1] quit

# Configure LSRB.
[~LSRB] isis 1
[~LSRB-isis-1] cost-style wide
[*LSRB-isis-1] traffic-eng level-2
[~LSRB-isis-1] quit
# Configure LSRC.
[~LSRC] isis 1
[~LSRC-isis-1] quit
# Configure LSRD.
[~LSRD] isis 1
[*LSRD-isis-1] traffic-eng level-2
[~LSRD-isis-1] quit
# Configure LSRE.
[~LSRE] isis 1
[~LSRE-isis-1] cost-style wide
[*LSRE-isis-1] traffic-eng level-2
[*LSRE-isis-1] commit
[~LSRE-isis-1] quit
# Configure LSRF.
[~LSRF] isis 1
[~LSRF-isis-1] cost-style wide
[*LSRF-isis-1] traffic-eng level-2
[*LSRF-isis-1] commit
[~LSRF-isis-1] quit
Step 5 Enable the MPLS TE capability on the interface of each node, and configure link attributes
for the interfaces.
# Configure LSRA.
<LSRA> system-view
[*LSRA-GigabitEthernet1/0/1] mpls te bandwidth max-reservable-bandwidth 10000
# Configure LSRB.
<LSRB> system-view
[~LSRB-GigabitEthernet1/0/0] mpls


# Configure LSRC.
<LSRC> system-view
[~LSRC-GigabitEthernet1/0/2] mpls
# Configure LSRD.
<LSRD> system-view
[~LSRD-GigabitEthernet1/0/0] mpls
# Configure LSRE.
<LSRE> system-view
[~LSRE] interface gigabitethernet 1/0/0
[~LSRE-GigabitEthernet1/0/0] mpls
[*LSRE-GigabitEthernet1/0/0] mpls te
[*LSRE-GigabitEthernet1/0/0] mpls rsvp-te
[*LSRE-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 10000
[*LSRE-GigabitEthernet1/0/0] mpls te bandwidth bc0 10000
# Configure LSRF.
<LSRF> system-view
[~LSRF] interface gigabitethernet 1/0/1
[~LSRF-GigabitEthernet1/0/1] mpls
[*LSRF-GigabitEthernet1/0/1] mpls te
[*LSRF-GigabitEthernet1/0/1] mpls rsvp-te
[*LSRF-GigabitEthernet1/0/1] mpls te bandwidth max-reservable-bandwidth 10000
[*LSRF-GigabitEthernet1/0/1] mpls te bandwidth bc0 10000
[*LSRF-GigabitEthernet1/0/1] commit
[~LSRF-GigabitEthernet1/0/1] quit
Step 6 Configure explicit paths and a leaf list on the ingress LSRA.
# Configure explicit paths on LSRA to LSRC, LSRE, and LSRF.

[~LSRA] explicit-path tolsrc

[*LSRA-explicit-path-tolsrc] next hop 10.1.1.2
[*LSRA-explicit-path-tolsrc] next hop 10.3.1.2
[*LSRA-explicit-path-tolsrc] quit
[*LSRA] explicit-path tolsrf
[*LSRA-explicit-path-tolsrf] next hop 10.1.1.2
[*LSRA-explicit-path-tolsrf] commit
[*LSRA-explicit-path-tolsrf] quit
[*LSRA] explicit-path tolsre
[*LSRA-explicit-path-tolsre] next hop 10.1.1.2
[*LSRA-explicit-path-tolsre] commit
[~LSRA-explicit-path-tolsre] quit
# Configure a leaf list iptv1 on LSRA and add leaf node addresses to the leaf list.
[~LSRA] mpls te leaf-list iptv1
[*LSRA-mpls-te-leaf-list-iptv1] destination 3.3.3.3
[*LSRA-mpls-te-leaf-list-iptv1-destination-3.3.3.3] path explicit-path tolsrc
[*LSRA-mpls-te-leaf-list-iptv1-destination-3.3.3.3] quit
[*LSRA-mpls-te-leaf-list-iptv1-destination-5.5.5.5] path explicit-path tolsre
[*LSRA-mpls-te-leaf-list-iptv1-destination-5.5.5.5] quit
[*LSRA-mpls-te-leaf-list-iptv1-destination-6.6.6.6] path explicit-path tolsrf
[*LSRA-mpls-te-leaf-list-iptv1-destination-6.6.6.6] commit
[~LSRA-mpls-te-leaf-list-iptv1-destination-6.6.6.6] quit
Step 7 Configure the P2MP TE tunnel interface on the ingress LSRA.
# Configure LSRA.
[*LSRA-Tunnel10] mpls te p2mp-mode
[*LSRA-Tunnel10] mpls te leaf-list iptv1
After completing the configurations, run the display mpls te p2mp tunnel-interface
Tunnel10 command on LSRA. The status of Tunnel 10 on LSRA is UP, and the status of all
sub-LSPs is UP.
[~LSRA] display mpls te p2mp tunnel-interface Tunnel10
------------------------------------------------------------------------------
Tunnel10
------------------------------------------------------------------------------
Tunnel State : UP
Session ID : 100
Ingress LSR ID : 1.1.1.1 P2MP ID : 0x1010101
Admin State : UP Oper State :
UP
Primary LSP State : UP
------------------------------------------------------------------------------
Main LSP State : UP LSP ID : 8
------------------------------------------------------------------------------
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls te p2mp-te
mpls rsvp-te
mpls te cspf
#
explicit-path tolsrc
next hop 10.1.1.2
next hop 10.3.1.2
#
explicit-path tolsrf
next hop 10.1.1.2
next hop 10.2.1.2
next hop 10.5.1.2
#
explicit-path tolsre
next hop 10.1.1.2
next hop 10.2.1.2
next hop 10.4.1.2
#
mpls te leaf-list iptv1
#
destination 3.3.3.3
path explicit-path tolsrc
#
destination 5.5.5.5
path explicit-path tolsre
#
destination 6.6.6.6
path explicit-path tolsrf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel10
mpls te p2mp-mode
mpls te leaf-list iptv1
#
return


#
sysname LSRB
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls te p2mp-te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls te p2mp-te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide

network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
#
sysname LSRD
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls te p2mp-te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.5.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1

#
return
#
sysname LSRE
#
mpls lsr-id 5.5.5.5
#
mpls
mpls te
mpls te p2mp-te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0005.00
traffic-eng level-2
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
#
sysname LSRF
#
mpls lsr-id 6.6.6.6
#
mpls
mpls te
mpls te p2mp-te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0006.00
traffic-eng level-2
#
undo shutdown
ip address 10.5.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
isis enable 1
#
return

3.38.21 Example for Configuring the IETF DS-TE Mode (RMD)

This section provides an example for configuring the IETF DS-TE mode.
In Figure 3-40, PEs and the P node run IS-IS to implement connectivity between one another.
The P node does not support MPLS LDP. PE1 and PE2 access both VPN-A and VPN-B. An
LDP LSP originates from PE3 and is terminated at PE4 through a path PE1 > P > PE2.
VPN-A transmits EF and AF traffic. VPN-B transmits EF, AF, and BE traffic. The LDP LSP
transmits BE traffic. QoS requirements of each type of traffic are as follows:
Data Flow Bandwidth Jitter
VPN-A EF traffic 100 Mbit/s Less than 50 ms
VPN-A AF traffic 50 Mbit/s Less than 200 ms
VPN-B EF traffic 100 Mbit/s Less than 50 ms
VPN-B AF traffic 50 Mbit/s Less than 200 ms
VPN-B BE traffic 50 Mbit/s Not required
LDP LSP BE traffic 50 Mbit/s Not required
A DS-TE tunnel is established between PE1 and PE2 to transfer the preceding types of traffic
and satisfy various QoS requirements. The bandwidth constraints model is set to RDM to
allow CTi to preempt lower-priority CTj bandwidth (0 <= i < j <= 7) to guarantee higher-
priority CT bandwidth.
Figure 3-40 IETF DS-TE networking

NOTE
In this example, interfaces 1 through 4 stand for GE 1/0/0, GE 2/0/0, GE 3/0/0, and 4/0/0, respectively.

AS 65410 AS 65430
VPN-A VPN-A
CE1 CE3
10.1.1.1/24 10.3.1.1/24
MPLS backbone AS 100

Loopback 1 Loopback 1 Loopback 1
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
10.1.1.2/24 interface3 10.3.1.2/24
interface3
Loopback 1 PE1 10.10.1.1/24 10.11.1.2/24 Loopback 1
PE2
4.4.4.9/32 5.5.5.9/32
10.5.1.1/24 10.10.1.2/24 P 10.11.1.1/24 10.6.1.1/24
PE3 interface2 interface2 PE4
10.2.1.2/24 10.4.1.2/24 interface1
interface1
10.6.1.2/24
10.5.1.2/24
10.2.1.1/24 10.4.1.1/24
CE2 CE4
VPN-B VPN-B
AS 65420 AS 65440
1. Since VPN-A and VPN-B share traffic types (EF and AF), establish two TE tunnels each
to carry traffic of a VPN instance.
2. Since VPN-B and the LDP LSP also share traffic types, establish different tunnels to
carry these types of traffic.
3. VPN-A and the LDP LSP do not share any of three traffic types, configure a TE tunnel
to carry their traffic.
4. Establish two RSVP-TE tunnels named Tunnel1 and Tunnel2. Each tunnel is assigned a
single CT, with priority values of 0.
5. Since the two tunnels pass through the same path, ensure that the BCi link bandwidth
value is greater than or equal to the sum of CTi through CT7 bandwidth values of all TE
tunnels, and the maximum link reservable bandwidth is greater than or equal to the BC0
bandwidth value. Set the maximum link reservable bandwidth to 400 Mbit/s (maximum
link reservable bandwidth >= BC0 bandwidth).
6. Use a CT template to configure TE tunnels because the two tunnels carry the same type
of service and use the same bandwidth and jitter requirements.
Data Preparation
l LSR IDs of PEs and the P

l Number of each MPLS TE tunnel interface

l TE-class mapping table

l Maximum reservable bandwidth value and each BC bandwidth value of each link
l VPN-A's and VPN-B's VPN instance names, Route-Distinguishers, VPN-Targets, and
tunnel policy name
zhineng
Procedure
Step 1 Assign an IP address to each interface on the PEs and P and configure IS-IS to implement
connectivity between the PEs and P.
After the configuration, isis neighbor relationships can be established between PE1, P, and
PE2. Run the display ip routing-table command. The command output shows that the PEs
have learnt the routes to Loopback1 of each other.
Step 2 Configure an LSR ID and enable MPLS on each node; enable MPLS TE and RSVP-TE on
PE1, PE2, and the P; enable MPLS LDP on each PE.
# Configure PE3.
<PE3> system-view
[~PE3] mpls lsr-id 4.4.4.9
[*PE3] mpls
[*PE3] commit
[~PE3-mpls] quit
[*PE3] mpls ldp
[*PE3] commit
[~PE3-mpls-ldp] quit
[~PE3] interface gigabitethernet 1/0/0
[*PE3-GigabitEthernet1/0/0] mpls
[*PE3-GigabitEthernet1/0/0] mpls ldp
[*PE3-GigabitEthernet1/0/0] commit
[~PE3-GigabitEthernet1/0/0] quit
# Configure PE1.
<PE1> system-view
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] mpls rsvp-te
[*PE1-mpls] commit
[~PE1-mpls] quit
[*PE1] mpls ldp
[*PE1-mpls-ldp] commit
[*PE1-GigabitEthernet3/0/0] mpls te
[*PE1-GigabitEthernet3/0/0] mpls rsvp-te
# Configure the P.
<P> system-view
[~P] mpls lsr-id 2.2.2.9
[*P] mpls

[*P-mpls] mpls te
[*P-mpls] mpls rsvp-te
[*P-mpls] commit
[~P-mpls] quit
[~P] interface gigabitethernet 1/0/0
[*P-GigabitEthernet1/0/0] mpls
[*P-GigabitEthernet1/0/0] mpls te
[*P-GigabitEthernet1/0/0] mpls rsvp-te
[*P-GigabitEthernet1/0/0] commit
[~P-GigabitEthernet1/0/0] quit
[*P-GigabitEthernet2/0/0] mpls
[*P-GigabitEthernet2/0/0] mpls te
[*P-GigabitEthernet2/0/0] mpls rsvp-te
# Configure PE2.
<PE2> system-view
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] commit
[~PE2-mpls] quit
[*PE2] mpls ldp
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure PE4.
<PE4> system-view
[*PE4] mpls
[*PE4-mpls] commit
[~PE4-mpls] quit
[*PE4] mpls ldp
[*PE4-mpls] commit
After completing the configuration, run the display mpls rsvp-te interface command on PE1,
PE2, or the P to view RSVP interface information and RSVP information. Run the display
mpls ldp lsp command on PE1, PE2, PE3, or PE4. The command output shows that an LDP
LSP has been established between the pair of PE3 and PE1 and that of PE2 and PE4.
Step 3 Configure IS-IS TE and enable CSPF on PE1, PE2, and the P.
# Enable IS-IS TE on all nodes and enable CSPF on the ingress of the TE tunnel.
# Configure PE1.
[~PE1] isis 1
[~PE1-isis-1] cost-style wide

[*PE1-isis-1] traffic-eng level-1-2

[*PE1-isis-1] commit
[~PE1-isis-1] quit
[~PE1] mpls
[~PE1-mpls] mpls te cspf
[*PE1-mpls] commit
# Configure the P.
[~P] isis 1
[~P-isis-1] cost-style wide
[*P-isis-1] traffic-eng level-1-2
[*P-isis-1] commit
[~P-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] traffic-eng level-1-2
[~PE2-isis-1] quit
[~PE2] mpls
[~PE2-mpls] mpls te cspf
[*PE2-mpls] commit
[~PE2-mpls] quit
After completing the configuration, run the display isis lsdb command on a PE or the P. The
command output shows that the isis link status information.
Step 4 Configure a DS-TE mode and a BCM on PE1, PE2, and the P.
# Configure PE1.
[~PE1] mpls
[~PE1-mpls] mpls te ds-te mode ietf
[*PE1-mpls] mpls te ds-te bcm rdm
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure the P.
[~P] mpls
[~P-mpls] mpls te ds-te mode ietf
[*P-mpls] mpls te ds-te bcm rdm
[*P-mpls] commit
[~P-mpls] quit
# Configure PE2.
[~PE2] mpls
[~PE2-mpls] mpls te ds-te mode ietf
[*PE2-mpls] mpls te ds-te bcm rdm
[*PE2-mpls] commit
[~PE2-mpls] quit
After completing the configuration, run the display mpls te ds-te summary command on a
PE or the P to view DS-TE configurations. The following example uses the command output
on PE1.
[~PE1] display mpls te ds-te summary
DS-TE IETF Supported :YES
DS-TE MODE :IETF
Bandwidth Constraint Model :RDM
TEClass Mapping (configured):
TE-Class ID Class Type Priority
TE-Class 0 0 0
TE-Class 1 1 0
TE-Class 2 2 0

TE-Class 3 3 0
TE-Class 4 0 7
TE-Class 5 1 7
TE-Class 6 2 7
TE-Class 7 3 7
Step 5 Configure link bandwidth values on PE1, PE2, and the P.

# Configure PE1.
[~PE1-GigabitEthernet3/0/0] mpls te bandwidth max-reservable-bandwidth 400000
[*PE1-GigabitEthernet3/0/0] mpls te bandwidth bc0 400000 bc1 300000 bc2 200000
# Configure the P.
[~P-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 400000
[*P-GigabitEthernet1/0/0] mpls te bandwidth bc0 400000 bc1 300000 bc2 200000
[~P-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 400000
[*P-GigabitEthernet2/0/0] mpls te bandwidth bc0 400000 bc1 300000 bc2 200000
# Configure PE2.
[*PE2-GigabitEthernet3/0/0] mpls te bandwidth bc0 400000 bc1 300000 bc2 200000
After completing the configuration, run the display mpls te link-administration bandwidth-
allocation interface gigabitethernet command on a PE to view BC bandwidth allocation
information. The following example uses the command output on PE1.
[~PE1] display mpls te link-administration bandwidth-allocation interface
gigabitethernet 3/0/0
Link ID: GigabitEthernet3/0/0
Bandwidth Constraint Model : Russian Dolls Model (RDM)
Physical Link Bandwidth(Kbits/sec) : -
Maximum Link Reservable Bandwidth(Kbit/sec): 400000
Reservable Bandwidth BC0(Kbit/sec) : 400000
Downstream Bandwidth (Kbit/sec) : 0
IPUpdown Link Status : UP
PhysicalUpdown Link Status : UP
----------------------------------------------------------------------
TE-CLASS CT PRIORITY BW RESERVED BW AVAILABLE DOWNSTREAM
(Kbit/sec) (Kbit/sec) RSVPLSPNODE COUNT
----------------------------------------------------------------------
0 0 0 0 400000 0
1 1 0 0 300000 0
2 2 0 0 200000 0
3 0 7 0 400000 0
4 1 7 0 300000 0
5 2 7 0 200000 0
6 - - - - -
7 - - - - -
8 - - - - -

9 - - - - -
10 - - - - -
11 - - - - -
12 - - - - -
13 - - - - -
14 - - - - -
15 - - - - -
----------------------------------------------------------------------
Step 6 Configure a TE-class mapping table on a PE.

# Configure PE1.
[~PE1] te-class-mapping
[~PE1-te-class-mapping] te-class0 class-type ct0 priority 0 description For-BE
[*PE1-te-class-mapping] te-class1 class-type ct1 priority 0 description For-AF
[*PE1-te-class-mapping] te-class2 class-type ct2 priority 0 description For-EF
[*PE1-te-class-mapping] commit
[~PE1-te-class-mapping] quit
# Configure PE2.
[~PE2] te-class-mapping
[~PE2-te-class-mapping] te-class0 class-type ct0 priority 0 description For-BE
[*PE2-te-class-mapping] te-class1 class-type ct1 priority 0 description For-AF
[*PE2-te-class-mapping] te-class2 class-type ct2 priority 0 description For-EF
[*PE2-te-class-mapping] commit
[~PE2-te-class-mapping] quit
After completing the configuration, run the display mpls te ds-te te-class-mapping
command on a PE to view TE-class mapping table information. The following example uses
the command output on PE1.
[~PE1] display mpls te ds-te te-class-mapping
TE-Class ID Class Type Priority Description
TE-Class0 0 0 For-BE
TE-Class1 1 0 For-AF
TE-Class2 2 0 For-EF
TE-Class3 - - -
TE-Class4 - - -
TE-Class5 - - -
TE-Class6 - - -
TE-Class7 - - -
Step 7 Configure an explicit path on PE1 and PE2.

# Configure PE1.
[~PE1] explicit-path path1
[*PE1-explicit-path-path1] next hop 10.10.1.2
[*PE1-explicit-path-path1] commit
[~PE1-explicit-path-path1] quit
# Configure PE2.
[~PE2] explicit-path path1
[*PE2-explicit-path-path1] commit
[~PE2-explicit-path-path1] quit
After completing the configuration, run the display explicit-path command on a PE to view
explicit path information. The following example uses the command output on PE1.
[~PE1] display explicit-path path1
Path Name : path1 Path Status : Enabled


Step 8 Configure a tunnel interfaces on PE1 and PE2.

# Configure PE1.
[~PE1] interface Tunnel1
[*PE1-Tunnel1] description For VPN-A & Non-VPN
[*PE1-Tunnel1] mpls te signal-protocol rsvp-te
[*PE1-Tunnel1] mpls te path explicit-path path1
[*PE1-Tunnel1] mpls te priority 0 0
[~PE1-Tunnel1] quit
[*PE1-Tunnel2] description For VPN-B
[~PE1-Tunnel2] quit
# Configure PE2.
[*PE2-Tunnel1] description For VPN-A & Non-VPN
[~PE2-Tunnel1] quit
[*PE2-Tunnel2] description For VPN-B
[~PE2-Tunnel2] quit
After completing the configuration, run the display interface tunnel interface-number
command on a PE. The command output shows that the tunnel interface is Up. The following
example uses information on Tunnel1 of PE1.
[~PE1] display interface Tunnel1
Tunnel1 current state : UP(ifindex: 27)


Last up time: 2017-07-19, 11:15:01
Description :For VPN-A & Non-VPN
Tunnel ct0 bandwidth is 50000 Kbit/sec
primary tunnel id is 0x8201002c, secondary tunnel id is 0x0
...
Run the display mpls te te-class-tunnel command on a PE to view information about a TE

tunnel associated with a TE-class. The following example uses the command output on PE1.
[~PE1] display mpls te te-class-tunnel all
------------------------------------------------------------------------
No. CT priority status tunnel name tunnel commit
------------------------------------------------------------------------
1 0 0 Valid Tunnel1 Yes
2 0 0 Valid Tunnel2 Yes
Step 9 Establish an MP-IBGP peer relationship between the PEs, and establish EBGP peer
relationships between PEs and CEs.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] peer 3.3.3.9 as-number 100
[*PE1-bgp] peer 3.3.3.9 connect-interface loopback 1
[*PE1-bgp] ipv4-family vpnv4
[*PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[*PE1-bgp-af-vpnv4] commit
[~PE1-bgp-af-vpnv4] quit
[~PE1-bgp] ipv4-family vpn-instance vpna
[*PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[*PE1-bgp-vpna] import-route direct
[*PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
[~PE1-bgp] ipv4-family vpn-instance vpnb
[*PE1-bgp-vpnb] peer 10.2.1.1 as-number 65420
[*PE1-bgp-vpnb] import-route direct
[*PE1-bgp-vpnb] commit
[~PE1-bgp-vpnb] quit
NOTE
The procedures for configuring PE2 are similar to that of PE1. For the detailed configuration, see
# Configure CE1.
[~CE1] bgp 65410
[*CE1-bgp] peer 10.1.1.2 as-number 100
[*CE1-bgp] import-route direct
[*CE1-bgp] commit
NOTE
Repeat this step on CE2 to CE4. For the detailed configuration, see Configuration Files in this section.
After completing the configuration, run the display bgp vpnv4 all peer command on each
PE. The command output shows that BGP peer relationships between PEs have been
established and are in the Established state.
[~PE1] display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 3 Peers in established state : 3

Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv

3.3.3.9 4 100 12 18 0 00:09:38 Established 0
Peer of vpn instance:
VPN-Instance vpna, Router ID 1.1.1.9:
10.1.1.1 4 65410 25 25 0 00:17:57 Established 1
VPN-Instance vpnb, Router ID 1.1.1.9:
10.2.1.1 4 65420 21 22 0 00:17:10 Established 1
Step 10 Configure tunnel policies on PEs.

# Configure PE1.
[~PE1] tunnel-policy policya
[*PE1-tunnel-policy-policya] tunnel binding destination 3.3.3.9 te Tunnel 30
[*PE1-tunnel-policy-policya] commit
[~PE1-tunnel-policy-policya] quit
[~PE1] tunnel-policy policyb
[*PE1-tunnel-policy-policyb] tunnel binding destination 3.3.3.9 te Tunnel 31
[*PE1-tunnel-policy-policyb] commit
[~PE1-tunnel-policy-policyb] quit
# Configure PE2.
[~PE2] tunnel-policy policya
[*PE2-tunnel-policy-policya] tunnel binding destination 1.1.1.9 te Tunnel 30
[*PE2-tunnel-policy-policya] commit
[~PE2-tunnel-policy-policya] quit
[~PE2] tunnel-policy policyb
[*PE2-tunnel-policy-policyb] tunnel binding destination 1.1.1.9 te Tunnel 31
[*PE2-tunnel-policy-policyb] commit
[~PE2-tunnel-policy-policyb] quit
Step 11 Configure VPN instances on each PE and configure CEs to access the PEs.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[*PE1-vpn-instance-vpna] ipv4-family
[*PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*PE1-vpn-instance-vpna-af-ipv4] tnl-policy policya
[*PE1-vpn-instance-vpna-af-ipv4] commit
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] ip vpn-instance vpnb
[*PE1-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2
[*PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[*PE1-vpn-instance-vpnb-af-ipv4] tnl-policy policyb
[*PE1-vpn-instance-vpnb-af-ipv4] commit
[~PE1-vpn-instance-vpnb-af-ipv4] quit
[~PE1-vpn-instance-vpnb] quit
[*PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[*PE1-GigabitEthernet1/0/0] ip address 10.1.1.2 24
[*PE1] interface gigabitethernet 2/0/0
[*PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpnb
# Configure PE2.
[~PE2] ip vpn-instance vpna
[*PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[*PE2-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[*PE2-vpn-instance-vpna-af-ipv4] tnl-policy policya

[*PE2-vpn-instance-vpna-af-ipv4] commit
[~PE2-vpn-instance-vpna-af-ipv4] quit
[~PE2-vpn-instance-vpna] quit
[~PE2] ip vpn-instance vpnb
[*PE2-vpn-instance-vpnb] ipv4-family
[*PE2-vpn-instance-vpnb-af-ipv4] route-distinguisher 200:2
[*PE2-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[*PE2-vpn-instance-vpnb-af-ipv4] tnl-policy policyb
[*PE2-vpn-instance-vpnb-af-ipv4] commit
[~PE2-vpn-instance-vpnb-af-ipv4] quit
[~PE2-vpn-instance-vpnb] quit
[*PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[*PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpnb
# Assign IP addresses to the interfaces on CEs. For the detailed configuration, see
After completing the configuration, run the display ip vpn-instance verbose command on a
PE to view the configurations of VPN instances. Each PE can successfully ping its connected
CEs.
After completing the configuration, configure a tester to access PE3, PE4, and each CE and
inject the following traffic to inbound interfaces.
Data Flow Type Bandwidth
Between CE1 and CE2 EF 100 Mbit/s
AF 50 Mbit/s
Between CE3 and CE4 EF 100 Mbit/s
AF 50 Mbit/s
BE 50 Mbit/s
Between PE3 and PE4 BE 50 Mbit/s
No packets are dropped. The jitter of EF traffic is less than 50 ms, and that of AF traffic is less
than 200 ms.
----End
Configuration Files
#
sysname PE1
#
ip vpn-instance vpna
ipv4-family

tnl-policy policya
#
ip vpn-instance vpnb
ipv4-family
tnl-policy policyb
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls te ds-te mode ietf
mpls rsvp-te
#
mpls ldp
#
mpls ldp remote-peer pe1tope2
remote-ip 3.3.3.9
#
explicit-path path1
next hop 10.10.1.2
next hop 10.11.1.2
next hop 3.3.3.9
#
te-class-mapping
te-class0 class-type ct0 priority 0 description For-BE
te-class1 class-type ct1 priority 0 description For-AF
te-class2 class-type ct2 priority 0 description For-EF
#
interface Tunnel1
description For VPN-A & Non-VPN
destination 3.3.3.9
mpls te priority 0
.mpls te reserved-for-binding
mpls te path explicit-path path1
mpls te igp advertise
mpls te igp metric absolute 1
commit
mpls
#
interface Tunnel2
description For VPN-B
destination 3.3.3.9
mpls te priority 0
commit
#
bgp 100
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4

policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpna
import-route direct
#
ipv4-family vpn-instance vpnb
import-route direct
#
isis 1
is-level level-1
cost-style wide
traffic-eng level-1
#
tunnel-policy policya
#
tunnel-policy policyb
#
return
l P configuration file
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.10.1.2 255.255.255.0
mpls
mpls te
mpls te bandwidth bc0 400000 bc1 300000 bc2 200000
mpls rsvp-te
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
mpls
mpls te
mpls te bandwidth bc0 400000 bc1 300000 bc2 200000
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
isis 1
is-level level-1
cost-style wide
traffic-eng level-1
#
return
#
sysname PE2
#
ip vpn-instance vpna
ipv4-family
tnl-policy policya


#
ip vpn-instance vpnb
ipv4-family
tnl-policy policyb
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls te rsvp-te
#
mpls ldp
#
mpls ldp remote-peer pe2tope1
remote-ip 1.1.1.9
#
explicit-path path1
next hop 10.10.1.1
next hop 10.11.1.1
next hop 1.1.1.9
#
te-class-mapping
te-class0 class-type ct0 priority 0 description For-EF
te-class1 class-type ct1 priority 0 description For-AF
te-class2 class-type ct2 priority 0 description For-BE
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
interface Tunnel1
description For VPN-A & Non-VPN
destination 1.1.1.9
mpls te priority 0
commit
#
interface Tunnel2
description For VPN-B
destination 1.1.1.9
mpls te priority 0
commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable

#
ipv4-family vpn-instance vpna
import-route direct
#
ipv4-family vpn-instance vpnb
import-route direct
#
isis 1
is-level level-1
cost-style wide
traffic-eng level-1tunnel-policy policya
#
tunnel-policy policyb
#
return

#
sysname PE3
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
undo shutdown
ip address 10.5.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
isis 1
is-level level-1
cost-style wide
traffic-eng level-1
#
return

#
sysname PE4
#
mpls lsr-id 5.5.5.9
mpls
#
mpls ldp
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
isis 1
is-level level-1
cost-style wide
traffic-eng level-1
#
return

l CE1 configuration file

#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
peer 10.1.1.2 enable
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE3
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE4
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
#
bgp 65440
#
ipv4-family unicast
import-route direct

#
return
3.38.22 Example for Configuring CBTS in an L3VPN over TE

Scenario
In Figure 3-41, CE1 and CE2 belong to the same L3VPN. They access a public network
through PE1 and PE2, respectively. Various types of services are transmitted between CE1
and CE2. Transmitting a large amount of common services deteriorates the efficiency of
transmitting important services. To prevent this problem, the CBTS function can be
configured. A CBTS allows traffic of a specific service class to be transmitted along a
specified tunnel.
In this example, tunnel 1 and tunnel 2 on PE1 transmit important services, and tunnel 3
transmits other packets.
NOTE
After the CBTS function is configured, do not configure the following services:
l Mixed load balancing
l Seamless MPLS
l Dynamic load balancing
Figure 3-41 CBTS in an L3VPN over TE scenario

NOTE
Interfaces 1 through 2 in this example are GE1/0/0, GE2/0/0 respectively.
CE1 CE2
interface2
10 .10.1.1/24 Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
PE1 PE2
10.1.1.1/24 10.3.1.2/24
2.2.2.9/32 3.3.3.9/32
P1 P2
Configuration Notes
N/A

2. Enable IS-IS globally, configure network entity names, specify the cost type, and enable
IS-IS TE. Enable IS-IS on interfaces, including loopback interfaces.
3. Set MPLS label switching router (LSR) IDs for all devices and globally enable MPLS,
MPLS TE, RSVP-TE, and CSPF.
4. Enable MPLS, MPLS TE, RSVP-TE, and CSPF on each interface.
5. Configure the maximum reservable bandwidth and BC bandwidth for a link on the
outbound interface of each node.
6. Configure a tunnel interface on the ingress and configure the IP address, tunnel protocol,
tunnel ID, destination IP address, and tunnel bandwidth.
7. Configure multi-field classification on PE1.
8. Configure a VPN instance and apply a tunnel policy on PE1.
Data Preparation
l IS-IS area ID, originating system ID, and IS-IS level on each node
l Maximum available link bandwidth and maximum reservable link bandwidth on each
node
l Tunnel interface number, IP address, destination IP address, tunnel ID, and tunnel
bandwidth on the tunnel interface
l Traffic classifier name, traffic behavior name, and traffic policy name
Procedure
Configure the IP address and mask for each interface according to Figure 3-41.
Step 2 Configure IS-IS to advertise routes.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] network-entity 00.0005.0000.0000.0001.00
[*PE1-isis-1] is-level level-2
[*PE1-isis-1] quit
[*PE1-GigabitEthernet1/0/0] isis enable 1
[*PE1-GigabitEthernet1/0/0] quit
[*PE1] interface loopback 1
[*PE1-LoopBack1] isis enable 1
[*PE1-LoopBack1] commit
[~PE1-LoopBack1] quit
# Configure P1.
[~P1] isis 1

[*P1-isis-1] network-entity 00.0005.0000.0000.0002.00

[*P1-isis-1] is-level level-2
[*P1-isis-1] quit
[*P1-GigabitEthernet1/0/0] isis enable 1
[*P1-GigabitEthernet1/0/0] quit
[*P1] interface loopback 1
[*P1-LoopBack1] isis enable 1
[*P1-LoopBack1] commit
[~P1-LoopBack1] quit
# Configure P2.
[~P2] isis 1
[*P2-isis-1] network-entity 00.0005.0000.0000.0003.00
[*P2-isis-1] is-level level-2
[*P2-isis-1] quit
[*P2] interface loopback 1
[*P2-LoopBack1] isis enable 1
[*P2-LoopBack1] commit
[~P2-LoopBack1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] network-entity 00.0005.0000.0000.0004.00
[*PE2-isis-1] is-level level-2
[*PE2-isis-1] quit
[*PE2-GigabitEthernet1/0/0] isis enable 1
[*PE2] interface loopback 1
[*PE2-LoopBack1] isis enable 1
[*PE2-LoopBack1] commit
[~PE2-LoopBack1] quit
After completing the preceding configurations, run the display ip routing-table command on
each node. The command output shows that both PEs have learned routes from each other.
The command output on PE1 is used as an example.
[~PE1] display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : _public_
Destinations : 13 Routes : 13
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.9/32 Direct 0 0 D 127.0.0.1 LoopBack0

2.2.2.9/32 ISIS 15 10 D 10.1.1.2
3.3.3.9/32 ISIS 15 20 D 10.1.1.2
4.4.4.9/32 ISIS 15 30 D 10.1.1.2
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1

10.2.1.0/24 ISIS 15 20 D 10.1.1.2
10.3.1.0/24 ISIS 15 30 D 10.1.1.2
Step 3 Configure an EBGP peer relationship between each pair of a PE and a CE and an MP-IBGP
peer relationship between two PEs.
# Enable MPLS, MPLS TE, and RSVP-TE globally and in the interface view on each node,
and enable CSPF in the MPLS view of the ingress of a tunnel to be created.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] mpls te cspf
[*PE1-mpls] quit
# Configure P1.
[~P1] mpls lsr-id 2.2.2.9
[*P1] mpls
[*P1-mpls] mpls te
[*P1-mpls] mpls rsvp-te
[*P1-mpls] quit
[*P1-GigabitEthernet1/0/0] mpls
[*P1-GigabitEthernet1/0/0] mpls te
[*P1-GigabitEthernet1/0/0] mpls rsvp-te
# Configure P2.
[*P2] mpls
[*P2-mpls] mpls te
[*P2-mpls] quit


# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit

# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] traffic-eng level-2
[~PE1-isis-1] quit
# Configure P1.
[~P1] isis 1
[~P1-isis-1] cost-style wide
[*P1-isis-1] traffic-eng level-2
[*P1-isis-1] commit
[~P1-isis-1] quit
# Configure P2.
[~P2] isis 1
[~P2-isis-1] cost-style wide
[*P2-isis-1] traffic-eng level-2
[*P2-isis-1] commit
[~P2-isis-1] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] traffic-eng level-2
[~PE2-isis-1] quit

outbound interface of each device along the tunnel.
# Configure PE1.
[*PE1-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
# Configure P1.
[~P1] interface gigabitethernet 2/0/0
[~P1-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000

[*P1-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000

# Configure P2.
Step 7 Configure QoS on each PE.

# Configure multi-field classification and set a service class for each type of service packet on
PE1.
[~PE1] acl 2001
[*PE1-acl4-basic-2001] rule 10 permit source 40.0.0.0 0.255.255.255
[*PE1-acl4-basic-2001] quit
[*PE1] acl 2002
[*PE1] traffic classifier service1
[*PE1-classifier-service1] if-match acl 2001
[*PE1-classifier-service1] commit
[~PE1-classifier-service1] quit
[~PE1] traffic behavior behavior1
[*PE1-behavior-behavior1] service-class af1 color green
[*PE1-behavior-behavior1] commit
[*PE1-behavior-behavior1] quit
[~PE1-behavior-behavior2] quit
[~PE1] traffic policy policy1
[*PE1-trafficpolicy-policy1] classifier service1 behavior behavior1
[*PE1-trafficpolicy-policy1] classifier service2 behavior behavior2
[*PE1-trafficpolicy-policy1] commit
[~PE1-trafficpolicy-policy1] quit
[~PE1-GigabitEthernet2/0/0] traffic-policy policy1 inbound
Step 8 Configure MPLS TE tunnel interfaces.

# On the ingress of each tunnel, create a tunnel interface and set the IP address, tunnel
protocol, destination IP address, tunnel ID, dynamic signaling protocol, tunnel bandwidth, and
service classes for packets transmitted on the tunnel.
NOTE
Run the mpls te service-class { service-class & <1-8> | default } command to configure the service
class for packets transmitted along each tunnel.
# Configure PE1.
[~PE1] interface tunnel1
[*PE1-Tunnel1] mpls te service-class af1

[~PE1-Tunnel1] quit
[~PE1-Tunnel2] quit
[*PE1-Tunnel3] mpls te service-class default
[~PE1-Tunnel3] commit
[~PE1-Tunnel3] quit
[*PE1] tunnel-policy policy1
[*PE1-tunnel-policy-policy1] tunnel select-seq cr-lsp load-balance-number 3
[*PE1-tunnel-policy-policy1] commit
[~PE1-tunnel-policy-policy1] quit
# Configure PE2.
[~PE2-Tunnel1] quit
[*PE2-tunnel-policy-policy1] tunnel select-seq cr-lsp load-balance-number 3
[*PE2-tunnel-policy-policy1] commit
[~PE2-tunnel-policy-policy1] quit
Step 9 Configure L3VPN access on each PE.

# Configure PE1.
[~PE1] ip vpn-instance vpn1
[*PE1-vpn-instance-vpn1] ipv4-family
[*PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-vpn1-af-ipv4] tnl-policy policy1
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 both
[*PE1-vpn-instance-vpn1-af-ipv4] commit
[~PE1-vpn-instance-vpn1-af-ipv4] quit
[~PE1-vpn-instance-vpn1] quit
[~PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE1-GigabitEthernet2/0/0] commit
# Configure PE2.
[~PE2] ip vpn-instance vpn2
[*PE2-vpn-instance-vpn2] ipv4-family
[*PE2-vpn-instance-vpn2-af-ipv4] route-distinguisher 200:1
[*PE2-vpn-instance-vpn2-af-ipv4] vpn-target 111:1 both
[*PE2-vpn-instance-vpn2-af-ipv4] commit
[~PE2-vpn-instance-vpn2-af-ipv4] quit
[~PE2-vpn-instance-vpn2] quit
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn2
----End

Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
ipv4-family
tnl-policy policy1
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0001.00
#
acl number 2001
rule 10 permit source 40.0.0.0 0.255.255.255
#
acl number 2002
#
traffic classifier service1
if-match acl 2001
#
if-match acl 2002
#
traffic behavior behavior1
service-class af1 color green
#
#
traffic policy policy1
classifier service1 behavior behavior1
#
tunnel select-seq cr-lsp load-balance-number 3
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip binding vpn-instance vpn1
ip address 10.10.1.1 255.255.255.0
traffic-policy policy1 inbound
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255

isis enable 1
#
interface Tunnel1
destination 4.4.4.9
mpls te tunnel-id 1
mpls te service-class af1
#
interface Tunnel2
destination 4.4.4.9
mpls te tunnel-id 2
#
interface Tunnel3
destination 4.4.4.9
mpls te tunnel-id 3
mpls te service-class default
#
bgp 100
#
ipv4-family unicast
peer 4.4.4.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 4.4.4.9 enable
#
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#

undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.9
#
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0003.00
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
mpls lsr-id 4.4.4.9
#
mpls
mpls te
mpls rsvp-te
#
ipv4-family


#
isis 1
is-level level-2
cost-style wide
traffic-eng level-2
network-entity 00.0005.0000.0000.0004.00
#
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
mpls te
isis enable 1
mpls rsvp-te
#
undo shutdown
ip binding vpn-instance vpn2
ip address 200.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 1.1.1.9
mpls te tunnel-id 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
return
3.38.23 Example for Configuring CBTS in an L3VPN over LDP

over TE Scenario
This section provides an example for configuring a CBTS in an L3VPN over LDP over TE
scenario.
In Figure 3-42, CE1 and CE2 belong to the same L3VPN. They access a public network
through PE1 and PE2, respectively. Various types of services are transmitted between CE1
and CE2. Transmitting a large amount of common services deteriorates the efficiency of

transmitting important services. To prevent this problem, the CBTS function can be
configured. A CBTS allows traffic of a specific service class to be transmitted along a
specified tunnel.
In this example, tunnel 1 transmits important services, and tunnel 2 transmits other packets.
Figure 3-42 CBTS in an L3VPN over LDP over TE scenario

NOTE
Interfaces 1 through 2 in this example are GE1/0/0, GE2/0/0 respectively.

2.2.2.2/32 3.3.3.3/32 4.4.4.4/32
P1 10.2.1.1/24 10.3.1.1/24 P2
interface1 P3 interface2
10.2.1.2/24 10.3.1.2/24
10.1.1.2/24 10.4.1.2/24
10.1.1.1/24 10.4.1.1/24
Loopback1 Loopback1
1.1.1.1/32 PE1 PE2 5.5.5.5/32
interface2
10 .10. 1 . 1 / 24
CE1 CE2
Configuration Notes
When configuring a TE tunnel group in an L3VPN over LDP over TE scenario, note that the
destination IP address of a tunnel must be equal to the LSR ID of the egress.
1. Configure the IP address of a loopback interface as the LSR ID on each LSR and
configure an IGP to advertise routes.
2. Configure OSPF TE on TE-aware areas, create an MPLS TE tunnel, and specify the
service class for packets that can be transmitted on the tunnel.
3. Enable MPLS LDP in non-TE-aware area and configure a remote LDP peer at the edge
of the TE-aware area.
4. Configure the forwarding adjacency.
5. Configure multi-field traffic classification on nodes that connected to the L3VPN and
configure behavior aggregate classification on LDP over TE links.
Data Preparation

l OSPF process ID and OSPF area

l Policy for triggering LDP LSP establishment
l Name and IP address of each remote LDP peer of P1 and P2
l Bandwidth attributes of links along the tunnel
l Tunnel interface number, IP address, destination IP address, tunnel ID, tunnel signaling
protocol (In this example, the default protocol of RSVP-TE is used), tunnel bandwidth,
TE metric value, and link cost on each P.
l Multi-field classifier name and traffic policy name
Procedure
Assign an IP address to each interface, including the loopback interface according to Figure
3-42. For configuration details, see Configuration Files in this section.
Step 2 Enable OSPF to advertise the route of the segment connected to each interface and the host
route destined for each LSR ID. For configuration details, see Configuration Files in this
section.
Step 3 Configure an EBGP peer relationship between each pair of a PE and a CE and an MP-IBGP
peer relationship between two PEs.
Step 4 Enable MPLS on each LSR. Enable LDP to establish an LDP session between PE1 and P1,
and between P2 and PE2. Enable RSVP-TE to establish an RSVP neighbor relationship
between P1 and P2, and between P1 and P3.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] lsp-trigger all
[*PE1-mpls] quit
[*PE1] mpls ldp
[*PE1-mpls-ldp] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] mpls te
[*P1-mpls] lsp-trigger all
[*P1-mpls] mpls te cspf
[*P1-mpls] quit
[*P1] mpls ldp
[*P1-mpls-ldp] quit
[*P1-GigabitEthernet1/0/0] mpls ldp

# Configure P3.
[*P3] mpls
[*P3-mpls] mpls te
[*P3-mpls] quit
# Configure P2.
[*P2] mpls
[*P2-mpls] mpls te
[*P2-mpls] lsp-trigger all
[*P2-mpls] mpls te cspf
[*P2-mpls] quit
[*P2] mpls ldp
[*P2-mpls-ldp] quit
[*P2-GigabitEthernet2/0/0] mpls ldp
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] lsp-trigger all
[*PE2-mpls] quit
[*PE2] mpls ldp
After completing the preceding configurations, the local LDP sessions have been successfully
established between PE1 and P1 and between P2 and PE2.
# Run the display mpls ldp session command on PE1, P1, P2, or PE2 to view information
about the established LDP session.
[~PE1] display mpls ldp session
LDP Session(s) in Public Network

Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.

--------------------------------------------------------------------------
PeerID Status LAM SsnRole SsnAge KASent/Rcv
--------------------------------------------------------------------------
2.2.2.2:0 Operational DU Passive 0000:00:05 23/23
--------------------------------------------------------------------------
TOTAL: 1 Session(s) Found.
# Run the display mpls ldp peer command on PE1 to view information about the established
LDP peer.
[~PE1] display mpls ldp peer
LDP Peer Information in Public network

A '*' before a peer means the peer is being deleted.
-------------------------------------------------------------------------
PeerID TransportAddress DiscoverySource
-------------------------------------------------------------------------
2.2.2.2:0 2.2.2.2 GigabitEthernet1/0/0
-------------------------------------------------------------------------
TOTAL: 1 Peer(s) Found.
# Run the display mpls lsp command on PE1 to view information about LDP LSP
information. The command output shows that an RSVP-TE tunnel is not established. The
command output on PE1 is used as an example.
[~PE1] display mpls lsp
----------------------------------------------------------------------
LSP Information: LDP LSP
----------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
1.1.1.1/32 3/NULL GE1/0/0/-
2.2.2.2/32 NULL/3 -/GE1/0/0
2.2.2.2/32 1024/3 -/GE1/0/0
10.1.1.0/24 3/NUL GE1/0/0/-
10.2.1.0/24 NULL/3 -/GE1/0/0
10.2.1.0/24 1025/3 -/GE1/0/0
Step 5 Configure a remote LDP session between P1 and P2.

# Configure P1.
[~P1] mpls ldp remote-peer lsrd
[*P1-mpls-ldp-remote-lsrd] remote-ip 4.4.4.4
[*P1-mpls-ldp-remote-lsrd] commit
[~P1-mpls-ldp-remote-lsrd] quit
# Configure P2.
[~P2] mpls ldp remote-peer lsrb
[*P2-mpls-ldp-remote-lsrb] remote-ip 2.2.2.2
[*P2-mpls-ldp-remote-lsrb] commit
[~P2-mpls-ldp-remote-lsrb] quit
After completing the preceding configurations, a remote LDP session is set up between P1
and P2. Run the display mpls ldp remote-peer command on P1 or P2 to view information
about the remote session entity. The command output on P1 is used as an example.
[~P1] display mpls ldp remote-peer lsrd
LDP Remote Entity Information
------------------------------------------------------------------------------
Remote Peer Name: P2
Remote Peer IP : 4.4.4.4 LDP ID : 2.2.2.2:0
Transport Address : 2.2.2.2 Entity Status : Active
Configured Keepalive Hold Timer : 45 Sec

Configured Keepalive Send Timer : ----
Configured Hello Hold Timer : 45 Sec
Negotiated Hello Hold Timer : 45 Sec

Configured Hello Send Timer : ----

Configured Delay Timer : ----
Hello Packet sent/received : 425/382
------------------------------------------------------------------------------
TOTAL: 1 Remote-Peer(s) Found.
Step 6 Configure bandwidth attributes on each outgoing interface along the link of the TE tunnel.
# Configure P1.
# Configure P3.
[*P3-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 20000
# Configure P2.
Step 7 Configure L3VPN access on PE1 and PE2 and configure multi-field classification on the
inbound interface of PE1.
# Configure PE1.
[~PE1] ip vpn-instance VPNA
[*PE1-vpn-instance-VPNA] ipv4-family
[*PE1-vpn-instance-VPNA-af-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-VPNA-af-ipv4] vpn-target 111:1 both
[*PE1-GigabitEthernet2/0/0] ip binding vpn-instance VPNA
[*PE1] acl 2001
[*PE1] acl 2002
[~PE1] traffic classifier service2

[~PE1] traffic policy test

[*PE1-trafficpolicy-test] classifier service1 behavior behavior1
[*PE1-trafficpolicy-test] classifier service2 behavior behavior2
[*PE1-trafficpolicy-test] commit
[~PE1-trafficpolicy-test] quit
[~PE1-GigabitEthernet2/0/0] traffic-policy test inbound
# Configure PE2.
[~PE2] ip vpn-instance VPNB
[~PE2-vpn-instance-VPNB] ipv4-family
[~PE2-vpn-instance-VPNB-af-ipv4] route-distinguisher 200:1
[~PE2-vpn-instance-VPNB-af-ipv4] vpn-target 111:1 both
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance VPNB
Step 8 Configure behavior aggregate classification on interfaces connecting PE1 to P1.

# Configure PE1.
[~PE1-GigabitEthernet1/0/0] trust upstream default
# Configure P1.
[~P1-GigabitEthernet1/0/0] trust upstream default
Step 9 Configure a TE tunnel that originates from P1 and is destined for P2 and set the service class
for each type of packets that can pass through the tunnel.
NOTE
Run the mpls te service-class { service-class & <1-8> | default } command to configure the service
class for packets transmitted along the tunnel.
# On P1, enable the IGP shortcut function on the tunnel interface and adjust the metric value
to ensure that traffic destined for P2 or PE2 passes through the tunnel.
[~P1] interface tunnel1
[*P1-Tunnel1] ip address unnumbered interface LoopBack1
[*P1-Tunnel1] mpls te bandwidth ct0 10000
[*P1-Tunnel1] mpls te igp shortcut
[*P1-Tunnel1] mpls te igp metric absolute 1
[*P1-Tunnel1] mpls te service-class af1 af2
[*P1-Tunnel1] quit
[*P1] interface tunnel12
[*P1-Tunnel2] mpls te service-class default
[*P1-Tunnel2] quit
[*P1] ospf 1
[*P1-ospf-1] area 0
[*P1-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[*P1-ospf-1-area-0.0.0.0] quit

[*P1-ospf-1] enable traffic-adjustment advertise

[*P1-ospf-1] commit
Step 10 Configure a tunnel that originates from P2 and is destined for P1.
# On P2, enable the forwarding adjacency on the tunnel interface and adjust the metric value
of the forwarding adjacency to ensure that traffic destined for PE1 or P1 passes through the
tunnel.
[~P2] interface tunnel1
[*P2-Tunnel1] quit
[*P2] ospf 1
[*P2-ospf-1] area 0
[*P2-ospf-1] enable traffic-adjustment advertise
[*P2-Tunnel1] commit
----End
Configuration Files
#
sysname PE1
#
ip vpn-instance VPNA
ipv4-family
apply-label per-instance
#
mpls lsr-id 1.1.1.1
#
mpls
lsp-trigger all
#
mpls ldp
#
acl number 2001
#
acl number 2002
#
if-match acl 2001
#
if-match acl 2002
#
#
#
traffic policy test
share-mode


#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
trust upstream default
#
undo shutdown
ip binding vpn-instance VPNA
ip address 10.10.1.1 255.255.255.0
traffic-policy test inbound
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 5.5.5.5 enable
#
ipv4-family vpnv4
policy vpn-target
peer 5.5.5.5 enable
#
ipv4-family vpn-instance VPNA
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
lsp-trigger all
#
mpls ldp
#
ipv4-family
#
mpls ldp remote-peer lsrd
remote-ip 4.4.4.4
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls

mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Tunnel1
destination 4.4.4.4
mpls te igp shortcut
mpls te service-class af1 af2
#
interface Tunnel2
destination 4.4.4.4
mpls te service-class default
#
ospf 1
enable traffic-adjustment advertise
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
mpls-te enable
#
return
l Configuration file of P3
#
sysname P3
#
mpls lsr-id 3.3.3.3
#
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#

ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.4
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
lsp-trigger all
#
mpls ldp
#
ipv4-family
#
mpls ldp remote-peer lsrb
remote-ip 2.2.2.2
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
interface Tunnel1
destination 2.2.2.2
#
ospf 1
enable traffic-adjustment advertise
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname PE2

#
ip vpn-instance VPNB
ipv4-family
apply-label per-instance
#
mpls lsr-id 5.5.5.5
#
mpls
lsp-trigger all
#
mpls ldp
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip binding vpn-instance VPNB
ip address 200.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance VPNB
#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 10.4.1.0 0.0.0.255
#
return
3.38.24 Example for Configuring CBTS in a VLL over TE Scenario
In Figure 3-43, CE1 and CE2 belong to the same VLL network. They access the MPLS
backbone network through PE1 and PE2, respectively. OSPF is used as an IGP on the MPLS
backbone network.
It is required that a Martini VLL and the dynamic signaling protocol RSVP-TE be used to
establish two MPLS TE tunnels between PE1 and PE2 to transmit VLL services. Each TE
tunnel is assigned a specific priority. Interfaces that receive VLL packets have behavior
aggregate classification enabled and trust 8021.p priority values so that they can forward VLL
packets with a specific priority to a specific tunnel.

TE1 tunnel with ID 100 is established over the path PE1 –> P1 –> PE2, and TE2 tunnel
with ID 200 is established over the path PE1 –> P2 –> PE2. AF1 is configured on TE1
interface, and AF2 is configured on TE2 interface. This configuration allows PE1 to forward
traffic with service class AF1 along TE1 tunnel and traffic with service class AF2 along TE2
tunnel. The two tunnels can load-balance traffic based on priority values.
Note that if multiple tunnels with AF1 are established between PE1 and PE2, packets mapped
to AF1 are load-balanced along these tunnels.
When CBTS is configured, do not configure the following services:

l Seamless MPLS
Figure 3-43 CBTS networking in a VLL over TE scenario

NOTE
Interfaces 1 through 10 in this example are GE2/0/1, GE2/0/2.1, GE2/0/3, GE5/0/1, GE5/0/0, GE3/0/1,
GE4/0/1, GE3/0/3, GE4/0/0, GE1/0/1.1 respectively.
Loopback1
2.2.2.9
interface6 Loopback1
10.1.2.2/24 4.4.4.9
1.1.1.9 10.1.4.1/24
10.1.2.1/24 10.1.4.2/24
PE1 P1 PE2

10.1.3.2/24 10.1.5.1/24
10.1.1.1/24 P2 10.1.1.2/24
Loopback1
3.3.3.9
CE1 CE2
l Enable an IGP on the MPLS backbone network for devices on the backbone network to
communicate.
l Establish MPLS TE tunnels and configure a tunnel policy. For details about how to
configure an MPLS TE tunnel, see "MPLS TE Configuration" in HUAWEI
l Enable MPLS Layer 2 virtual private network (L2VPN) on the PEs.
l Create a VLL, configure LDP as a signaling protocol, and bind the VLL to an AC
interface on each PE.

l Configure MPLS TE tunnels to transmit VLL packets.
Data Preparation
l OSPF area enabled with TE
l VLL name and VLL ID
l IP addresses of peers and tunnel policy
l Name of AC interfaces bound to a VLL
l Interface number and IP address of each tunnel interface, as well as destination IP
address, tunnel ID, tunnel signaling protocol (RSVP-TE), and tunnel bandwidth to be
specified on each tunnel interface
Procedure
Configure the IP address and mask for each interface according to Figure 3-43.
Step 2 Enable MPLS, MPLS TE, MPLS RSVP-TE, and MPLS CSPF.
On the nodes along each MPLS TE tunnel, enable MPLS, MPLS TE, and MPLS RSVP-TE
both in the system view and the interface view. On the ingress node of each tunnel, enable
MPLS CSPF in the system view.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] interface gigabitethernet2/0/1
[*PE1] commit
[*P1] commit
# Configure P1.
[*P1] mpls
[*P1-mpls] mpls te
[*P1-mpls] quit
[*P1] interface gigabitethernet3/0/1


[*P1] commit
# Configure P2.
[*P2] mpls
[*P2-mpls] mpls te
[*P2-mpls] quit
[*P2] commit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te
[*PE2-mpls] quit
[*PE2] commit
[*PE2] commit
Step 3 Enable OSPF and OSPF TE on the MPLS backbone network.

# Configure PE1.
[~PE1] ospf
[*PE1-ospf-1] opaque-capability enable
[*PE1-ospf-1] area 0.0.0.0
[*PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[*PE1-ospf-1-area-0.0.0.0] mpls-te enable
[*PE1-ospf-1-area-0.0.0.0] quit
[*PE1-ospf-1] quit
[*PE1] commit
# Configure P1.
[~P1] ospf
[*P1-ospf-1] opaque-capability enable
[*P1-ospf-1] area 0.0.0.0
[*P1-ospf-1-area-0.0.0.0] mpls-te enable
[*P1-ospf-1] quit

[*P1] commit
# Configure P2.
[~P2] ospf
[*P2-ospf-1] area 0.0.0.0
[*P2-ospf-1] quit
[*P2] commit
# Configure PE2.
[~PE2] ospf
[*PE2-ospf-1] area 0.0.0.0
[*PE2-ospf-1] quit
[*PE2] commit
# Create tunnel interfaces on PEs, configure MPLS TE as a tunnel protocol and RSVP-TE as
a signaling protocol, and specify priorities.
# Configure PE1.
[*PE1-Tunnel10] ip address unnumbered interface loopback1
[*PE1-Tunnel10] quit
[*PE1] commit
[*PE1] commit
After completing the preceding configurations, run the display this interface command in the
tunnel interface view. The command output shows that the Line protocol current state field
is UP, indicating that an MPLS TE tunnel has been successfully established.
Run the display tunnel-info all command in the system view on PE1. The command output
shows that two TE tunnels destined for PE2 with the LSR ID of 4.4.4.9 have been established.
The command output on PE2 is similar to that on PE1.
<PE1> display tunnel-info all
* -> Allocated VC Token
Tunnel ID Type Destination Token
----------------------------------------------------------------------
0xc2060404 cr lsp 4.4.4.9 132100
0xc2060405 cr lsp 4.4.4.9 132101

Step 5 Configure MPLS TE explicit paths.

Specify an explicit path for each tunnel with a physical interface on the P as the first next hop
and a physical interface on PE2 as the second next hop to ensure that two tunnels are built
over different links.
# Configure PE1.
[PE1] explicit-path t1
[*PE1-explicit-path-t1] next hop 10.1.2.2
[*PE1-explicit-path-t1] quit
[*PE1] commit
[*PE1] commit
[PE1] interface Tunnel 10
[*PE1-Tunnel10] mpls te path explicit-path t1
[*PE1] commit
[*PE1] commit
Step 6 Configure a remote LDP session.

Establish a remote LDP session between PE1 and PE2.
# Configure PE1.
[PE1] mpls ldp
[*PE1] mpls ldp remote-peer DTB1
[*PE1-mpls-ldp-remote-DTB] remote-ip 4.4.4.9
[*PE1] commit
# Configure PE2.
[PE2] mpls ldp
[*PE2-mpls-ldp-remote-DTB2] remote-ip 1.1.1.9
[*PE2] commit
After completing the preceding configurations, run the display mpls ldp peer command. A
remote LDP session has been established between the two PEs.
The following command output uses the display on PE1.
<PE1> display mpls ldp peer
A '*' before a peer means the peer is being deleted.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
4.4.4.9:0 4.4.4.9 Remote Peer : DTB1
------------------------------------------------------------------------------
Step 7 Configure a tunnel policy.

# Configure PE1.
[PE1] tunnel-policy p1
[*PE1-tunnel-policy-p1] tunnel select-seq cr-lsp load-balance-number 2

[*PE1-tunnel-policy-p1] quit
[*PE1] commit
Step 8 Enable MPLS L2VPN on PEs.

# Configure PE1.
[PE1] mpls l2vpn
[*PE1-l2vpn] quit
[*PE1] commit
# Configure PE2.
[*PE2] mpls l2vpn
[*PE2-l2vpn] quit
[*PE2] commit
Step 9 Create a VLL on PEs and bind it to the tunnel policy.

# Configure PE1.
[PE1] interface gigabitethernet2/0/2.1
[*PE1-GigabitEthernet2/0/2.1] vlan-type dot1q 10
[*PE1-GigabitEthernet2/0/2.1] mpls l2vc 4.4.4.9 1 tunnel-policy p1
[*PE1-GigabitEthernet2/0/2.1] trust upstream default
[*PE1-GigabitEthernet2/0/2.1] trust 8021p
[*PE1-GigabitEthernet2/0/2.1] undo shutdown
[*PE1-GigabitEthernet2/0/2.1] commit
# Configure PE2.
[*PE2-GigabitEthernet2/0/2.1] mpls l2vc 1.1.1.9 1
[*PE2-GigabitEthernet2/0/2.1] quit
# Configure CE1.
[CE1] interface gigabitethernet1/0/0.1
[*CE1-GigabitEthernet1/0/0.1] shutdown
[*CE1-GigabitEthernet1/0/0.1] vlan-type dot1q 10
[*CE1-GigabitEthernet1/0/0.1] ip address 10.1.1.1 255.255.255.0
[*CE1-GigabitEthernet1/0/0.1] undo shutdown
[*CE1-GigabitEthernet1/0/0.1] quit
# Configure CE2.
[*CE2-GigabitEthernet1/0/0.1]shutdown

After completing the preceding configurations, run display mpls l2vc command on PE1.
The command output shows that the values in the AC Status and VC State fields are up, and
there are two tunnel IDs. Two tunnels have been established between PE1 and PE2.
<PE1>display mpls l2vc interface GigabitEthernet2/0/2.1
*client interface : GigabitEthernet2/0/2.1 is up
Administrator PW : no
session state : up
AC status : up
VC state : up
Label state : 0

Token state : 0
VC ID : 1
VC type : VLAN
destination : 4.4.4.9
local group ID : 0 remote group ID : 0
local VC label : 32768 remote VC label : 32768
local AC OAM State : up
local PSN OAM State : up
local forwarding state : forwarding
local status code : 0x0 (forwarding)
remote AC OAM state : up
remote PSN OAM state : up
remote forwarding state: forwarding
remote status code : 0x0 (forwarding)
ignore standby state : no
BFD for PW : unavailable
VCCV State : up
manual fault : not set
active state : active
forwarding entry : exist
OAM Protocol : --
OAM Status : --
OAM Fault Type : --
TTL Value : --
link state : up
local VC MTU : 1500 remote VC MTU : 1500
local VCCV : alert ttl lsp-ping bfd
remote VCCV : alert ttl lsp-ping bfd
local control word : disable remote control word : disable
tunnel policy name : 1
PW template name : --
primary or secondary : primary
load balance type : flow
Access-port : false
Switchover Flag : false
VC tunnel info : 2 tunnels
NO.0 TNL type : te , TNL ID : 0x00000000030000000a
NO.1 TNL type : te , TNL ID : 0x000000000300000003
create time : 0 days, 0 hours, 9 minutes, 58 seconds
up time : 0 days, 0 hours, 7 minutes, 41 seconds
last change time : 0 days, 0 hours, 7 minutes, 41 seconds
VC last up time : 2014/05/23 10:13:29
VC total up time : 0 days, 0 hours, 7 minutes, 41 seconds
CKey : 1
NKey : 989855833
PW redundancy mode : frr
AdminPw interface : --
AdminPw link state : --
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : --
Domain Name : --
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#

explicit-path t1
next hop 10.1.2.2
next hop 10.1.4.2
#
explicit-path t2
next hop 10.1.3.2
next hop 10.1.5.2
#
mpls l2vpn
#
mpls ldp
#
ipv4-family
#
mpls ldp remote-peer DTB1
remote-ip 4.4.4.9
#
interface GigabitEthernet2/0/2.1
undo shutdown
vlan-type dot1q 10
mpls l2vc 4.4.4.9 1 tunnel-policy 1
trust 8021p
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel10
destination 4.4.4.9
mpls te path explicit-path t1
#
interface Tunnel11
destination 4.4.4.9
#
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
mpls-te enable
#
tunnel-policy p1

#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.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 10.1.2.0 0.0.0.255
network 10.1.4.0 0.0.0.255
mpls-te enable
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.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
area 0.0.0.0

network 3.3.3.9 0.0.0.0

network 10.1.3.0 0.0.0.255
network 10.1.5.0 0.0.0.255
mpls-te enable
#
return

#
sysname PE2
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls l2vpn
#
mpls ldp
#
ipv4-family
#
remote-ip 1.1.1.9
#
undo shutdown
vlan-type dot1q 10
mpls l2vc 1.1.1.9 1
#
undo shutdown
ip address 10.1.4.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.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 10.1.4.0 0.0.0.255
network 10.1.5.0 0.0.0.255
mpls-te enable
#
return

#
sysname CE1
#
undo shutdown
vlan-type dot1q 10
ip address 10.1.1.1 255.255.255.0
#
return


#
sysname CE2
#
undo shutdown
vlan-type dot1q 10
ip address 10.1.1.2 255.255.255.0
#
return
3.38.25 Example for Configuring CBTS in a VPLS over TE

Scenario
In Figure 3-44, CE1 and CE2 belong to the same VPLS network. They access the MPLS
backbone network through PE1 and PE2, respectively. OSPF is used as an IGP on the MPLS
backbone network.
It is required that a Martini VPLS tunnel and the dynamic signaling protocol RSVP-TE be
used to establish two MPLS TE tunnels between PE1 and PE2 to transmit VPLS services.
Each TE tunnel is assigned a specific priority. Interfaces that receive VPLS packets have
behavior aggregate classification enabled and trust 8021.p priority values so that they can
forward VPLS packets with a specific priority to a specific tunnel.
TE1 tunnel with ID 100 is established over the path PE1 –> P1 –> PE2, and TE2 tunnel
with ID 200 is established over the path PE1 –> P2 –> PE2. AF1 is configured on TE1
interface, and AF2 is configured on TE2 interface. This configuration allows PE1 to forward
traffic with service class AF1 along TE1 tunnel and traffic with service class AF2 along TE2
tunnel. The two tunnels can load-balance traffic based on priority values.
Note that if multiple tunnels with AF1 are established between PE1 and PE2, packets mapped
to AF1 are load-balanced along these tunnels.
When CBTS is configured, do not configure the following services:

l Seamless MPLS
Figure 3-44 CBTS networking in a VPLS over TE scenario

NOTE
Interfaces 1 through 10 in this example are GE2/0/1, GE2/0/2.1, GE2/0/3, GE5/0/1, GE5/0/0, GE3/0/1,
GE4/0/1, GE3/0/3, GE4/0/0, GE1/0/0.1 respectively.

Loopback1
2.2.2.9
interface6 Loopback1
10.1.2.2/24 4.4.4.9
1.1.1.9 10.1.4.1/24
10.1.2.1/24 10.1.4.2/24
PE1 P1 PE2

10.1.3.2/24 10.1.5.1/24
10.1.1.1/24 P2 10.1.1.2/24
Loopback1
3.3.3.9
CE1 CE2
l Enable an IGP on the MPLS backbone network for devices on the backbone network to
communicate.
l Establish MPLS TE tunnels and configure a tunnel policy. For details about how to
configure an MPLS TE tunnel, see "MPLS TE Configuration" in HUAWEI
l Enable MPLS Layer 2 virtual private network (L2VPN) on the PEs.
l Create a virtual switching instance (VSI), configure LDP as a signaling protocol, and
bind the VSI to an AC interface on each PE.
l Configure MPLS TE tunnels to transmit VSI packets.
Data Preparation
l OSPF area enabled with TE

l VSI name and VSI ID
l IP addresses of peers and tunnel policy
l Names of AC interfaces bound to the VSI
l Interface number and IP address of each tunnel interface, as well as destination IP
address, tunnel ID, tunnel signaling protocol (RSVP-TE), and tunnel bandwidth to be
specified on each tunnel interface
Procedure
Step 1 Assign an IP address to each interface on the backbone network. For configuration details, see
Step 2 Enable MPLS, MPLS TE, MPLS RSVP-TE, and MPLS CSPF.

On the nodes along each MPLS TE tunnel, enable MPLS, MPLS TE, and MPLS RSVP-TE
both in the system view and the interface view. On the ingress node of each tunnel, enable
MPLS CSPF in the system view.
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] commit
[*PE1] commit
# Configure P1.
[*P1] mpls
[*P1-mpls] mpls te
[*P1-mpls] quit
[*P1] commit
# Configure P2.
[*P2] mpls
[*P2-mpls] mpls te
[*P2-mpls] quit
[*P2] commit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] mpls te


[*PE2-mpls] quit
[*PE2] commit
[*PE2] commit
Step 3 Enable OSPF and OSPF TE on the MPLS backbone network.
# Configure PE1.
[~PE1] ospf
[*PE1-ospf-1] area 0.0.0.0
[*PE1-ospf-1] quit
[*PE1] commit
# Configure P1.
[~P1] ospf
[*P1-ospf-1] area 0.0.0.0
[*P1-ospf-1] quit
[*P1] commit
# Configure P2.
[~P2] ospf
[*P2-ospf-1] area 0.0.0.0
[*P2-ospf-1] quit
[*P2] commit
# Configure PE2.
[~PE2] ospf
[*PE2-ospf-1] area 0.0.0.0
[*PE2-ospf-1] quit
[*PE2] commit

# Create tunnel interfaces on PEs, configure MPLS TE as a tunnel protocol and RSVP-TE as
a signaling protocol, and specify priorities.
# Configure PE1.
[*PE1] commit
[*PE1] commit
After completing the preceding configurations, run the display this interface command in the
tunnel interface view. In the command output, Line protocol current state is UP, indicating
that the MPLS TE tunnel has been established.
Run the display tunnel-info all command in the system view on PE1. The command output
shows that two TE tunnels destined for PE2 with the LSR ID of 4.4.4.9 have been established.
The command output on PE2 is similar to that on PE1.
<PE1> display tunnel-info all
* -> Allocated VC Token
Tunnel ID Type Destination Token
----------------------------------------------------------------------
0xc2060404 cr lsp 4.4.4.9 132100
0xc2060405 cr lsp 4.4.4.9 132101
Step 5 Configure MPLS TE explicit paths.
Specify an explicit path for each tunnel with a physical interface on the P as the first next hop
and a physical interface on PE2 as the second next hop to ensure that two tunnels are built
over different links.
# Configure PE1.
[*PE1] commit
[*PE1] commit
[*PE1] commit
[*PE1] commit

Step 6 Configure a remote LDP session.

Establish a remote LDP session between PE1 and PE2.
# Configure PE1.
[PE1] mpls ldp
[*PE1-mpls-ldp-remote-DTB1] quit
[*PE1] commit
# Configure PE2.
[PE2] mpls ldp
[*PE2-mpls-ldp-remote-DTB2] quit
[*PE2] commit
After completing the preceding configurations, run the display mpls ldp peer command. A
remote LDP session has been established between the two PEs.
The following command output uses the display on PE1.
<PE1> display mpls ldp peer
An asterisk (*) before a peer means the peer is being deleted.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
4.4.4.9:0 4.4.4.9 Remote Peer : DTB1
------------------------------------------------------------------------------
Step 7 Configure a tunnel policy.

# Configure PE1.
[PE1] tunnel-policy p1
[*PE1-tunnel-policy-p1] tunnel select-seq cr-lsp load-balance-number 2
[*PE1-tunnel-policy-p1] quit
[*PE1] commit
Step 8 Enable MPLS L2VPN on PEs.

# Configure PE1.
[PE1] mpls l2vpn
[*PE1-l2vpn] quit
[*PE1] commit
# Configure PE2.
[*PE2] mpls l2vpn
[*PE2-l2vpn] quit
[*PE2] commit
Step 9 Create a VSI and bind it to the tunnel policy on PEs.

# Configure PE1.
[PE1] vsi a2 static
[*PE1-vsi-a2] pwsignal ldp
[*PE1-vsi-a2-ldp] vsi-id 2
[*PE1-vsi-a2-ldp] peer 4.4.4.9 tnl-policy p1
[*PE1-vsi-a2-ldp] quit

[*PE1-vsi-a2] quit
[*PE1] commit
# Configure PE2.
[PE2] vsi a2 static
[*PE2-vsi-a2] pwsignal ldp
[*PE2-vsi-a2-ldp] vsi-id 2
[*PE2-vsi-a2-ldp] peer 1.1.1.9 tnl-policy p1
[*PE2-vsi-a2-ldp] quit
[*PE2-vsi-a2] quit
[*PE2] commit
Step 10 Bind the VSI to the interfaces of the PEs.

# Configure PE1.
[*PE1-GigabitEthernet2/0/2.1] l2 binding vsi a2
[*PE1-GigabitEthernet2/0/2.1] trust upstream default
[*PE1-GigabitEthernet2/0/2.1] trust 8021p
# Configure PE2.
[*PE2-GigabitEthernet2/0/2.1] l2 binding vsi a2
# Configure CE1.
[*CE1-GigabitEthernet1/0/0.1] shutdown
# Configure CE2.
[*CE2-GigabitEthernet1/0/0.1]shutdown

After completing the preceding configurations, run the display vsi name a2 verbose
command on PE1. The command output shows that the VSI named a2 has been established
over a PW to PE and the PW State is up. The command output also shows that there are two
tunnel IDs, which indicates that two tunnels have been established between PE1 and PE2.
<PE1> display vsi name a2 verbose
***VSI Name : a2
Administrator VSI : no
Isolate Spoken : disable
VSI Index : 0
PW Signaling : ldp
Member Discovery Style : static
PW MAC Learn Style : unqualify
Encapsulation Type : vlan
MTU : 1500
......

VSI ID : 2
*Peer Router ID : 4.4.4.9
VC Label : 162816
Peer Type : dynamic
Session : up
Tunnel ID : 0xc2060404 0xc2060405
......
**PW Information:
*Peer Ip Address : 4.4.4.9
PW State : up
Local VC Label : 162816
Remote VC Label : 162816
PW Type : label
Tunnel ID : 0xc2060404 0xc2060405
......
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path t1
next hop 10.1.2.2
next hop 10.1.4.2
#
explicit-path t2
next hop 10.1.3.2
next hop 10.1.5.2
#
mpls l2vpn
#
mpls ldp
#
ipv4-family
#
remote-ip 4.4.4.9
#
vsi a2 static
pwsignal ldp
vsi-id 2
peer 4.4.4.9 tnl-policy p1
#
undo shutdown
vlan-type dot1q 10
l2 binding vsi a2
trust 8021p
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown

ip address 10.1.3.1 255.255.255.0

mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface Tunnel10
destination 4.4.4.9
#
interface Tunnel11
destination 4.4.4.9
#
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
mpls-te enable
#
tunnel-policy p1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.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 10.1.2.0 0.0.0.255

network 10.1.4.0 0.0.0.255

mpls-te enable
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.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
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.1.3.0 0.0.0.255
network 10.1.5.0 0.0.0.255
mpls-te enable
#
return
#
sysname PE2
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls l2vpn
#
vsi a2 static
pwsignal ldp
vsi-id 2
peer 1.1.1.9 tnl-policy p1
#
mpls ldp
#
ipv4-family
#
remote-ip 1.1.1.9
#
undo shutdown
vlan-type dot1q 10
l2 binding vsi a2

#
undo shutdown
ip address 10.1.4.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.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 10.1.4.0 0.0.0.255
network 10.1.5.0 0.0.0.255
mpls-te enable
#
return

#
sysname CE1
#
undo shutdown
vlan-type dot1q 10
ip address 10.1.1.1 255.255.255.0
#
return

#
sysname CE2
#
undo shutdown
vlan-type dot1q 10
ip address 10.1.1.2 255.255.255.0
#
return

01-03 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-03 MPLS TE Configuration

Uploaded by

Copyright:

Available Formats

HUAWEI NetEngine40E Universal Service Router

Configuration Guide - MPLS 3 MPLS TE Configuration

About This Chapter

3.1 Overview of MPLS TE

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 22

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 23

3.22 Configuring MPLS TE Manual FRR

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 24

3.1 Overview of MPLS TE

3.2 Licensing Requirements and Limitations for MPLS TE

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 25

Restrictions and Guidelines

A loopback interface None If an LSR ID is not set to a

The destination IP address None If an LSR ID is not set to a

If a TE tunnel group and None If a TE tunnel group is

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 26

Restrictions Guidelines Impact

The TE group feature None Non-LPUF-50/LPUF-50-L/

After re-marking is After re-marking is In a TE tunnel group

In a TE tunnel group None In a TE tunnel group

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 27

Restrictions Guidelines Impact

VPN QoS is not supported None When VLL/VPLS traffic is

When VPN traffic is iterated VPN-based BFD is Protocol convergence is

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 28

Restrictions Guidelines Impact

DS-TE: None None

When a Huawei forwarder Do not specify an initiated The forwarder cannot

PCEP is used only to If both PCEP and The Huawei controller

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 29

Restrictions Guidelines Impact

Entropy label feature: None None

A neighbor node supports None If the RSVP-TE Hello

In an LDP over TE scenario, In the preceding scenario, a If no remote LDP session is

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 30

Restrictions Guidelines Impact

If a TE tunnel passes Plan all TE tunnels within A tunnel fails to be

When you configure a split None None

If the mpls te timer auto- None Automatic bandwidth

The include and exclude None The configuration fails.

When the bidirectional None The configuration fails.

The bidirectional co-routed None The configuration fails.

A primary tunnel cannot be None The configuration fails.

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 31

Restrictions Guidelines Impact

The bandwidth configured None The configuration fails.

The FF style is mutually None The configuration fails.

The FF style is mutually None The configuration fails.

Bit error-triggered switching None The configuration fails.

Hot standby is mutually None The latest configuration

Hot standby is mutually None The configuration fails.

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 32

Restrictions Guidelines Impact

Ordinary backup is mutually None The configuration fails.

Fast reroute is mutually None The configuration fails.

A bypass tunnel is mutually None The configuration fails.

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 33

Restrictions Guidelines Impact

A protected interface is None The configuration fails.

The best-effort path function None The configuration fails.

Soft preemption is mutually None The configuration fails.

The bypass attribute is None The configuration fails.

Issue 01 (2018-12-05) Copyright © Huawei Technologies Co., Ltd. 34

Restrictions Guidelines Impact