01-05 Segment Routing Configuration

CloudEngine 12800 Series Switches
Configuration Guide - MPLS 5 Segment Routing Configuration
5 Segment Routing Configuration
5.1 Overview of Segment Routing

5.2 Understanding Segment Routing
5.3 Application Scenarios for Segment Routing
This section describes application scenarios of segment routing.
5.4 Licensing Requirements and Limitations for Segment Routing
5.5 Default Settings for Segment Routing
This section describes default settings for SR-MPLS TE.
5.6 Configuring SR-MPLS TE
5.7 Configuring SR-MPLS BE
This chapter describes segment routing-best effort (SR-MPLS BE) implementation
and configuration procedure.
5.1 Overview of Segment Routing

Definition
Segment routing (SR) is a protocol designed to forward data packets on a network
based on source routes. Segment routing MPLS is segment routing based on the
MPLS forwarding plane, which is segment routing for short hereafter. Segment
routing divides a network path into several segments and assigns a segment ID to
each segment and network forwarding node. The segments and nodes are
sequentially arranged (segment list) to form a forwarding path.
Segment routing encodes the segment list identifying a forwarding path into a
data packet header. The segment ID is transmitted along with the packet. After
receiving the data packet, the receive end parses the segment list. If the top
segment ID in the segment list identifies the local node, the node removes the
segment ID and proceeds with the follow-up procedure. If the top segment ID
does not identify the local node, the node uses the Equal Cost Multiple Path
(ECMP) algorithm to forward the packet to a next node.
Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 289

Purpose
With the progress of the times, more and more types of services pose a variety of
network requirements. For example, real-time UC&C applications prefer paths with
low delay and low jitter, while big data applications prefer high bandwidth tunnels
with a low packet loss rate. In this situation, the rule helping the network adapt to
service growth cannot catch up with the rapid service development and even
makes network deployment more complex and difficult to maintain.
The solution is to allow services to drive network development and to define the
network architecture. Specifically, an application raises requirements (on the delay,
bandwidth, and packet loss rate). A controller collects information, such as
network topology, bandwidth usage, and delay information and computes an
explicit path that meets the service requirements.
Segment routing emerges in this context. Segment routing is used to simply define
an explicit path. Nodes need to merely maintain the segment routing information
to adapt to rapid service growth in real time. Segment routing has the following
characteristics:
● Extends existing protocols such as IGP to allow for better smooth evolution of
live networks.
● Supports both the controller's centralized control mode and forwarder's
distributed control mode, providing a balance between centralized control and
distributed control.
● Uses the source routing technique to provide capabilities of rapid interaction
between networks and upper-layer applications.
Benefits
Segment routing offers the following benefits:
● Simplifies the control plane of the MPLS network.
A controller or an IGP is used to uniformly compute paths and distribute
labels, without using tunnel protocols such as RSVP-TE and LDP. Segment
routing can be directly applied to the MPLS architecture without any change
in the forwarding plane.
● Provides efficient topology independent-loop-free alternate (TI-LFA) FRR
protection for fast path failure recovery.
Based on the segment routing technique, combined with the RLFA (Remote
Loop-free Alternate) FRR algorithm, an efficient TI-LFA FRR algorithm is
formed. TI-LFA FRR supports node and link protection of any topology and
overcomes drawbacks in conventional tunnel protection.
● Provides the higher network capacity expansion capability.
MPLS TE is a connection-oriented technique. To maintain connections, nodes
need to send and process a large number of Keepalive packets, posing heavy
burdens on the control plane. Segment routing controls any service paths by
merely operating labels on the ingress node, and transit nodes do not have to
maintain path information, reducing burdens on the control plane.
In addition, the number of labels for the SR technique is the sum of the
number of nodes on the entire network and local adjacencies, which is related
only to the network scale and irrelevant to the number of tunnels and service
scale.

● Better smooth evolution to SDN networks.

Segment routing is designed based on source routes. Using the source node
alone can control forwarding paths over which packets are transmitted across
a network. The segment routing technique and the centralized path
computing module are used together to flexibly and conveniently control and
adjust paths.
Segment routing supports both traditional networks and SDN networks. It is
compatible with existing devices and ensures smooth evolution of existing
networks to SDN networks instead of subverting existing networks.
5.2 Understanding Segment Routing
5.2.1 Segment Routing Implementation
Basic Concepts
Segment routing involves the following concepts:
● Segment routing domain: is a set of SR nodes.
● Segment ID (SID): uniquely identifies a segment. A SID is mapped to an MPLS
label on the forwarding plane.
● SRGB: A segment routing global block (SRGB) is a set of local labels reserved
for segment routing of users.
Segment Category
Table 5-1 Segment category
Label Generation Function

Mode
Prefix Manually A prefix segment identifies the prefix of a

segment configured. destination address.
An IGP floods a prefix segment to the other
network elements. The prefix segment is visible
globally and takes effect globally.
A prefix segment is identified by the prefix SID. A
prefix SID is an offset within the SRGB range and
advertised by a source node. The receive end uses
the local SRGB to compute label values to
generate MPLS forwarding entries.
The node segment, a special prefix segment,
identifies a specific node. When an IP address is
configured for a loopback interface of a node, the
prefix SID is the node SID.

Label Generation Function

Mode
Adjacency Allocated by An adjacency segment identifies an adjacency on a

segment the ingress network.
node using a An IGP floods an adjacency segment to the other
dynamic network elements. The adjacency segment is
protocol. visible globally and takes effect locally.
An adjacency segment is identified by the
adjacency SID. The adjacency SID is a local SID out
of the SRGB range.
Figure 5-1 shows an example of adjacency SIDs, prefix SIDs, and node SIDs.
Figure 5-1 Adjacency SIDs, prefix SIDs, and node SIDs

101 102 103
1001 1003 16003
16001
10.1.1.0/24 10.3.1.0/24
1002
Adjacency SID: 1001, 1002, 1003

16002
Prefix SID: 16001, 16002, 16003
10.2.1.0/24
Node SID: 101, 102, 103
In simple words, a prefix segment indicates a destination address, and an

adjacency segment indicates a link over which data packets travel. The prefix and
adjacency segments are similar to the destination IP address and outbound
interface, respectively, in conventional IP forwarding. In an IGP domain, an NE
floods the node SID and adjacency SID of itself by using an extended IGP message,
so that any NE can obtain information of other network elements.
Combining prefix (node) SIDs and adjacency SIDs in sequence can construct any
network path. Every hop on a path identifies a next hop based on the segment
information on the top of the label stack. The segment information is stacked in
sequence at the top of the data header. If segment information at the stack top
contains the identifier of another node, the receive end forwards a data packet to
the next hop using ECMP. If segment information at the stack top identifies the
local node, the receive end removes the top segment and proceeds with the
follow-up procedure.
In actual application, the prefix segment, adjacency segment, and node segment
can be used independently or in combinations. The following three main cases are
involved.
Prefix Segment
The prefix segment-based forwarding path is calculated by the IGP through
shortest path first (SPF). As shown in Figure 5-2, node Z is the destination node

and its prefix SID is 100. After the prefix SID is flooded using an IGP, all devices in
the IGP domain learn the prefix SID of node Z, and then obtain the shortest path
(with the lowest overhead) to node Z through SPF.
Figure 5-2 Prefix segment-based forwarding path

100 100 100
B D F
Cost:1 Cost:1
100
Cost:1 Cost:1
A Primary Z
Loopback
path
Cost:10 Cost:10 Cost:10 X.X.X.X
Secondary Prefix SID=100
path
Cost:2 Cost:2
Cost:2 Cost:2
C E G
If multiple paths have the same cost, they perform ECMP. If they have different
costs, they perform link backup. Therefore, prefix segment-based forwarding path
is not a fixed path, and the ingress node cannot control the entire packet
forwarding path.
Adjacency Segment
As shown in Figure 5-3, an adjacency segment is allocated to each adjacency on
the network, and a segment list with multiple adjacency segments is defined on
the ingress node. In this manner, any strict explicit path can be specified. This
mode can better implement SDN.
Figure 5-3 Adjacency segment-based forwarding path

2004
4005 4005
5007 5007
1002 7009 7009
2004 B D F
4005 2004
5007
7009 1002
A Z
4005
5007
7009
C E G
5007
7009 7009
Adjacency Segment + Node Segment

As shown in Figure 5-4, the adjacency segment and node segment are combined.
Adjacency segments can be used to force the entire path to contain an adjacency.

Nodes can use node segments to compute the shortest path based on SPF or to
load-balance traffic among paths. In this mode, paths are not strictly fixed, and
therefore, they are also called loose explicit paths.
Figure 5-4 Adjacency segment + node segment-based forwarding path

101
4005 4005
100 100
B D Node F
101
4005 SID=101
100
A Z
Pop
4005
Loopback
X.X.X.X
Prefix SID=100
C E G
100 100
SR Forwarding Mechanism
SR can be used directly in the MPLS architecture, where the forwarding
mechanism remains unchanged. SIDs are encoded as MPLS labels. The segment
list is encoded as a label stack. The segment to be processed is at the stack top.
Once a segment is processed, its label is removed from a label stack.
Label Conflicts and Handling Rules

Prefix segments are manually configured. These settings on different devices may
conflict with one another. Label conflicts are divided as follows:
● Prefix conflict: The same prefix is associated with two different SIDs.
● SID conflict: The same SID is associated with different prefixes.
If label conflicts occur, handle prefix conflicts before SID conflicts and use the
following rules to preferentially select a route:
1. A prefix with a larger mask is preferred.
2. The prefix of a smaller value is preferred.
3. A smaller SID is preferred.
For example, label conflicts occur in the following four routes (in the format of
prefix/mask SID):
● a. 1.1.1.1/32 1
● b. 1.1.1.1/32 2
● c. 2.2.2.2/32 3
● d. 3.3.3.3/32 1
The process of handling the label conflicts is as follows:

1. Prefix conflicts are handled first. Routes a and b lead to a prefix conflict.
Route a has a smaller SID than route b, so route a is preferred. After the
conflict is handled, the following three routes are selected:
– a. 1.1.1.1/32 1
– c. 2.2.2.2/32 3
– d. 3.3.3.3/32 1
2. SID conflicts are handled then. Routes a and d lead to a SID conflict. Route a
has a smaller prefix than route d, so route a is preferred. After the conflict is
handled, the following two routes are selected:
– a. 1.1.1.1/32 1
– c. 2.2.2.2/32 3
5.2.2 SR LSP
SR LSPs are established using the segment routing technique, and use a prefix or
node segment to guide data packet forwarding. Segment Routing Best Effort (SR-
MPLS BE) uses an IGP to run the shortest path algorithm to compute an optimal
SR LSP.
The establishment and data forwarding of SR LSPs are similar to those of LDP
LSPs. SR LSPs have no tunnel interfaces.
SR LSP Creation
Creating an SR LSP involves the following operations:
● Devices report topology information to a controller (if the controller is used to

create an LSP) and are assigned labels.
● The devices compute paths.
SR LSPs are created primarily using prefix labels. A destination node runs an IGP
to advertise prefix SIDs, and forwarders parse them and compute label values
based on local SRGBs. Each node then runs an IGP to collect topology information,
runs the SPF algorithm to calculate a label forwarding path, and delivers the
computed next hop and outgoing label (OuterLabel) to the forwarding table to
guide data packet forwarding.
Figure 5-5 Prefix label-based LSP creation

SRGB SRGB SRGB SRGB
[18000-23999] [26000-40960] [36000-40960] [16000-40960]
A B C D Loopback
X.X.X.X
1 1 1 Prefix SID=100
4 3 2
Label: 18100 Label: 26100 Label: 36100
Label: 16100
OuterLabel: 26100 OuterLabel: 36100 OuterLabel: 16100
1 Distribute Prefix SID and SRGB
2 3 4 Compute Label and OuterLabel

Table 5-2 describes the process of using prefix labels to create an LSP shown in
Figure 5-5.
Table 5-2 Process of creating an LSP

St Devi Operation
e ce
p
1 D An SRGB is configured on D and a prefix SID is configured on the

loopback interface for generation and delivery of forwarding entries.
After that, D encapsulates the SRGB and prefix SID into LSP packets
and floods the LSP packets to the entire network through an IGP.
After receiving the LSP packets, the other devices parse the packets,
obtain the prefix SID advertised by D, compute label values based on
local SRGBs and outgoing labels (OuterLabels) based on next-hop
devices. They run the IGP to compute a label forwarding path and
generate forwarding entries.
2 C C parses the prefix SID released by D and computes a label value

based on the local SRGB (36000 to 40960). The value is calculated
using the following formula:
Label = SRGB start value + Prefix SID value = 36000 + 100 = 36100
IS-IS calculates an OuterLabel based on the following formula:
OuterLabel = SRGB start value advertised by the next-hop device +
Prefix SID value = 16000 + 100 = 16100
Here, the next-hop device is D, and D releases the SRGB (16000 to
40960).
3 B The calculation process is similar to C:

Label = 26000 + 100 = 26100
OuterLabel = 36000 + 100 = 36100
4 A The calculation process is similar to C:

Label = 18000 + 100 = 18100
OuterLabel = 26000 + 100 = 26100
Data Forwarding
Similar to MPLS, SR label operations include pushing a label into a label stack,
swapping for a label stack, and popping out a label.
● Push: After a packet enters an SR LSP, the ingress node adds a label between
the Layer 2 and IP header. Alternatively, the ingress node adds a label stack
above the existing label stack.
● Swap: When packets are forwarded in an SR domain, a node searches the
label forwarding table for a label assigned by a next hop and swaps the label
on the top of the label stack with the matching label in each SR packet.

● Pop: After the packets leave an SR domain, a node finds an outbound

interface mapped to the label on the top of the label stack and removes the
top label.
Figure 5-6 Prefix label-based data forwarding

Label: 18100 Label: 26100 Label: 36100
Label: 16100
OuterLabel: 26100 OuterLabel: 36100 OuterLabel: 16100
A B C D
1 2 3 4
Push Swap Swap Pop
26100 36100 16100

Payload Payload Payload Payload Payload
Table 5-3 describes the data forwarding process on the network shown in Figure
5-6.
Table 5-3 Packet forwarding process

St Devi Operation
e ce
p
1 A Receives a data packet, adds label 26100 to the packet, and

forwards the packet.
2 B Receives the labeled packet, swaps label 26100 for label 36100, and
3 C Receives the labeled packet, swaps label 36100 for label 16100, and
4 D Removes label 16100 and forwards the packet along a matching

route.
5.2.3 SR-MPLS TE
Definition
Segment Routing-Traffic Engineering (SR-MPLS TE) is a new MPLS TE tunneling
technique implemented using SR as the control signaling. The controller calculates
a path for an SR-MPLS TE tunnel and delivers a computed label stack completely
matching the path to a forwarder. The forwarder, which is the ingress node of the
tunnel, uses the label stack to control the path along which packets are
transmitted on a network.
SR-MPLS TE Advantages
Due to complexity of the control protocol, Resource Reservation Protocol-TE
(RSVP-TE) cannot meet requirements of rapid development of software-defined

networking (SDN). SR-MPLS TE outperforms RSVP-TE in this situation. Table 5-4

describes the comparison between SR-MPLS TE and RSVP-TE.
Table 5-4 Comparison between SR-MPLS TE and RSVP-TE
Item SR-MPLS TE RSVP-TE
Control SR, which is an extension to IGP, RSVP-TE is used as the control

plane is used as the control signaling. protocol of MPLS, and the control
The control plane is simple. There plane is complex.
is no need for a dedicated MPLS
control protocol, reducing the
total number of used protocols.
Label Each link is distributed only a A label is distributed to each LSP.

distribut single label, which is shared by Such a large number of labels for
ion all LSPs. This reduces resource multiple LSPs result in several
consumption and maintenance label forwarding tables, and
workload of label forwarding maintaining these tables creates
tables. a heavy workload.
Path An intermediate device does not Configurations must be delivered

adjustm perceive SR-MPLS TE tunnel to each node.
ent and information. A service forwarding
control path can be controlled by
operating a label only on the
ingress node. Configurations do
not need to be delivered to each
node.
When a node on a path fails, the
controller re-calculates the path
and updates the label stack of
the ingress node.
Related Concepts
Label Stack
A label stack is a set of link labels in the form of a stack, used to identify a
complete label switched path (LSP). Each link label in the stack identifies a specific
link, and the label stack from top to bottom describes all links along an SR-MPLS
TE LSP. During packet forwarding, a node searches for a link mapped to each link
label at the label stack top in a packet, removes the label, and forwards the
packet. After all link labels are removed from the label stack, the packet is
transmitted through an SR-MPLS TE tunnel to the tunnel destination.
Stitching Label and Stitching Node
If the label stack depth exceeds the upper limit supported by a forwarder, the label
stack cannot carry all link labels of a whole LSP. In this situation, the controller
must divide the entire path's labels into multiple label stacks and distribute a
special label to associate adjacent label stacks, so that multiple label stacks are

associated to identify a whole LSP. The special label is a stitching label, and the
node that the stitching label resides is a stitching node.
The controller distributes a stitching label to the stitching node, pushes the
stitching label into the bottom of the upstream label stack of the LSP, and
associates the stitching label with the adjacent downstream label stack. Different
from link labels, the stitching label cannot be used to identify links. When a
packet is forwarded to the stitching node according to the upstream label stack of
the LSP, a new label stack is used to replace the stitching label according to the
association between the stitching label and the downstream label stack to guide
packet forwarding in the downstream direction of the LSP.
5.2.3.1 Label Distribution
Distributed by forwarders
A forwarder runs an IGP (only IS-IS is currently supported) to distribute labels and
report label information to the controller.
Figure 5-7 IS-IS-based label distribution
Controller
IS-IS/BGP-LS
P1 P2
9009
9009 901
0 9051
PE1 900 0 9008 5 PE2
9 0
0
9008
1 901
900 01 9021
9006
9005
9010
9011
90
IS-IS IS-IS IS-IS 2
9006
9005
9010
9011
900 3
9040 901 3
4 9007 9 1
0
900 4
3
900
9007 901 14
3 90
Interface1
9002
P3 9002 P4
Label: 9002
Link label direction
Outbound interface:
Interface1 Report label and network
Next hop: P4 topology information
IS-IS SR is enabled on PE1, PE2, and P1 through P4 to establish IS-IS neighbor

relationships between each pair of directly connected nodes. SR-capable IS-IS
instances assign SR link labels to all IS-IS outbound interfaces. The link labels are
flooded to the entire network through the extended IS-IS SR protocol. The
following uses P3 as an example to describe the process of IS-IS-based label
distribution according to the network in Figure 5-7.

1. P3 runs IS-IS to apply for a local dynamic label for a direct link. For example,
P3 distributes link label 9002 to the P3-to-P4 link.
2. P3 runs IS-IS to advertise the link label and floods it across the network.
3. P3 uses the label to generate a label forwarding table.
4. After the other nodes on the network run IS-IS to learn the link label
advertised by P3, the nodes do not generate local forwarding tables.
PE1, PE2, P1, P2, and P4 distribute and advertise link labels in the same way as P3
does, and the label forwarding tables are generated on each node. One or more
nodes establish IS-IS or BGP-LS neighbor relationships with the controller, and
report topology information, including SR labels, to the controller.
Distributed by the controller

The controller delivers distributed SR labels to forwarders through NETCONF
interfaces.
Figure 5-8 Controller-based label distribution
Controller
NE
LS TC
P- O
NF
BG
-I S/
IS P1 P2
9009
9009 901
0 9051
PE1 900 00 9008 5 PE2
90 9008 901
1
900 01 9021
9006
9005
9010
9011
9 0
IS-IS IS-IS IS-IS 2
9006
9005
9010
9011
900 3
9040 901 13
4 9007 90
900 4
3
900 9007 901 14
3 90
9002
P3 Interface19002 P4
Label: 9002
Outbound interface: Report network topology information
Interface1 Deliver labels
Next hop: P4 Link label direction
In Figure 5-8, IS-IS SR- capable forwarders establish IS-IS neighbor relationships
with each other. The controller establishes IS-IS or BGP-LS neighbor relationships
with the forwarders. IS-IS or BGP-LS reports the collected network topology
information to the controller. The controller distributes a label to each link and
uses NETCONF to deliver the labels to each forwarder which is the source node of
a link. The forwarder then generates a link label forwarding table.

5.2.3.2 SR-MPLS TE Tunnel Establishment
SR-MPLS TE Tunnel
Segment Routing Traffic Engineering (SR-MPLS TE) runs the SR protocol and uses
TE constraints to establish a tunnel.
Figure 5-9 SR-MPLS TE tunnel
P1 Primary LSP P2
PE1 PE2
SR-TE tunnel
Backup LSP
P3 P4
In Figure 5-9, a primary LSP is established along the path PE1 -> P1 -> P2 -> PE2,
and a backup path is established along the path PE1 -> P3 -> P4 -> PE2. The two
LSPs form an SR-MPLS TE tunnel. The LSP originates from the ingress node, passes
through transit nodes, and terminates at the egress node.
SR-MPLS TE tunnel establishment involves configuring and establishing an SR-

MPLS TE tunnel. Before an SR-MPLS TE tunnel is established, IS-IS neighbor
relationships must be established between forwarders, and IS-IS or BGP-LS
neighbor relationships must be established between forwarders and the controller
to implement network layer connectivity, distribute labels, and collect network
topology information. Forwarders send label and network topology information to
the controller, which uses the information to calculate paths.
SR-MPLS TE Tunnel Configuration

SR-MPLS TE tunnel attributes are used to establish tunnels. An SR-MPLS TE tunnel
can be configured on the controller or a forwarder.
● An SR-MPLS TE tunnel is configured on the controller.

The controller runs NETCONF to deliver tunnel attributes to a forwarder (as
shown in Figure 5-10). The forwarder delegates the tunnel to the controller
for management.
● An SR-MPLS TE tunnel is configured on a forwarder.
The controller obtains tunnel attributes (as shown in Figure 5-10) from a
forwarder, on which an SR-MPLS TE tunnel is configured. The forwarder
delegates the tunnel to the controller for management.
Tunnel management on the controller includes tunnel path calculation, label stack
generation, and tunnel maintenance.

SR-MPLS TE Tunnel Establishment

If a service (such as IPv4, VPN, or LDP) is imported to an SR-MPLS TE tunnel, an
SR-MPLS TE tunnel is established based on the following process, as shown in
Figure 5-10.
Figure 5-10 SR-MPLS TE tunnel establishment
Controller
1005
NETCONF
1009
1010
P1 P2
1005
1005
4 100
PE1 100 4 1080 PE2
100 8
1006
1009
ISIS ISIS ISIS
1006
1009
1003 100
1030 10
3 10 10
1006 10
1007
100 1007
P3 P4
The controller delivers or obtains

tunnel configurations.
The controller delivers a label statck.
SR-TE LSP
The process of establishing an SR-MPLS TE tunnel is as follows:

1. The controller uses SR-MPLS TE tunnel constraints and Path Computation
Element (PCE) to calculate paths and combines link labels into a label stack
(that is, the calculation result).
NOTE
Stitching labels cannot be configured using commands, but can only be delivered by
the controller through NETCONF.
If the label stack depth exceeds the upper limit supported by a forwarder, the
label stack cannot carry all link labels of a whole path, and the controller
needs to divide the entire path's labels into multiple label stacks.
As shown in Figure 5-10, the controller calculates a path PE1 -> P3 -> P1 ->
P2 -> P4 -> PE2 for the SR-MPLS TE tunnel. The path is mapped to label
stacks {1003, 1006, 100} and {1005, 1009, 1010}. Label 100 is a stitching label
associated with the label stack {1005, 1009, 1010}, and the others are link
labels.
2. The controller delivers the label stacks to the forwarders through NETCONF.
For the networking shown in Figure 5-10, the process of delivering label
stacks by the controller is as follows:

a. The controller delivers stitching label 100 and label stack {1005, 1009,
1010} to the stitching node P1.
b. The controller delivers label stack {1003, 1006, 100} to the ingress node
PE1.
3. The forwarders use the received label stacks to establish an LSP for the SR-
MPLS TE tunnel.
5.2.3.3 SR-MPLS TE Data Forwarding

A forwarder operates a label in a packet based on the label stack mapped to the
SR-MPLS TE LSP, searches for an outbound interface hop by hop based on the top
label of the label stack, and uses the label to guide the packet to the tunnel
destination address.
SR-MPLS TE Data Forwarding (Adjacency Label)

In Figure 5-11, an example is provided to describe the process of forwarding SR-
MPLS TE data with manually specified adjacency labels.
Figure 5-11 SR-MPLS TE data packet forwarding (adjacency label)
Controller
1005
1009 1009
NETCONF
1010 1010
Payload Payload
C D
1005
1005
4 100
A 100 04 1080 F
1 0 8
1006
1009
1006
1009
100
1003 1030 10 Payload
3 10 10
1006 10
1007
B 1007 E
100
Payload 1006 1010
100 Payload
Payload
Deliver label stacks to the

ingress node and stitching node
SR-TE LSP
In Figure 5-11, the SR-MPLS TE path calculated by the controller is A -> B -> C ->
D -> F -> E. The path is mapped to label stacks {1003, 1006, 100} and {1005,
1009, 1010}. The two label stacks are delivered to ingress node A and stitching
node C, respectively. Label 100 is a stitching label and is associated with label
stack {1005, 1009, 1010}. The other labels are adjacency labels. The process of
forwarding data packets along an SR-MPLS TE tunnel is shown as follows:

1. Ingress node A receives a data packet, adds the label stack {1003, 1006, 100}
to the data packet, matches the adjacent node B according to label 1003 on
the top of the stack, searches the outbound interface, and removes label
1003. The packet carrying label stack {1006, 100} is forwarded to downstream
node B through the A-to-B adjacency.
2. After receiving the packet, node B searches for the adjacency matching top
label 1006 in the label stack, finds that the corresponding outbound interface
is the B-to-C adjacency, and removes label 1006. The pack carrying the label
stack {100} is forwarded to downstream node C through the B-to-C adjacency.
3. After receiving the packet, stitching node C identifies stitching label 100 by
querying the stitching label entries, and swaps the label for the associated
label stack {1005, 1009, 1010}. Stitching node C searches for the adjacency
matching top label 1005 in the label stack, finds that the corresponding
outbound interface is the C-to-D adjacency, and removes label 1005. The
packet carrying label stack {1009, 1010} is forwarded to downstream node D
through the C-to-D adjacency.
4. After nodes D and E receive the packet, they forward the packet in the same
way as node B. Node E removes the last label 1010 and forwards the data
packet to node F.
5. Egress F receives the packet without a label and forwards the packet
according to a routing table.
The preceding information shows that after adjacency labels are manually
specified, devices strictly forward the data packets hop by hop along the explicit
path designated in the label stack. This forwarding method is also called strict
explicit-path SR-MPLS TE.
SR-MPLS TE Data Forwarding (Node and Adjacency Labels)

SR-MPLS TE in strict path mode does not support load balancing if equal-cost
paths exist. To overcome these drawbacks, node labels are introduced to SR-MPLS
TE paths.
The node and adjacency mixed label stack can be manually specified. With this
stack used, the inter-node node labels can be set. The controller runs NETCONF to
deliver the stack to the forwarder ingress node, and forwarders use the label stack
to forward packets through outbound interfaces to the destination IP address of
an LSP.

Figure 5-12 SR-MPLS TE data packet forwarding (node and adjacency labels)
Controller
101 (node)
NETCONF
1005 (adj)
Payload 201 (node)
101 (node)
C D Payload G
Payload 1005
1008
1004
A 301 (node) Payload 1011

1006 1009
Payload
1003 (adj)
1006 (adj) 1003 1010
1005 (adj) 1007 Payload

101 (node) B E F
1006 (adj)
Payload
1005 (adj) Deliver label stacks to the
101 (node) ingress node and load
balancing nodes
Payload
SR-TE LSP
On the network shown in Figure 5-12, a node and adjacency mixed label stack is
specified manually. On the ingress node A, the mixed label stack is {1003, 1006,
1005, 101}. Labels 1003, 1006, and 1005 are adjacency labels, and label 101 is a
node label.
1. Node A finds an A-to-B outbound interface based on label 1003 on the top of
the label stack. Node A removes label 1003 and forwards the packet to the
next-hop node B.
2. Similar to node A, node B finds the outbound interface mapped to label 1006
on the top of the label stack. Node B removes label 1006 and forwards the
packet to the next-hop node C.
3. Similar to node A, node C finds the outbound interface mapped to label 1005
on the top of the label stack. Node C removes label 1006 and forwards the
packet to the next-hop node D.
4. Node D processes label 101 on the top of the label stack. This label is to
perform load balancing. Traffic packets are balanced on links based on 5-
tuple information.
5. After receiving node label 101, nodes E and G that are at the penultimate
hops remove labels and forward packets to node F to complete the E2E traffic
forwarding.
The preceding information shows that after adjacency and node labels are
manually specified, a device can forward the data packets along the shortest path
or load-balance the data packets over paths. The paths are not fixed, and
therefore, this forwarding method is also called loose explicit-path SR-MPLS TE.
5.2.3.4 SR-MPLS TE Load Balancing

SR-MPLS TE Load Balancing

SR-MPLS TE guides data packet forwarding based on the label stack that the
ingress node encapsulates into the data packets. By default, each adjacency label
identifies a specified adjacency, which means that load balancing cannot be
performed even if equal-cost links exist. To address the preceding problem, SR-
MPLS TE introduces a parallel adjacency label to identify multiple equal-cost links.
In Figure 5-13, two links between nodes B and C and the link between nodes B
and D are equal-cost links. The same adjacency SID (for example, 1001 in Figure
5-13) can be configured for these links. Such an adjacency SID is called a parallel
adjacency label. Like common labels, the parallel adjacency label is also used in
path calculation.
When the data packets carrying the parallel adjacency label arrive at node B, node
B parses the parallel adjacency label and uses the hash algorithm to load balance
the traffic over the three links, which efficiently uses network resources and
prevents network congestion.
Figure 5-13 SR-MPLS TE parallel adjacency label

C
Link1
SID: 1001
A B E
Link2
SID: 1001
Load
Link3
balancing
SID: 1001
node
D
A parallel adjacency label is generated without affecting distribution of existing

adjacency labels between IGP neighbors. After a parallel adjacency label is
configured, the load balancing device advertises multiple adjacency labels to the
same adjacency.
If BFD for SR-MPLS TE is used and an SR-MPLS TE parallel adjacency label is

configured, BFD packets can be load balanced, whereas each BFD packet is hashed
to a single link. If the link fails, BFD detects a link Down event even if the other
links keep working. In this case, faults may be detected incorrectly.
5.2.3.5 SR-MPLS TE Reliability
5.2.3.5.1 CR-LSP Backup

CR-LSP backup provides end-to-end protection for an SR-MPLS TE tunnel. If the
ingress node detects a failure of the primary CR-LSP, it switches traffic to a backup
CR-LSP. Traffic moves back to the primary CR-LSP once it recovers.
An SR-MPLS TE tunnel supports CR-LSP backup in hot standby mode only. In this
mode, a backup CR-LSP is set up immediately after the primary CR-LSP is set up.
When the primary CR-LSP fails, traffic moves to the backup CR-LSP quickly.

Implementation
CR-LSP backup involves the following processes:
1. Path planning
Determine whether the paths of primary and hot-standby CR-LSPs partially
overlap. A hot-standby CR-LSP can be established over an explicit path.
A hot-standby CR-LSP supports the following attributes:
– Explicit path
– Hop limit
– Path overlapping
2. Backup CR-LSP setup
If a new tunnel configuration is committed or a tunnel goes Down, the
ingress node attempts to establish a hot-standby CR-LSP, until a CR-LSP is
successfully established.
3. Backup CR-LSP attribute modification
If attributes of a backup CR-LSP are modified, the ingress node uses the
make-before-break mechanism to reestablish the backup CR-LSP with the
updated attributes. After a backup CR-LSP has been successfully reestablished,
traffic on the original backup CR-LSP (if it is transmitting traffic) moves to
this new backup CR-LSP, and then the original backup CR-LSP is torn down.
4. Fault detection
SR-MPLS TE does not provide a fault detection mechanism. CR-LSP backup
uses BFD for LSP to quickly detect faults.
5. Traffic switchover
After the primary CR-LSP fails, the ingress node attempts to switch traffic
from the primary CR-LSP to a hot-standby CR-LSP.
6. Traffic switchback
Traffic switches back to a path based on priorities of the available CR-LSPs.
Traffic will first switch to the primary CR-LSP. Traffic will preferentially switch
to the primary CR-LSP, followed by the hot-standby CR-LSP.
Path Overlapping for a Hot-Standby CR-LSP

The path overlapping function can be configured for hot-standby CR-LSPs. This
function allows a hot-standby CR-LSP to use some links of a primary CR-LSP. After
the hot-standby CR-LSP is established, it can protect traffic on the primary CR-LSP.
5.2.3.5.2 BFD for SR-MPLS TE

Bidirectional Forwarding Detection (BFD) enables rapid fault detection on the SR-
MPLS TE tunnel and SR-MPLS TE LSP to monitor the actual connectivity. If a fault
occurs, the SR-MPLS TE tunnel reliability function triggers traffic switchover,
improving the reliability of the entire network.
Background
SR-MPLS TE does not provide a connectivity detection mechanism. The status of
an SR-MPLS TE tunnel and an SR-MPLS TE LSP is Up by default after the tunnel

and LSP are established. Service traffic is lost continuously upon a path failure due
to lack of a connectivity detection mechanism. Detection of faults on the SR-MPLS
TE LSP and SR-MPLS TE tunnel must be completed by an additional protocol. BFD
for SR-MPLS TE is an E2E rapid detection mechanism that can rapidly detect faults
in links of an SR-MPLS TE tunnel.
Implementation Process
In SR-MPLS TE, BFD is implemented in the following methods for different
detection scenarios:
● BFD for SR-MPLS TE Tunnel
This method detects the SR-MPLS TE tunnel connectivity to obtain the real
tunnel status. During establishment of an SR-MPLS TE tunnel, the tunnel
interfaces cannot go Up if BFD negotiation fails.
● BFD for SR-MPLS TE LSP
This method detects the LSP connectivity to obtain the real LSP status. During
establishment of an SR-MPLS TE LSP, the LSP cannot go Up if BFD negotiation
fails. When the primary LSP fails, traffic is quickly switched to the backup LSP.
BFD for SR-MPLS TE Tunnel

The device supports static BFD for SR-MPLS TE tunnel by binding a BFD session to
an SR-MPLS TE tunnel. That is, a BFD session is created between the ingress and
egress nodes of an SR-MPLS TE tunnel. A BFD packet is sent from the ingress node
to the egress node along the tunnel. Then, the egress node responds to the BFD
packet. In this manner, the ingress node can fast detect the SR-MPLS TE tunnel
connectivity. The BFD detection result is associated with the SR-MPLS TE tunnel
interface status, so the status of the SR-MPLS TE tunnel interface indicates the
real tunnel connectivity.
● If a fault occurs, BFD detects the fault on the SR-MPLS TE tunnel and sets the
status of the associated tunnel interface to Down, implementing millisecond-
level fault detection.
● If the fault is rectified, the tunnel interface goes Up only after the BFD goes
Up. The device performs BFD negotiation before determining that the BFD is
Up, taking a long period of time. The tunnel status is Down before a new
tunnel is established. The controller delivers new label stacks for BFD to go
Up, and then the associated tunnel interface goes Up. The entire process takes
a dozen of seconds. BFD for SR-MPLS TE tunnel has a long convergence time
if no other protection mechanism is configured for the SR-MPLS TE tunnel.
BFD for SR-MPLS TE LSP

BFD for SR-MPLS TE LSP can rapidly detect faults on CR-LSPs and notify the
forwarding plane of the faults to ensure a fast traffic switchover. Generally, BFD
for SR-MPLS TE LSP and hot standby CR-LSP are used together.
The device supports static BFD for SR-MPLS TE LSP and dynamic BFD for SR-MPLS
TE LSP.
● Static BFD for SR-MPLS TE LSP: A static BFD session is bound to a CR-LSP.
That is, a static BFD session is created between the ingress and egress nodes
of a CR-LSP. To detect a backup CR-LSP, you also need to bind a BFD session
to it.

● Dynamic BFD for SR-MPLS TE LSP: After the BFD for SR-MPLS TE LSP
capability is enabled on the ingress node and automatic BFD session creation
is enabled on the egress node, the device dynamically creates a BFD session
for a CR-LSP. Dynamic BFD for SR-MPLS TE LSP also automatically creates
BFD sessions for all CR-LSPs and performs detection.
After a BFD session is created between the ingress and egress nodes of an SR-
MPLS TE LSP, a BFD packet is sent by the ingress node and forwarded to the
egress node along a CR-LSP. The egress node then responds to the BFD packet.
The BFD session at the ingress node can rapidly detect the status of the link
through which the LSP passes. If a link fault is detected, BFD notifies the
forwarding plane of the fault. The forwarding plane switches service traffic to the
backup CR-LSP and reports fault information to the control plane.
Figure 5-14 BFD for SR-MPLS TE LSP before and after a link fault occurs
LSRD
Before a link fault occurs
LSRA LSRB LSRC
LSRD
After a link fault occurs
Primary CR-LSP
Backup CR-LSP
LSRA LSRB LSRC BFD session
Link fault
Other Functions
One-arm BFD for SR-MPLS TE:
When a device from another vendor is used as the egress node, BFD for SR-MPLS
TE fails to create a common BFD session between a Huawei device and the non-
Huawei device. BFD for SR-MPLS TE provides the one-arm echo mode to solve the
problem.
Using a one-arm BFD session, the ingress node exchanges the source address and
destination address in an IP packet header when encapsulating a BFD packet.
After the BFD packet is forwarded to the egress node, the egress node searches for
a route based on the destination address in the packet and sends the packet back

to the ingress node. The ingress node detects the BFD packet to implement the
one-arm BFD detection.
5.2.3.6 SR-MPLS TE Group

An SR-MPLS TE group consists of several SR-MPLS TE tunnels that forward service
packets with specified CoS values, which is used to implement differentiated
services for packets of multiple service types in the scenario where some Equal-
cost multi-path routing (ECMP) outbound interfaces are SR-MPLS TE tunnel
interfaces.
The ECMP outbound interfaces may be SR-MPLS TE tunnel interfaces, RSVP TE
tunnel interfaces, VLANIF interfaces, main interfaces, and Layer 3 sub-interfaces.
The SR-MPLS TE group function can be configured on an SR-MPLS TE tunnel to
implement priority-based load balancing of traffic based on the matching
between the class of service (CoS) value of the SR-MPLS TE tunnel and that of the
service packet.
CoS Value of a Tunnel

To carry packets with different priorities, SR-MPLS TE tunnels have nine CoSs that
are listed in ascending order of priority: default, BE, AF1, AF2, AF3, AF4, EF, CS6,
and CS7. The priorities BE, AF1, AF2, AF3, AF4, EF, CS6, and CS7 map to eight
internal priorities of the device. The priority default can map to any internal
priority. One SR-MPLS TE tunnel can have one or more CoS values.
CoS Value of a Service Packet

The CoS value of a packet represents the CoS value of the SR-MPLS TE tunnel that
the packet expects to pass through, which can be obtained in either of the
following methods:
● Packet priority mapping
For a packet entering the tunnel, the DSCP or EXP field in the packet header
is used to map the forwarding priority according to the QoS mapping profile.
The forwarding priority-based mapping is the CoS value of the packet.
● MQC re-marking
For a packet entering the tunnel, the internal priority is specified according to
5-tuple information of the packet. The specified internal priority is the CoS
value of the packet.
Tunnel Selection Principles for an SR-MPLS TE Group

Figure 5-15 shows the principles for selecting an SR-MPLS TE tunnel from an SR-
MPLS TE group.

Figure 5-15 Tunnel selection principles for an SR-MPLS TE group

Service flow enters the
device and is allocated
a CoS value
Yes
Is there any tunnel using Select the tunnel with the
the same CoS value? specified CoS value
No
Yes
Is there any tunnel using the Select the tunnel with the
CoS value default? CoS value default
No
Yes
Is there any tunnel Select the tunnel with no
containing no CoS CoS value
value?
No
Is there any ECMP Yes

outbound interface Select the interface with
containing no priority, no priority
except SR-TE tunnel?
No
Select the tunnel with the

lowest CoS value
1. If the SR-MPLS TE group has an SR-MPLS TE tunnel that matches the CoS
value of the packet, the tunnel is used for packet forwarding. Otherwise, go to
step 2.
2. If the SR-MPLS TE group has an SR-MPLS TE tunnel with the CoS value
default, the tunnel is used for packet forwarding. Otherwise, go to step 3.

3. If the SR-MPLS TE group has an SR-MPLS TE tunnel that is not configured

with the CoS value, the tunnel is used for packet forwarding. Otherwise, go to
step 4.
4. If the ECMP outbound interface has another type of interface with no priority
configured interface (for example, a VLANIF interface), the interface of this
type is preferred for packet forwarding. Otherwise, go to step 5.
5. The SR-MPLS TE tunnel with the lowest CoS value in the SR-MPLS TE group is
selected for packet forwarding.
5.3 Application Scenarios for Segment Routing

This section describes application scenarios of segment routing.
5.3.1 Iteration of Public IP Addresses to an SR Tunnel
Iteration of Public BGP Routes to an SR Tunnel

If an Internet user uses a carrier network that performs IP forwarding to access
the Internet, core carrier devices on the forwarding path need to learn a large
number of Internet routes. This imposes a heavy load on core carrier devices and
affects the performance of these devices. To solve this problem, you can enable
access devices to iterate non-labeled public BGP routes or non-labeled static
routes to an SR tunnel so that users can access the Internet through the SR tunnel.
The iteration to the SR tunnel prevents the problems induced by insufficient
performance, heavy burdens, and service transmission on the core devices on the
carrier network.
Figure 5-16 Iteration of public BGP routes to an SR tunnel

SRGB SRGB
[26000-40960] [36000-40960]
SRGB PE1 P1 P2 PE2 SRGB
[16000-40960] Segment routing [16000-40960]
Loopback X.X.X.X
Internet Prefix SID = 100
BGP
26100 36100 16100

IP header IP header IP header IP header IP header
As shown in Figure 5-16, the deployment process is as follows:

● Set up a BGP peer relationship on PEs to learn routes to each other.
● Deploy IS-IS and SR on PEs and Ps in an end-to-end manner.
● Iterate BGP service routes to the SR tunnel on PEs.

Iteration of Static Routes to an SR Tunnel

A static route needs to be iterated if its next hop is not directly reachable. If static
routes can be iterated to an SR tunnel, label forwarding can be performed.
Figure 5-17 Iteration of static routes to an SR tunnel

SRGB SRGB
[26000-40960] [36000-40960]
SRGB PE1 P1 P2 PE2 SRGB
[16000-40960] Segment routing [16000-40960]
Loopback X.X.X.X
Internet Prefix SID = 100
26100 36100 16100

As shown in Figure 5-17, the deployment process is as follows:

● Configure a static route on PE1 and specify the next hop as the loopback
interface address of PE2.
● Establish an SR tunnel between PE1 and PE2 that the loopback interface
address of PE2 is configured as the destination address.
● Encapsulate the label after an IP packet is received and forward the IP packet
through the SR tunnel.
5.3.2 Iteration of L3VPN Services to an SR Tunnel

Iteration of Basic VPN Services to an SR Tunnel
If an Internet user uses a carrier network that performs IP forwarding to access
the Internet, core carrier devices on the forwarding path need to learn a large
number of Internet routes. This imposes a heavy load on core carrier devices and
affects the performance of these devices. To solve this problem, you can configure
VPN services iterated to an SR tunnel so that users can access the Internet
through the tunnel.
Figure 5-18 Iteration of basic VPN services to an SR tunnel

SRGB SRGB SRGB SRGB
[16000-40960] [26000-40960] [36000-40960] [16000-40960]
PE1 P1 Segment P2 PE2
routing
CE1 CE2
BGP
Loopback X.X.X.X
26100 36100 Prefix SID = 100
Label Z Label Z Label Z

The network shown in Figure 5-18, the network consists of discontinuous L3VPN
subnets with a backbone network in between. PEs establish an SR tunnel to
forward L3VPN packets. PEs use BGP to learn VPN routes. The deployment is as
follows:
● Deploy IS-IS on both ends of PEs to implement reachable routes.
● Set up a BGP peer relationship between the PEs to learn VPN routes from
each other.
● Establish an IS-IS SR tunnel between PEs to allocate public network labels and
compute the label forwarding path.
● Allocate a private network label to the VPN through BGP, for example, Label
Z.
● Iterate the VPN routes to the SR tunnel.
● After PE1 receives an IP packet, encapsulate the private network label and the
public network labels, and forward the packet based on the label forwarding
path.
VPN FRR
As shown in Figure 5-19, PE1 adds the optimal route advertised by PE3 and the
secondary optimal route advertised by PE4 to a forwarding entry. The optimal
route is used for traffic forwarding, and the secondary optimal route is used as a
backup route.
Figure 5-19 VPN FRR networking

PE1 P1 P3 PE3
LSP1
LSP2
CE1 CE2
LSP3
PE2 P2 P4 PE4

Table 5-5 Typical fault-triggered switchover scenarios

Failure Point Protection Switchover
P1-to-P3 link Since BFD for SR-MPLS BE is not

supported, PE1 cannot detect that the
tunnel goes Down and VPN FRR
cannot be performed to switch traffic
to PE4, as shown in LSP3 in blue.
If IS-IS FRR is configured, FRR is
performed on P1. After the switchover
is performed, traffic passes through
PE1 -> P1 -> P2 -> P4 -> P3 -> PE3, as
shown in LSP2 in red.
If IS-IS FRR is configured, the SR-MPLS
BE tunnel on the P node is used for
hard convergence. The converged
traffic passes through PE1 -> P1 -> P2
-> P4 -> P3 -> PE3, as shown in LSP2
in red.
PE3 If PE3 is faulty, FRR switchover cannot

be performed on LSP1 and traffic
cannot be switched. PE1 detects PE3
failure through IS-IS packets. After re-
convergence, LSP1 goes Down, and
traffic is switched to LSP3 through PE1
-> CE1 -> PE2 -> P2 -> P4 -> PE4, as
shown in LSP3 in red.
5.3.3 Application of SR-MPLS TE in DCN Traffic Optimization

A node on a conventional IP network selects the shortest path as an optimal
route, regardless of other factors such as bandwidth. This routing mechanism may
cause congestion on the shortest path and waste resources on other available
paths. As shown in Figure 5-20, the traffic destined for Site2 is transmitted on the
shortest path (PE1 -> P1 -> PE2). When the packet traffic exceeds the path
bandwidth, traffic loss occurs. The SR-MPLS TE function can be configured on the
network to allocate some traffic to idle links (PE1 -> P2 -> P3 -> PE2) so that
traffic is distributed on the network more properly.

Figure 5-20 VPN over SR-MPLS TE tunnel networking

Controller
NETCONF IS-IS/BGP-LS
Tunnel
1
P1
PE1 IS-IS IS-IS IS-IS PE2
Tunnel 2
P2 P3
CE1 CE2
VPN1 VPN1
Site 1 Site 2
Similar to common TE tunnel techniques, SR-MPLS TE provides various reliability

techniques. CR-LSP backup provides E2E protection for MPLS TE tunnels. If the
ingress node detects a primary CR-LSP failure, it switches traffic to a backup CR-
LSP. Once the primary CR-LSP recovers, traffic is switched back from the backup
path. This implements backup protection for the primary CR-LSP. If both the
primary and backup CR-LSPs fail, SR-MPLS TE can also trigger a best-effort path
to ensure network reliability.
5.3.4 Application of an SR-MPLS TE Group in an ECMP

Scenario
In an L3VPN over SR-MPLS TE scenario shown in Figure 5-21, CE1 and CE2 belong
to the same L3VPN and they connect to the TE network through PE1 and PE2,
respectively. Multiple SR-MPLS TE tunnels on the TE network form equal-cost
multi-path routing (ECMP). Various types of service packets transmitted between
CE1 and CE2 share forwarding resources, regardless of the importance. Forwarding
of important services will be affected when there are a large amount of common
service flows. This problem also occurs in the IP over SR-MPLS TE scenarios.

Figure 5-21 L3VPN over SR-MPLS TE networking

P1
SR-TE Tunnel1
PE1 PE2
P2
SR-TE Tunnel2
CE1 P3 CE2
SR-TE Tunnel3
Important service
Common service
To ensure forwarding quality of important services, an SR-MPLS TE group can be

configured on the ingress node PE1. In this group, Tunnel1 and Tunnel2 are used
to transmit important services and Tunnel3 is used to transmit common services.
The mapping between the CoS of packets and CoS of tunnels ensures forwarding
quality of important services.
5.4 Licensing Requirements and Limitations for

Segment Routing
Involved Network Elements
SR-MPLS TE: When serving as a forwarder, a switch needs to work with the
controller to provide the SR-MPLS TE function. SR-MPLS TE tunnels and tunnel
attributes can be configured on the controller or forwarder. The controller
calculates paths, generates and delivers labels, and maintains SR-MPLS TE tunnels.
SR-MPLS BE: Other network elements are required to support SR-MPLS BE.
Licensing Requirements
You can use the segment routing feature only after the MPLS function is enabled.
The MPLS function is controlled by a license. By default, the MPLS function is
disabled on a newly purchased switch. To use the MPLS function, apply for and
purchase the license from the equipment supplier.
Version Requirements
Table 5-6 Products and minimum version supporting SR
Product Model Minimum

Version Required
CE12804/CE12808/CE12812/CE12816/CE12804S/CE12808S V200R002C50

Feature Limitations
When deploying SR-MPLS TE on the switch, pay attention to the following points:
Limitations on SR-MPLS TE:
● Among all VSs in port mode, SR-MPLS TE functions can only be configured in
the admin-VS.
All VSs in group mode support SR-MPLS TE.
● When the controller is used to control SR-MPLS TE tunnel establishment
between devices, do not configure link labels on the devices. Link labels may
conflict with the configurations delivered by the controller, which may
adversely affect the SR-MPLS TE service.
● If SR-MPLS TE functions have been configured on a switch, do not enable
TRILL functions for interfaces on the SR-MPLS TE forwarding path. Otherwise,
SR-MPLS TE functions do not take effect.
● When SR-MPLS TE is configured for path selection and equal-cost multi-path
routing (ECMP) is configured for load balancing, paths in the output of the
tracert lsp segment-routing te tunnel command may differ from actual
ones.
● When the CE-L16CQ-FD, CE-L48XS-FD1, CE-L36CQ-FD1, CE-L36CQ-SD, CE-
L48XS-FG, CE-L36CQ-FG and CE-L08CF-FG1 cards are configured to work in
enhanced segment routing mode, you need to set the MPLS TTL processing
mode to pipe on all SR nodes. Otherwise, the number of paths displayed after
using the tracert function will decrease.
● When a switch works in non-enhanced mode in an IPv4 over SR-MPLS TE or
IPv4 VPN over SR-MPLS TE scenario, ECMP and hot standby cannot be
configured together. To configure both ECMP and hot standby, run the set
forward capability enhanced command to set the interworking mode to
enhanced mode.
● When a switch works in non-enhanced mode in an IPv4 over SR-MPLS TE
group or IPv4 VPN over SR-MPLS TE group scenario, ECMP and hot standby
cannot be configured together. To configure both ECMP and hot standby, run
the set forward capability enhanced command to set the interworking
mode to enhanced mode.
● If SR-LSP hot standby is configured on an SR-MPLS TE tunnel and a BFD for
SR-MPLS TE tunnel session is configured, BFD for SR-MPLS TE LSP needs to be
configured and the time for detecting the BFD for SR-MPLS TE tunnel needs
to be longer than the time for detecting the BFD for SR-MPLS TE LSP.
Otherwise, the BFD session may flap.
● The SR-MPLS TE Group function does not take effect for IPv4 packets that are
decapsulated through tunnels (such as VXLAN and GRE tunnels).
● When the MQC re-marked VPNv4 traffic enters an SR-MPLS TE group, the
MQC-based traffic policy needs to be applied to the Layer 3 interface bound
to a VRF.
Limitations on SR-MPLS TE tunnel statistics collection:
● The traffic statistics collection period on an SR-MPLS TE tunnel must be larger
than 30s. Otherwise, the statistics are inaccurate.
● If traffic statistics collection is enabled on an SR-MPLS TE tunnel interface and
a VLANIF interface or a Layer 3 sub-interface on the tunnel, packets with the

SR-MPLS TE tunnel interface as the next hop are counted as statistics on the
SR-MPLS TE tunnel interface, but not statistics on the VLANIF interface or
Layer 3 sub-interface.
● In an L3VPN over SR-MPLS TE scenario, if traffic statistics collection is enabled
for both SR-MPLS TE tunnels and L3VPN, the function takes effect for SR-
MPLS TE traffic but not for incoming L3VPN traffic.
● For cards except CE-L48XS-FDA, CE-L48XS-FD, CE-L48XS-FG, CE-L48XS-FD1,
CE-L24LQ-FD, CE-L36LQ-FD, CE-L12CQ-FD, CE-L36CQ-FG, CE-L36CQ-FD1, CE-
L36CQ-SD, CE-L16CQ-FD, CE-L08CF-FG1, and CE-L36CQ-FD, when multiple
SR-MPLS TE tunnels load balance traffic using ECMP, traffic statistics
collection in the inbound direction of an SR-MPLS TE tunnel becomes invalid.
When deploying SR-MPLS BE on the switch, pay attention to the following points:
Limitations on SR-MPLS BE:

● Among all VSs in port mode, SR-MPLS BE functions can only be configured in
the admin-VS.
All VSs in group mode support SR-MPLS BE.
● When implicit-null label is enabled and LSPs whose next hop is label 3 or
non-label 3 form a multi-path, Ps preferentially select the LSP with the
smallest next-hop IP address among all non-outbound interfaces of the
tunnel to forward traffic.
● When implicit-null label is disabled in an SR-MPLS BE scenario, hash mis-
sequencing may occur when MPLS packets are load balanced using ECMP and
Eth-Trunk.
● When MPLS packets carry four or more layers of labels (for example, in an IP
over segment routing scenario), MPLS packets can be load balanced based on
only the three outermost labels using ECMP and Eth-Trunk. In V200R019C00
and later versions, after the assign forward segment-routing hash
enhanced command is run, Eth-Trunk or ECMP load balancing can be
performed for packets with a maximum of five label stack layers.
● The device does not support VPLS over SR-MPLS BE function.
● For a device at the penultimate hop, if the next hop is an LSP with implicit-
null label 3 and an LSP with a non-3 label and the LSPs form an ECMP, only
one LSP is selected to forward traffic, the ECMP load balancing function
becomes invalid, and packets are lost during a link switchover.
5.5 Default Settings for Segment Routing

This section describes default settings for SR-MPLS TE.
Table 5-7 Default settings for Segment Routing
Parameter Default Setting
MPLS TE Disabled
SR Disabled

5.6 Configuring SR-MPLS TE

Context
SR-MPLS TE is implemented after an SR-MPLS TE tunnel is created and traffic is
imported to the SR-MPLS TE tunnel. To deploy some reliability solutions, perform
one or more of the following operations: adjusting the establishment of SR-MPLS
TE LSP backup, configuring BFD for SR-MPLS TE tunnels, and configuring BFD for
SR-MPLS TE LSPs.
5.6.1 Configuring an SR-MPLS TE Tunnel

An SR-MPLS TE tunnel is configured on a forwarder and then is delegated to the
controller for management.
Usage Scenario
In Figure 5-22, a tunnel is established between PE1 and PE2. Segment Routing
(SR) is used as the signaling protocol for the tunnel establishment. The controller
calculates the path (PE1 -> P1 -> PE2) and delivers the calculation result (label
stack) to the ingress node PE1 through NETCONF. Forwarders establish a tunnel
based on the label stack.
Figure 5-22 SR-MPLS TE tunnel networking
Controller
NETCONF
IS-IS/BGP-LS
P1
IS-IS IS-IS
PE1 PE2
Pre-configuration Tasks
Before configuring an SR-MPLS TE tunnel, complete the following tasks:
● Configure IS-IS to implement network layer connectivity for LSRs.

● Set an LSR ID for each LSR.
● Enable MPLS globally and on interfaces on all LSRs.
NOTE
The forwarder delegates the SR-MPLS TE tunnel to the controller. The controller must be
configured to calculate paths for the tunnel, generate label stacks, and maintain the tunnel.

Configuration Procedure
5.6.1.1 Enabling MPLS TE
Context
To configure an SR-MPLS TE tunnel, first enable the MPLS TE function, and then
perform other related configurations, such as configuring the SR-MPLS TE tunnel
interface and attributes.
Perform the following configurations on each node of the SR-MPLS TE tunnel.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run mpls
The MPLS view is displayed.
Step 3 Run mpls te
MPLS TE is enabled globally.
By default, MPLS TE is disabled globally.
Step 4 Run quit
Return to the system view.
Step 5 Run interface interface-type interface-number
The SR-MPLS TE interface view is displayed.
Step 6 On an Ethernet interface, run undo portswitch
The interface is switched to Layer 3 mode.
By default, an Ethernet interface works in Layer 2 mode.
The mode switching function takes effect when the interface only has attribute
configurations (for example, shutdown and description configurations).
Alternatively, if configuration information supported by both Layer 2 and Layer 3
interfaces exists (for example, mode lacp and lacp system-id configurations), no
configuration that is not supported after the working mode of the interface is
switched can exist. If unsupported configurations exist on the interface, delete the
configurations first and then run the undo portswitch command.
NOTE
If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch
batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in
the system view to switch these interfaces to Layer 3 mode in batches.
Step 7 Run mpls

MPLS is enabled on the interface.

By default, MPLS is disabled on the interface.
Step 8 Run mpls te
MPLS TE is enabled on the interface.
By default, MPLS TE is disabled on the interface.
Step 9 Run commit
The configuration is committed.
----End
5.6.1.2 Globally Enabling the Segment Routing Capability
Context
Segment Routing (SR) enables a forwarder to assign a label to each link, which
reduces resource consumption on the forwarder. To use the SR function, SR must
be enabled globally.
Perform the following configurations on each node of the SR-MPLS TE tunnel.
Procedure
Step 2 Run segment-routing
SR is enabled globally.
By default, SR is disabled globally.
Step 3 Run commit
----End
5.6.1.3 Configuring the IS-IS SR-MPLS TE Capability and Topology Report

Function
Context
Before an SR-MPLS TE tunnel is established, a device must assign labels, collect
network topology information, and report the information to the controller so that
the controller uses the information to calculate a path and a label stack for the
path. SR-MPLS TE labels can be assigned by the controller or the extended IS-IS
protocol on forwarders. Network topology information (including labels assigned
by IS-IS) is collected by IS-IS and reported to the controller through IS-IS flooding
or BGP-LS route advertisement.

Procedure
Step 1 Configure IS-IS SR-MPLS TE.
Perform the following steps on each node of an SR-MPLS TE tunnel:
1. Run system-view

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

3. Run cost-style { compatible [ relax-spf-limit ] | wide | wide-compatible }
The IS-IS wide metric function is enabled.
IS-IS TE uses the sub-type-length-value (sub-TLV) of the Extended IS

Reachability TLV (22) to carry TE attributes. The IS-IS wide metric function
must be enabled to support the Extended IS Reachability TLV. The function
provides the cost-styles of wide, compatible, and wide-compatible.
By default, IS-IS sends or receives packets carrying the cost-style of narrow.

4. Run traffic-eng [ level-1 | level-2 | level-1-2 ]
IS-IS TE is enabled.
By default, IS-IS TE is disabled.
If no IS-IS level is specified in this command, IS-IS TE is enabled in both

Level-1 and Level-2 areas.
5. Run segment-routing mpls
IS-IS SR is enabled.
By default, IS-IS SR is disabled.

6. Run quit

7. Run commit
Step 2 Configure the device to report topology information to the controller.
Perform the following steps on one or multiple nodes of an SR-MPLS TE tunnel:
NOTE
● If the controller is indirectly connected to a forwarder at Layer 3, BGP-LS must be

configured on the forwarder and controller to report topology information to the
controller.
If a controller is directly connected to a forwarder at Layer 3, assigned labels and
network topology information can be reported to the controller using IS-IS, so BGP-LS
does not need to be configured.
● A forwarder can report network-wide topology information to the controller after they
establish an IS-IS neighbor relationship or BGP-LS peer relationship. The following steps
can be configured on one or multiple nodes, depending on the network scale.

1. Configure IS-IS to advertise the network topology to BGP.

a. Run isis [ process-id ]
b. Run bgp-ls enable [ level-1 | level-2 | level-1-2 ]
IS-IS is enabled to advertise the network topology to BGP.
By default, IS-IS is disabled from advertising the network topology to
BGP.
If no IS-IS level is specified in this command, IS-IS network topology
advertisement to BGP is enabled in both Level-1 and Level-2 areas.
c. (Optional) Run bgp-ls identifier identifier-value
A BGP-LS identifier is configured for IS-IS.
By default, no BGP-LS ID is configured for IS-IS.
NOTE
To deploy BGP-LS on more than one node, you must configure the same
identifier identifier-value for these nodes to ensure that the collected topology
information is correct.
d. Run quit
2. Configure the BGP-LS route advertisement capability.
a. Run bgp { as-number-plain | as-number-dot }
BGP is enabled, and the BGP view is displayed.
b. Run peer ipv4-address as-number as-number-plain
A BGP peer is created.
c. Run link-state-family unicast
BGP-LS is enabled, and the BGP-LS address family view is displayed.
By default, BGP-LS is disabled.
d. Run peer { group-name | ipv4-address } enable
The device is enabled to exchange BGP-LS routing information with a
specified peer or peer group.
By default, the device is disabled from exchanging BGP-LS routing
information with the specified BGP peer.
3. Run commit
Step 3 (Optional) Configure an adjacency SID.
After IS-IS SR is enabled, an adjacency SID is automatically generated. To disable
the automatic generation of adjacency SIDs, run the segment-routing auto-adj-
sid disable command. The automatically generated adjacency SID may change
after a device restart. If an explicit path uses such an adjacency SID and the
associated device is restarted, this adjacency SID must be reconfigured. You can
also manually configure an adjacency SID to facilitate the use of an explicit path.
1. Run system-view

2. Run segment-routing
The SR view is displayed.
3. Run ipv4 adjacency local-ip-addr local-ip-address remote-ip-addr remote-
ip-address sid sid-value
An adjacency SID is configured for SR.
4. Run commit
----End
5.6.1.4 Configuring an SR-MPLS TE Tunnel Interface
Context
A tunnel interface must be created on the ingress node so that a tunnel can be
established and forward data packets.
A tunnel interface supports the following functions:
● Tunnel establishment: Tunnel constraints, bandwidth attributes, and advanced
attributes can be configured on the tunnel interface to establish the tunnel.
● Tunnel management: Tunnel attributes can be modified on the tunnel
interface to manage the tunnel.
NOTE
Because SR-MPLS TE tunnels forward MPLS packets, not IP packets, IP forwarding-related

commands run on the tunnel interface are invalid.
Perform the following configurations on the ingress node of an SR-MPLS TE

tunnel.
Procedure
Step 2 Run interface tunnel tunnel-number
A tunnel interface is created, and the tunnel interface view is displayed.
NOTICE
If the shutdown command is run on the tunnel interface, all LSPs established on
the tunnel interface will be deleted.
Step 3 Run either of the following commands to assign an IP address to the tunnel
interface:
● Run ip address ip-address { mask | mask-length } [ sub ]
An IP address is configured for the tunnel interface.

The secondary IP address of the tunnel interface can be configured only after
the primary IP address is configured.
● Run ip address unnumbered interface interface-type interface-number
The tunnel interface is configured to borrow the IP address of another
interface.
An MPLS TE tunnel can be established even if the tunnel interface is assigned no
IP address. The tunnel interface must obtain an IP address before forwarding
traffic. An MPLS TE tunnel is unidirectional and does not need a peer address.
Therefore, there is no need to configure a separate IP address for the tunnel
interface. Generally, a loopback interface is created on the ingress node and a 32-
bit address that is the same as the LSR ID is assigned to the loopback interface.
Then the tunnel interface borrows the IP address of the loopback interface.
Step 4 Run tunnel-protocol mpls te
MPLS TE is configured as a tunneling protocol.
Step 5 Run destination ip-address
A tunnel destination address is configured, which is usually the LSR ID of the
egress node.
Various types of tunnels require specific destination addresses. If a tunneling
protocol is changed from another protocol to MPLS TE, a configured destination
address is deleted automatically and a new destination address needs to be
configured.
Step 6 Run mpls te tunnel-id tunnel-id
A tunnel ID is configured.
Step 7 Run mpls te signal-protocol segment-routing
SR is configured as the signaling protocol of the tunnel.
By default, the signaling protocol used to set up a tunnel is RSVP-TE.
Step 8 Run mpls te pce delegate
SR-MPLS TE tunnel delegation to a PCE server is enabled.
By default, delegation to a PCE server is disabled on a tunnel interface.
Step 9 Run commit
----End
5.6.1.5 (Optional) Configuring Administrative Group and Affinity Property
Context
The affinity property, together with the link administrative group attribute, is used
to determine the links used in CR-LSP path calculation.
The switch supports two configuration methods:

● Hexadecimal number: A 32-bit hexadecimal number is set for each affinity

property and link administrative group attribute, which causes planning and
computational difficulties. This is the traditional configuration method.
● Name: Each affinity property and link administrative group can be named,
which simplifies configuration and maintenance. This configuration method is
recommended.
NOTE
● The change of the administrative group attribute takes effect only on the new CR-LSP.
Existing CR-LSPs are unaffected.
● If the affinity property of a tunnel is changed, the existing CR-LSPs for the tunnel are
affected. The switch re-calculates paths for the tunnel.
The following procedures show how to configure an affinity property on the

ingress node of the SR-MPLS TE tunnel and an administrative group attribute on
each node participating in the tunnel path calculation.
Procedure
● Configure an administrative group attribute and affinity property through a
hexadecimal number.
a. Configure a hexadecimal number for the link's administrative group
attribute.
i. Run system-view
ii. Run interface interface-type interface-number
iii. On an Ethernet interface, run undo portswitch
The mode switching function takes effect when the interface only
has attribute configurations (for example, shutdown and
description configurations). Alternatively, if configuration
information supported by both Layer 2 and Layer 3 interfaces exists
(for example, mode lacp and lacp system-id configurations), no
configuration that is not supported after the working mode of the
interface is switched can exist. If unsupported configurations exist on
the interface, delete the configurations first and then run the undo
portswitch command.
NOTE
If many Ethernet interfaces need to be switched to Layer 3 mode, run the

undo portswitch batch interface-type { interface-number1 [ to interface-
number2 ] } &<1-10> command in the system view to switch these
interfaces to Layer 3 mode in batches.
iv. Run mpls te link administrative group value
An administrative group attribute is configured for the link.
The default administrative group attribute of the link is 0x0.
v. Run quit


b. Configure an affinity property for the tunnel.
i. Run interface tunnel tunnel-number
The tunnel interface view is displayed.
ii. Run mpls te affinity property properties [ mask mask-value ]
[ secondary ]
An affinity property is configured for the tunnel.
By default, no affinity value is configured for the tunnel.
iii. Run commit
● Configure an administrative group attribute and affinity property through a
name.
a. Configure a mapping template for affinity names and bits.
i. Run system-view
ii. Run path-constraint affinity-mapping
An affinity property name template is created, and the template view
is displayed.
By default, no affinity property name template is created.
iii. Run attribute bit-name bit-sequence bit-number
Mappings between affinity bits and names are configured.
This step can be performed to configure an affinity bit. Repeat this
step to configure more affinity bits. You can configure up to 32
affinity bits.
By default, no mapping between affinity bits and names is
configured.
iv. Run quit
NOTE
Configure an affinity property name template on each node that calculates the
path over which a tunnel is established. The mapping relationship on all the
nodes must be the same. In this way, affinity property names have the same
meaning during path calculation for the tunnel.
b. Configure an administrative group name for a link.
i. Run interface interface-type interface-number
ii. On an Ethernet interface, run undo portswitch
The mode switching function takes effect when the interface only
has attribute configurations (for example, shutdown and
description configurations). Alternatively, if configuration
information supported by both Layer 2 and Layer 3 interfaces exists

(for example, mode lacp and lacp system-id configurations), no

configuration that is not supported after the working mode of the
interface is switched can exist. If unsupported configurations exist on
the interface, delete the configurations first and then run the undo
portswitch command.
NOTE
If many Ethernet interfaces need to be switched to Layer 3 mode, run the

undo portswitch batch interface-type { interface-number1 [ to interface-
number2 ] } &<1-10> command in the system view to switch these
interfaces to Layer 3 mode in batches.
iii. Run mpls te link administrative group name bit-name &<1-32>
An administrative group name is configured for a link.
In this command, bit-name must be within the range defined in the
affinity property name template.
By default, the administrative group attribute value of a link is 0x0,
and no administrative group name is configured for the link.
iv. Run quit
c. Configure an affinity property name for the tunnel.
i. Run interface tunnel tunnel-number
ii. Run mpls te affinity { primary | secondary } { include-all | include-
any | exclude } bit-name &<1-32>
An affinity property name is configured for the tunnel.
In this command, bit-name must be within the range defined in the
affinity property name template.
By default, no affinity property name is configured for the tunnel.
iii. Run commit
----End
5.6.1.6 (Optional) Configuring an SRLG
Context
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 enabled. Two or more links are at the same risk level if they share
physical resources. For example, sub-interfaces share risks with their main
interface. These sub-interfaces will go Down if the main interface goes Down. If
the links of a primary tunnel and a backup tunnel are in the same SRLG, the links
of the backup tunnel share risks with the links of the primary tunnel. The backup
tunnel will go Down if the primary tunnel goes Down. After an SRLG is configured,
CSPF must calculate a hot-standby CR-LSP according to the SRLG attribute. The

link used by the primary path and the link used by the hot-standby CR-LSP cannot
be in the same SRLG.
NOTE
The configuration of SRLG takes effect only on the new CR-LSP. Existing CR-LSPs are
unaffected.
Perform the following steps according to actual networking.
Procedure
● Configuring an SRLG path calculation mode globally
Perform the following steps on the ingress node of the hot-standby tunnel.
a. Run system-view
b. Run mpls
c. Run mpls te srlg path-calculation [ preferred | strict ]
An SRLG path calculation mode is configured.
NOTE
● If strict is specified, CSPF uses the SRLG attribute as a constraint when

calculating paths for the hot-standby CR-LSP.
● If preferred is specified, CSPF uses the SRLG attribute as a constraint to
calculate paths for the hot-standby CR-LSP for the first time. If the calculation
fails, CSPF tries to calculate paths again without using the SRLG attribute as a
constraint.
By default, when calculating paths, CSPF does not consider an SRLG

constraint or check whether the primary CR-LSP and hot-standby CR-LSP
are in the same SRLG.
d. Run quit
● Configuring an SRLG attribute for the link
Perform the following steps on the links which are in the same SRLG.
a. Run interface interface-type interface-number
The SR-MPLS TE tunnel view is displayed.
b. On an Ethernet interface, run undo portswitch
The mode switching function takes effect when the interface only has
attribute configurations (for example, shutdown and description
configurations). Alternatively, if configuration information supported by
both Layer 2 and Layer 3 interfaces exists (for example, mode lacp and
lacp system-id configurations), no configuration that is not supported

after the working mode of the interface is switched can exist. If

unsupported configurations exist on the interface, delete the
configurations first and then run the undo portswitch command.
NOTE
If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo
portswitch batch interface-type { interface-number1 [ to interface-number2 ] }
&<1-10> command in the system view to switch these interfaces to Layer 3 mode
in batches.
c. Run mpls te srlg srlg-number
The link on which the interface resides joins the SRLG.
On a network with hot standby enabled, the SRLG attribute needs to be
configured for the outbound interface of the ingress on a tunnel and
other members in the SRLG. A link joins an SRLG after the SRLG attribute
is configured on any outbound interface of the link.
By default, an interface is not added to any SRLG.
NOTE
To delete the SRLG attribute from all interfaces on a switch, run the undo mpls
te srlg all-config command in the MPLS view.
d. Run commit
----End
5.6.1.7 (Optional) Configuring an Explicit Path for the Tunnel
Context
Constraints such as explicit path attributes can be configured on the ingress node
to accurately and flexibly establish tunnels.
Perform the following steps on the ingress node of an SR-MPLS TE tunnel.
1. Configuring an Explicit Path
You need to configure an explicit path before you can configure explicit path
constraints.
An explicit path refers to a vector path on which a series of nodes are
arranged in the sequence in which they are configured. The IP address of an
interface on the egress is usually used as the destination address of the
explicit path. Links or nodes can be specified for an explicit path so that a CR-
LSP can be established over the specified path, facilitating resource allocation
and efficiently controlling CR-LSP establishment.
Two adjacent nodes on an explicit path are connected in either of the
following modes:
– Strict: Adjacent hops must be directly connected. This mode strictly
controls the path through which the LSP passes.
– Loose: Other nodes may exist between adjacent hops.
The strict and loose modes are used either separately or in combination.

2. Applying the Explicit Path to a Tunnel

After an explicit path is configured as one of the constraints for tunnel
establishment, path computation is based on the constraints to calculate a
path over which a CR-LSP is established.
Procedure
Step 1 Configure an explicit path.
1. Run system-view
2. Run explicit-path path-name
An explicit path is created and the explicit path view is displayed.
3. Perform one of the following steps as required.
– To specify a next-hop label for the explicit path, run the next sid label
label-value type { adjacency | prefix } command.
– To specify a next-hop address for the explicit path:
i. Run next hop ip-address [ include [ [ loose | strict ] | [ incoming |
outgoing ] ] * | exclude ]
A next-hop address is specified for the explicit path.
By default, the include strict parameter is configured, meaning that
adjacent hops must be directly connected. An explicit path can be
configured to pass through a specified node or not to pass through a
specified node.
Either of the following parameters can be configured:
○ incoming: sets the ip-address to the IP address of an inbound
interface of a next-hop node.
○ outgoing: sets the ip-address to the IP address of an outbound
interface of a next-hop node.
ii. You can run the following commands to add, modify, or delete nodes
on the explicit path.
○ Run list hop [ ip-address ]
Information about nodes on the explicit path is displayed.
○ Run add hop ip-address1 [ include [ [ loose | strict ] |
[ incoming | outgoing ] ] * | exclude ] { after | before } ip-
address2
A node is added to the explicit path.
By default, the include strict parameter is configured, meaning
that adjacent hops must be directly connected. An explicit path
can be configured to pass through a specified node or not to
pass through a specified node.
○ incoming: sets the ip-address1 to the IP address of an
inbound interface of a newly added node.
○ outgoing: sets the ip-address1 to the IP address of an
outbound interface of a newly added node.

○ Run modify hop ip-address1 ip-address2 [ include [ [ loose |

strict ] | [ incoming | outgoing ] ] * | exclude ]
The address of a node is changed to allow another specified
node to be used by the explicit path.
By default, the include strict parameter is configured, meaning
that adjacent hops must be directly connected. An explicit path
can be configured to pass through a specified node or not to
pass through a specified node.
○ incoming: sets the ip-address2 to the IP address of an
inbound interface of the modified node.
○ outgoing: sets the ip-address2 to the IP address of an
outbound interface of the modified node.
○ Run delete hop ip-address
A node is deleted from the explicit path.
4. Run commit
Step 2 Apply the explicit path to a tunnel.
1. Run system-view
2. Run interface tunnel tunnel-number
3. Run mpls te path explicit-path path-name
The explicit path is applied to the tunnel.
4. Run commit
----End
5.6.1.8 (Optional) Configuring CR-LSP Hop Limit
Context
The hop limit is a condition for CR-LSP path selection and is used to specify the
maximum number of hops along a CR-LSP.
Procedure
Step 2 Run interface tunnel interface-number

Step 3 Run mpls te hop-limit hop-limit-value

The maximum number of hops along the CR-LSP is set. The hop-limit-value is an
integer in the range from 1 to 32.
Step 4 Run commit
----End
5.6.1.9 (Optional) Configuring the Tunnel Bandwidth
Context
The bandwidth of a tunnel must be planned according to requirements of the
services to be transmitted over the tunnel. Bandwidth attributes can be configured
on the ingress to accurately and flexibly establish tunnels.
Procedure
Step 3 Run mpls te bandwidth ct0 ct0-bw-value
A bandwidth constraint is configured for the tunnel.
By default, no bandwidth constraint is configured for a tunnel.
Step 4 Run commit
----End
5.6.1.10 (Optional) Configuring the Tunnel Priority
Context
In the process of establishing a CR-LSP, if no path with the required bandwidth
exists, bandwidth preemption is implemented according to setup priority and
holding priority.
Procedure

Step 3 Run mpls te priority setup-priority [ hold-priority ]
The setup and holding priorities are set for the tunnel.
Both the setup priority and the holding priority are in the range from 0 to 7. The
smaller the value, the higher the priority.
By default, both the setup priority and the holding priority are 7. If only the setup
priority value is set, the holding priority value is the same as the setup priority
value.
NOTE
The setup priority should not be higher than the holding priority.
Step 4 Run commit
----End
5.6.1.11 Verifying the SR-MPLS TE Tunnel Configuration
Prerequisites
The SR-MPLS TE tunnel configuration has been completed.
Procedure
● Run the following commands to check the IS-IS TE status:
– display isis traffic-eng advertisements [ local | lsp-id ] [ level-1 |
level-2 | level-1-2 ] [ process-id | vpn-instance vpn-instance-name ]
– display isis traffic-eng statistics [ process-id | vpn-instance vpn-
instance-name ]
● Run the display bgp link-state unicast peer command check information
about BGP-LS peers and their status.
● Run the display explicit-path [ [ name ] path-name ] [ verbose ] command
to check configured explicit paths.
● Run the display mpls te tunnel [ destination ip-address ] [ lsp-id ingress-lsr-
id session-id local-lsp-id ] [ lsr-role { all | egress | ingress | remote |
transit } ] [ name tunnel-name ] [ { incoming-interface | interface |
outgoing-interface } interface-type interface-number ] [ verbose ] command
to check tunnel information.
● Run the display mpls te tunnel statistics or display mpls sr-te-lsp
command to check tunnel or LSP statistics.
● Run the display mpls te tunnel-interface [ tunnel interface-number ]
command to check information about a tunnel interface on the ingress.
● Run the display mpls te tunnel diagnostic command to check brief tunnel
information.

● Run the display mpls te stitch-label-stack command to check information

about the stitching label stack mapped to the stitching label.
When the label stack depth exceeds the upper limit supported by a forwarder,
the controller needs to divide a label stack into multiple stacks for an entire
path. The divided stacks are separately assigned to the ingress node and
stitching nodes. You can view information about a stitching label stack on a
stitching node.
----End
5.6.2 Importing Traffic to an SR-MPLS TE Tunnel

An SR-MPLS TE tunnel does not automatically import traffic. To enable traffic to
travel along an SR-MPLS TE tunnel, you need to use some methods to import
traffic to the SR-MPLS TE tunnel.
Before importing traffic to the SR-MPLS TE tunnel, complete the following tasks:
Configure an SR-MPLS TE tunnel. For details, see 5.6.1 Configuring an SR-MPLS

TE Tunnel.
To import traffic to the SR-MPLS TE tunnel, perform one of the following
operations according to the network planning. You are advised to use the auto
route mechanism.
5.6.2.1 Configuring Static Routes
Context
Using static routes is the simplest method for importing traffic to an SR-MPLS TE
tunnel.
Procedure
Static routes in an SR-MPLS TE tunnel are similar to common static routes. You
only need to configure a static route with an SR-MPLS TE tunnel interface as the
outbound interface. For detailed instructions, see Configuring IPv4 Static Routes in
the CloudEngine 12800 and 12800E Series Switches Configuration Guide - IP
Unicast Routing.
5.6.2.2 Configuring MQC Redirection
Context
To transmit specific traffic over an SR-MPLS TE tunnel, traffic is filtered out based
on MQC traffic policies and redirected to the SR-MPLS TE tunnel interface.

Procedure
Apply MQC traffic policies in the inbound direction to redirect packets matching
traffic classification rules to the SR-MPLS TE tunnel. For details, see Configuring
Redirection in the CloudEngine 12800 and 12800E Series Switches Configuration
Guide - QoS.
5.6.2.3 Configuring a Tunnel Policy
Context
A tunnel policy can be configured to import VPN traffic and unlabeled routes of
the public network to an SR-MPLS TE tunnel.
Procedure
● Configure a tunnel policy to import VPN traffic to an SR-MPLS TE tunnel.
Typically, VPN traffic is forwarded through an LSP tunnel but not an SR-MPLS
TE tunnel. To import VPN traffic to the SR-MPLS TE tunnel, you need to
configure a tunnel policy.
a. Create a tunnel policy.
You can configure either of the following types of tunnel policies
according to service requirements:
▪ Tunnel type prioritizing policy: This specifies the sequence in which

different types of tunnels are selected by the VPN. For example, you
can specify the VPN to select the SR-MPLS TE tunnel first.
▪ Tunnel binding policy: This binds an SR-MPLS TE tunnel to a specified

VPN by binding a specified destination address to the SR-MPLS TE
tunnel to provide QoS guarantee.
b. Apply the tunnel policy.
For detailed instructions, see Configuring and Applying a Tunnel Policy in
"BGP MPLS IP VPN Configuration" of the CloudEngine 12800 and 12800E
Series Switches Configuration Guide - VPN.
● Configure a tunnel policy to iterate unlabeled routes of the public
network to an SR-MPLS TE tunnel.
By default, unlabeled routes of the public network can only be iterated to the
outbound interface and the next hop, but not a tunnel.
a. Run system-view
b. Run tunnel-policy policy-name
A tunnel policy is created, and tunnel policy view is displayed.
c. (Optional) Run description description-information
The description of the tunnel policy is configured.
d. Run tunnel select-seq cr-lsp load-balance-number load-balance-
number
The sequence in which each type of tunnel is selected and the number of
tunnels participating in load balancing are set.

e. Run quit
f. Run route recursive-lookup tunnel [ ip-prefix ip-prefix-name ]
[ tunnel-policy policy-name ]
The unlabeled route of the public network is allowed to be iterated to the
LSP to forward through MPLS.
By default, the unlabeled route of the public network can be iterated only
to the outbound interface and the next hop but not the LSP tunnel.
If ip-prefix ip-prefix-name is not set, all static routes and unlabeled BGP
routes will be preferentially iterated to LSP tunnels.
g. Run commit
After unlabeled routes of the public network are iterated to an SR-MPLS TE
tunnel, you can run the display bgp routing-table network command to
view route iteration information.
5.6.2.4 Configuring Auto Routes
Context
After you configure auto routes, SR-MPLS TE tunnels act as logical links to
participate in IGP route calculation and tunnel interfaces are used as the
outbound interfaces of packets. Devices on a network determine whether to
advertise LSP information to neighboring nodes to instruct packet forwarding. You
can configure automatic routes following Configuring IGP shortcut. The SR-MPLS
TE tunnel is not advertised to neighbor nodes in this mode. Therefore, the SR-
MPLS TE tunnel participates only in local route calculation and other nodes cannot
use this tunnel.
Procedure
● Configuring IGP shortcut
a. Run system-view

b. Run interface tunnel interface-number

c. Run mpls te igp shortcut [ isis | ospf ]
IGP shortcut is configured.
By default, IGP shortcut is not configured. If the IGP type is not specified
for IGP shortcut, both IS-IS and OSPF are supported.
d. Run mpls te igp metric { absolute | relative } value
The IGP metric value is configured for the SR-MPLS TE tunnel.
By default, the metric value used by the SR-MPLS TE tunnel is the same
as that of the IGP path.

You can specify a metric value used by the SR-MPLS TE tunnel when a
path is calculated using the IGP shortcut mode.
▪ If the absolute metric is used, the metric value of the SR-MPLS TE

tunnel is equal to the configured metric value.
▪ If the relative metric is used, the metric value of the SR-MPLS TE

tunnel is equal to the sum of the metric value of the corresponding
IGP path and relative metric value.
e. You can select either of the following modes to configure IGP shortcut.
▪ For IS-IS, run isis enable [ process-id ]

An IS-IS process is enabled on the tunnel interface.
▪ For OSPF, run the following commands in sequence:

1) Run quit
2) Run ospf [ process-id ]
The OSPF view is displayed.
3) Run enable traffic-adjustment
The IGP shortcut function is enabled.
f. Run commit
----End
5.6.2.5 Verifying the Configuration for Importing Traffic to an SR-MPLS TE

Tunnel
Prerequisites
The configuration for importing traffic to an SR-MPLS TE tunnel is complete.
Procedure
● Run the display current-configuration command to check the configuration
for importing traffic to an SR-MPLS TE tunnel.
● Run the display ip routing-table command to check the routes with an SR-
MPLS TE tunnel interface as the outbound interface.
----End
5.6.3 Configuring SR-MPLS TE LSP Backup

SR-MPLS TE LSP backup provides an end-to-end protection mechanism. If a
primary CR-LSP fails, traffic rapidly moves to a backup CR-LSP, ensuring
uninterrupted traffic transmission.
Before configuring SR-MPLS TE LSP backup, complete the following tasks:

● Configure an SR-MPLS TE tunnel. For details, see 5.6.1 Configuring an SR-

MPLS TE Tunnel.
● Enable MPLS and MPLS TE globally and on interfaces of each node along a
backup CR-LSP.
● Enable SR globally on each node along a backup CR-LSP.
● Configure the IS-IS SR-MPLS TE capability on each node along a backup CR-
LSP.
NOTE
If CR-LSP hot standby is configured, perform the operations in 5.6.5 Configuring Static BFD for
SR-MPLS TE LSPs or 5.6.6 Configuring Dynamic BFD for SR-MPLS TE LSPs to implement fast
switching (in milliseconds).
Carry out the following procedures. Of which, configuring forcible switchover is
optional.
5.6.3.1 Creating a Backup CR-LSP
Context
CR-LSP backup can be configured to allow traffic to switch from a primary CR-LSP
to a backup CR-LSP, providing end-to-end protection.
Procedure
Step 3 Run mpls te backup hot-standby
The mode of establishing a backup CR-LSP is configured.
To implement fast switching (in milliseconds), perform the operation of 4.16
Configuring Static BFD for CR-LSPs.
After hot standby is configured, the system automatically selects a path for a
backup CR-LSP. If you want to specify a path for a backup CR-LSP, perform one or
more of steps 4 to 5. When hot standby is configured, perform one or more of
steps 6 to 8.
Step 4 (Optional) Run mpls te path explicit-path path-name secondary
An explicit path is specified for the backup CR-LSP.
Use a separate explicit path for the backup CR-LSP to prevent the backup CR-LSP
from completely overlapping its primary CR-LSP. Protection will fail if the backup
CR-LSP completely overlaps its primary CR-LSP.

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

b. Run interface tunnel tunnel-number

c. Run hotstandby-switch force
Traffic is switched to a backup CR-LSP forcibly.
NOTICE
To prevent traffic loss, check that a backup CR-LSP has been established
before running the hotstandby-switch force command.
● After adjusting the primary CR-LSP, perform the following steps:

a. Run system-view

b. Run interface tunnel tunnel-number

c. Run hotstandby-switch clear
Traffic is switched back to the primary CR-LSP.
----End
5.6.3.3 Verifying the CR-LSP Backup Configuration
Prerequisites
The configuration of CR-LSP backup is complete.
Procedure
● Run the display mpls te tunnel-interface [ tunnel tunnel-number ]
command to check information about the tunnel interface.
● Run the display mpls te hot-standby state { all [ verbose ] | interface
tunnel interface-number } command to check information about the hot-
standby status.
outgoing-interface } interface-type interface-number ] command to check
tunnel information.
----End
5.6.4 Configuring Static BFD for SR-MPLS TE Tunnels

BFD can be used to monitor SR-MPLS TE tunnels. If the primary tunnel fails, BFD
instructs applications such as VPN FRR to quickly switch traffic to a backup tunnel,
minimizing the impact on services.

Before configuring static BFD for SR-MPLS TE tunnels, complete the following
task:
TE Tunnel.
5.6.4.1 Enabling BFD Globally
Context
You can set BFD parameters only after enabling BFD globally.
Perform the following steps on the ingress and egress nodes of an SR-MPLS TE
tunnel.
Procedure
Step 2 Run bfd
BFD is enabled globally.
By default, BFD is disabled globally.
Step 3 Run commit
----End
5.6.4.2 Configuring BFD Parameters on the Ingress Node of the Tunnel
Context
The BFD parameters configured on the ingress node determine whether a BFD
session is established. These parameters include the local and remote
discriminators, local intervals at which BFD packets are sent and received, and BFD
detection multiplier.
Procedure
Step 2 Run bfd session-name bind mpls-te interface tunnel interface-number [ one-
arm-echo ]

A BFD session is configured to monitor an SR-MPLS TE tunnel.

By default, no BFD is configured to monitor an SR-MPLS TE tunnel.
If one-arm-echo is specified, a one-arm BFD echo session is established to
monitor an SR-MPLS TE tunnel. This is required if a Huawei device is deployed at
the ingress and a non-Huawei device is deployed at the egress, because they
cannot communicate using BFD for SR-MPLS TE tunnels and therefore a BFD
session cannot be established.
Step 3 Run discriminator local discr-value
The local discriminator is set.
By default, the local discriminator is not set.
Step 4 Run discriminator remote discr-value
The remote discriminator is set.
By default, the remote discriminator is not set.
You do not need to configure a remote discriminator for a one-arm BFD echo
session.
Step 5 (Optional) Run min-tx-interval interval
The local interval at which BFD packets are sent is set.
By default, the value is 1000 milliseconds.
One-arm BFD echo sessions do not support this parameter.
Step 6 (Optional) Run min-rx-interval interval
The local interval at which BFD packets are received is set.
For a one-arm BFD echo session, run the min-echo-rx-interval command to set
the local interval at which BFD packets are received.
Step 7 (Optional) Run detect-multiplier multiplier
The local detection multiplier is adjusted.
By default, the local detection multiplier is 3.
Actual local sending interval = MAX { Configured local sending interval,
Configured remote receiving interval }
Actual local receiving interval = MAX { Configured remote sending interval,
Configured local receiving interval }
Actual local detection interval = Actual local receiving interval x Configured
remote detection multiplier
For example:
● The local sending and receiving intervals are set to 200 ms and 300 ms
respectively and the detection multiplier is set to 4.
● The remote sending and receiving intervals are set to 100 ms and 600 ms

Then,
● Actual local sending interval = MAX {200 ms, 600 ms} = 600 ms; Actual local
receiving interval = MAX {100 ms, 300 ms} = 300 ms; Actual local detection
interval is 300 ms x 5 = 1500 ms.
● Actual remote sending interval = MAX {100 ms, 300 ms} = 300 ms; Actual
remote receiving interval = MAX {200 ms, 600 ms} = 600 ms; Actual remote
detection interval is 600 ms x 4 = 2400 ms.
Step 8 Run commit
----End
5.6.4.3 Configuring BFD Parameters on the Egress Node of the Tunnel
Context
The BFD parameters configured on the egress node determine whether a BFD
Perform the following steps on the egress node of an SR-MPLS TE tunnel.
NOTE
If a one-arm BFD echo session is established on the ingress node, this configuration is not
required.
Procedure
Step 2 Configure a reverse tunnel to inform the ingress node of a fault if one occurs. The
reverse tunnel can be an IP link or SR-MPLS TE tunnel. To ensure that the forward
and reverse paths are over the same link, an SR-MPLS TE tunnel is preferentially
selected to notify the ingress node of an LSP fault. Run the following commands
as required.
● For an IP link, run bfd session-name bind peer-ip ip-address [ vpn-instance
vpn-name ] [ source-ip ip-address ]
● For an SR-MPLS TE tunnel, run bfd session-name bind mpls-te interface
tunnel interface-number
By default, BFD detection is disabled on the reverse tunnel.




For example:
Then,
Step 8 Run commit
----End
5.6.4.4 Verifying the Configuration of Static BFD for SR-MPLS TE
Prerequisites
Static BFD for SR-MPLS TE tunnels has been configured.

Procedure
● Run the display bfd session mpls-te interface tunnel tunnel-name
[ verbose ] command to check BFD session information on the tunnel ingress.
● Check BFD session information on the tunnel egress.
– To check information about all BFD sessions, run the display bfd session
all [ for-lsp | for-te ] [ verbose ] command.
– To check information about static BFD sessions, run the display bfd
session static [ for-lsp | for-te ] [ verbose ] command.
● Check BFD statistics.
– To check statistics about all BFD sessions, run the display bfd statistics
session all [ for-lsp | for-te ] command.
– To check statistics about static BFD sessions, run the display bfd
statistics session static [ for-lsp | for-te ] command.
– To check statistics about BFD for MPLS-TE sessions, run the display bfd
statistics session mpls-te interface tunnel tunnel-number [ te-lsp ]
command.
----End
5.6.5 Configuring Static BFD for SR-MPLS TE LSPs

BFD detects the connectivity of SR-MPLS TE LSPs. If a BFD session fails to go Up
through negotiation, an SR-MPLS TE LSP cannot go Up. Static BFD for SR-MPLS TE
LSPs is configured to rapidly switch traffic from the primary LSP to a backup LSP if
the primary LSP fails.
Before configuring static BFD for SR-MPLS TE LSPs, complete the following task:
TE Tunnel.
Context
tunnel.
Procedure
Step 2 Run bfd


Step 3 Run commit
----End
5.6.5.2 Configuring BFD Parameters on the Ingress Node of the Tunnel
Context
The BFD parameters configured on the ingress node determine whether a BFD
Procedure
Step 2 Run bfd session-name bind mpls-te interface tunnel interface-number te-lsp
[ backup ] [ one-arm-echo ]
A BFD session is configured to monitor an SR-MPLS TE LSP.
By default, no BFD is configured to monitor an SR-MPLS TE LSP.
If one-arm-echo is specified, a one-arm BFD echo session is established to
monitor an SR-MPLS TE LSP. This is required if a Huawei device is deployed at the
ingress and a non-Huawei device is deployed at the egress, because they cannot
communicate using BFD for SR-MPLS TE LSPs and therefore a BFD session cannot
be established.
You do not need to configure a remote discriminator for a one-arm BFD echo
session.

One-arm BFD echo sessions do not support this parameter.

For a one-arm BFD echo session, run the min-echo-rx-interval command to set
the local interval at which BFD packets are received.
For example:
Then,
Step 8 Run commit
----End
5.6.5.3 Configuring BFD Parameters on the Egress Node of the Tunnel
Context
The BFD parameters configured on the egress node determine whether a BFD
Perform the following steps on the egress node of an SR-MPLS TE tunnel.

NOTE
required.
Procedure
Step 2 Configure a reverse tunnel to inform the ingress node of a fault if one occurs. The
reverse tunnel can be an IP link or SR-MPLS TE LSP. To ensure that the forward
and reverse paths are over the same link, an SR-MPLS TE LSP is preferentially
selected to notify the ingress node of an LSP fault. Run the following commands
as required.
● For an IP link, run bfd session-name bind peer-ip ip-address [ vpn-instance
vpn-name ] [ interface interface-type interface-number ] [ source-ip ip-
address ]
● For an SR-MPLS TE LSP, run bfd session-name bind mpls-te interface tunnel
interface-number te-lsp [ backup ]
By default, BFD detection is disabled on the reverse tunnel.




For example:
Then,
Step 8 Run commit
----End
5.6.5.4 Verifying the Configuration of Static BFD for SR-MPLS TE LSPs
Prerequisites
Static BFD for SR-MPLS TE LSPs has been configured.
Procedure
● Run the display bfd session mpls-te interface tunnel-name te-lsp
[ verbose ] command to check information about BFD sessions on the
ingress.
● Check BFD session information on the tunnel egress.
– To check information about all BFD sessions, run the display bfd session
all [ for-ip | for-lsp | for-te ] [ verbose ] command.
– To check information about static BFD sessions, run the display bfd
session static [ for-ip | for-lsp | for-te ] [ verbose ] command.
– To check statistics about all BFD sessions, run the display bfd statistics
session all [ for-ip | for-lsp | for-te ] command.
– To check statistics about static BFD sessions, run the display bfd
statistics session static [ discriminator local-discriminator | for-ip | for-
lsp | for-te ] command.
– To check statistics about BFD sessions that monitor LSPs, run the display
bfd statistics session mpls-te interface tunnel tunnel-number te-lsp
command.
----End

5.6.6 Configuring Dynamic BFD for SR-MPLS TE LSPs

Dynamic BFD for SR-MPLS TE LSPs rapidly detects faults of SR-MPLS TE LSPs,
which protects traffic transmitted on SR-MPLS TE LSPs.
BFD detects the connectivity of SR-MPLS TE LSPs. If a BFD session fails to go Up

through negotiation, an SR-MPLS TE LSP cannot go Up. Dynamic BFD for SR-MPLS
TE LSPs is configured to rapidly switch traffic from the primary LSP to a backup
LSP if the primary LSP fails. Unlike static BFD for SR-MPLS TE LSPs, dynamic BFD
for SR-MPLS TE LSPs simplifies the configuration and minimizes manual
configuration errors.
Currently, dynamic BFD can only monitor LSPs of an SR-MPLS TE tunnel but not
the entire SR-MPLS TE tunnel.
Before configuring dynamic BFD for SR-MPLS TE LSPs, complete the following
tasks:

TE Tunnel.
Context
tunnel.
Procedure
Step 2 Run bfd
Step 3 Run commit
----End

5.6.6.2 Enabling the Ingress to Dynamically Create BFD Sessions to Monitor

SR-MPLS TE LSPs
Context
Perform either of the following operations to enable the ingress to dynamically
create BFD sessions to monitor SR-MPLS TE LSPs:
● Globally enable the capability if BFD sessions need to be automatically

created for most SR-MPLS TE tunnels on the ingress.
● Enable the capability on a specific tunnel interface if BFD sessions need to
be automatically created for a specific or some SR-MPLS TE tunnels on the
ingress.
Procedure
● Globally enabling the capability
Perform the following steps on the ingress of an SR-MPLS TE tunnel:
a. Run system-view

b. Run mpls

c. Run mpls te bfd enable [ one-arm-echo ]
The capability to dynamically create BFD sessions to monitor SR-MPLS TE

LSPs is enabled globally.
After the capability is enabled globally, the ingress automatically creates

BFD sessions for LSPs of all the SR-MPLS TE tunnels, except those on
which the capability to dynamically create BFD sessions is blocked.
By default, the capability to dynamically create BFD sessions to monitor

SR-MPLS TE LSPs is disabled.
If one-arm-echo is specified, a one-arm BFD echo session is established

to monitor an SR-MPLS TE LSP. This is required if a Huawei device is
deployed at the ingress and a non-Huawei device is deployed at the
egress, because they cannot communicate using BFD for SR-MPLS TE
LSPs and therefore a BFD session cannot be established.
d. (Optional) If some SR-MPLS TE tunnels do not need to be monitored
using BFD for SR-MPLS TE LSPs, block the capability to dynamically
create BFD sessions on each tunnel interface.
▪ Run interface tunnel interface-number

▪ Run mpls te bfd block

The tunnel is disabled from automatically creating BFD sessions to
monitor SR-MPLS TE LSPs.
e. Run commit


● Enabling the capability on a tunnel interface
Perform the following steps on the ingress of an SR-MPLS TE tunnel:
a. Run system-view
b. Run interface tunnel interface-number
c. Run mpls te bfd enable [ one-arm-echo ]
The capability to dynamically create BFD sessions to monitor SR-MPLS TE
LSPs is enabled.
By default, the capability to dynamically create BFD sessions to monitor
SR-MPLS TE LSPs is disabled.
If one-arm-echo is specified, a one-arm BFD echo session is established
to monitor an SR-MPLS TE LSP. This is required if a Huawei device is
deployed at the ingress and a non-Huawei device is deployed at the
egress, because they cannot communicate using BFD for SR-MPLS TE
LSPs and therefore a BFD session cannot be established.
d. Run commit
----End
5.6.6.3 Enabling the Egress to Passively Create a BFD Session
Context
On a unidirectional LSP, after the active role (ingress) creates a BFD session and
the passive role (egress) receives an LSP ping packet sent by the ingress, the
egress can automatically create a BFD session.
Perform the following steps on the egress of an SR-MPLS TE tunnel.
NOTE
required.
Procedure
Step 2 Run bfd
The BFD view is displayed.
Step 3 Run mpls-passive
The egress is enabled to create a BFD session passively.

By default, the egress of an LSP cannot passively create a BFD session.

The egress can create a BFD session only after receiving an LSP ping request
carrying a BFD TLV.
Step 4 Run commit
----End
5.6.6.4 (Optional) Adjusting BFD Parameters on the Ingress Node
Context
Adjust BFD parameters on the ingress node using either of the following methods:
● Adjusting BFD parameters globally: This method is used if BFD parameters
for most SR-MPLS TE tunnels need to be adjusted on the ingress node.
● Adjusting BFD parameters on a specific tunnel interface: This method is
used if an SR-MPLS TE tunnel interface needs BFD parameters different from
the globally configured ones.
NOTE
The sending, receiving, and detection intervals are calculated as follows:

● Actual local sending interval = MAX { Configured local sending interval, Configured
remote receiving interval }
● Actual local receiving interval = MAX { Configured remote sending interval, Configured
local receiving interval }
● Actual local detection interval = Actual local receiving interval x Configured remote
detection multiplier
On the egress node of an SR-MPLS TE tunnel, a BFD session is passively created. The BFD
parameters cannot be adjusted. That is, the default values are the smallest values that can
be set on the ingress node. Therefore, the effective BFD detection period on both ends of an
SR-MPLS TE tunnel is as follows:
● Effective detection period on the ingress node = Configured interval at which BFD
packets are received on the ingress node x 3
● Effective detection period on the egress node = Configured interval at which BFD
packets are sent on the ingress node x Configured detection multiplier on the ingress
node
Perform the following configurations on the ingress node of an SR-MPLS TE

tunnel.
Procedure
● Adjusting BFD parameters globally
a. Run system-view
b. Run bfd
c. Run mpls ping interval interval

The interval at which LSP ping packets are sent is set.
By default, the interval at which LSP ping packets are sent in a dynamic
BFD session is 60 seconds.
d. Run quit

e. Run mpls

f. Run mpls te bfd { min-tx-interval tx-interval | min-rx-interval rx-
interval | detect-multiplier multiplier } *
BFD parameters are set.
By default, the minimum intervals at which BFD packets are sent and
received are 1000, and the local detection multiplier is 3.
g. Run commit

● Adjusting BFD parameters on a specific tunnel interface
a. Run system-view

b. Run bfd

c. Run mpls ping interval interval
The interval at which LSP ping packets are sent is set.
By default, the interval at which LSP ping packets are sent in a dynamic
BFD session is 60 seconds.
d. Run quit

e. Run interface tunnel interface-number

f. Run mpls te bfd { min-tx-interval tx-interval | min-rx-interval rx-
interval | detect-multiplier multiplier } *
BFD parameters are set.
By default, the minimum intervals at which BFD packets are sent and
received are 1000, and the local detection multiplier is 3.
g. Run commit
----End

5.6.6.5 Verifying the Configuration of Dynamic BFD for SR-MPLS TE LSPs
Prerequisites
Dynamic BFD for SR-MPLS TE LSPs has been configured.
Procedure
● Run the display bfd session dynamic [ verbose ] command to check
information about BFD sessions on the ingress.
● Run the display bfd session passive-dynamic [ peer-ip peer-ip remote-
discriminator discriminator ] [ verbose ] command to check information
about BFD sessions that are passively created on the egress.
– To check all BFD statistics, run the display bfd statistics command.
– To check statistics about dynamic BFD sessions, run the display bfd
statistics session dynamic command.
● Run the display mpls bfd session protocol sr-te [ verbose ] command to
check information about BFD sessions for MPLS.
----End
5.6.7 Configuring an SR-MPLS TE Group to Implement

Differentiated Services
When ECMP outbound interfaces contain SR-MPLS TE tunnel interfaces, you can
configure an SR-MPLS TE group to preferentially forward important services.
Before configuring an SR-MPLS TE group to implement differentiated services,
complete the following tasks:
● Configure an SR-MPLS TE tunnel. For details, see 5.6.1 Configuring an SR-
MPLS TE Tunnel.
● Import traffic to the SR-MPLS TE tunnel. For details, see 5.6.2 Importing
Traffic to an SR-MPLS TE Tunnel.
5.6.7.1 Setting the CoS of Packets
Context
The class of service (CoS) of a packet represents the CoS of the SR-MPLS TE
tunnel that the packet expects to pass through, which can be obtained in either of
the following methods:
● Packet priority mapping
For packets entering a tunnel, the DSCP or EXP field in the packet header is
mapped to the forwarding priority according to the mapping relationship

defined in the DiffServ domain. The internal priority obtained through

mapping is the CoS of the packets.
If you want to select a tunnel to forward service packets based on the original
priority of the packets or change the priority of the original service packets,
use this mode.
● MQC re-marking
For packets entering a tunnel, the packets are classified based on the IP 5-
tuple information in the packets, and the internal priority of the packets
matching the traffic classifier rules is re-marked. The re-marked interval
priority is the CoS of the packets.
If you do not want to select a tunnel to forward packets based on the original
priority of the packets or the packets do not carry any priority information,
use this mode.
Procedure
● Configure packet priority mapping.
After packet priority mapping is configured on the ingress node of an SR-
MPLS TE tunnel, the internal priority obtained through mapping is the CoS of
the packets. For details, see Configuring Priority Mapping in CloudEngine
12800 and 12800E Series Switches QoS Configuration Guide.
By default, the device maps the priority of original packets to the internal
priority based on the mapping defined in the default domain.
● Configure MQC re-marking.
a. Configure a traffic classifier.
i. Run system-view
ii. Run traffic classifier classifier-name [ type { and | or } ]
A traffic classifier is created and the traffic classifier view is displayed,
or the view of an existing traffic classifier is displayed.
and is the logical operator between rules in a traffic classifier, which
means that:
○ If a traffic classifier contains ACL rules, packets match the traffic
classifier only if they match one ACL rule and all the non-ACL
rules.
○ If a traffic classifier does not contain any ACL rules, packets
match the traffic classifier only if they match all the rules in the
classifier.
The logical operator or means that packets match a traffic classifier
if they match one or more rules in the classifier.
By default, the relationship between rules in a traffic classifier is or.
iii. Run if-match acl { acl-number | acl-name }
An ACL is used to define a traffic classification rule, traffic
classification is performed based on the IP 5-tuple information
carried in packets.

NOTE
● If an ACL is used to define a traffic classification rule, configure the ACL

first. In the ACL, you must specify the destination IP address of packets
matching the ACL, and the mask length of the specified destination IP
address must be greater than or equal to that of the destination
network segment route.
● If an ACL in a traffic classifier defines multiple rules, a packet matches
the ACL as long as it matches one of the rules, regardless of whether the
relationship between rules in the traffic classifier is AND or OR.
iv. Run commit
v. Run quit
Exit from the traffic classifier view.
b. Configure traffic behavior.
i. Run traffic behavior behavior-name
A traffic behavior is created and the traffic behavior view is
displayed, or the existing traffic behavior view is displayed.
ii. Run remark local-precedence { local-precedence-name | local-
precedence-value } [ green | yellow | red ]
Packets matching the traffic classifier are re-marked with an internal
precedence.
iii. Run commit
iv. Run quit
Exit from the traffic behavior view.
c. Configure a traffic policy.
i. Run traffic policy policy-name
A traffic policy is created and the traffic policy view is displayed, or
the view of an existing traffic policy is displayed.
ii. Run classifier classifier-name behavior behavior-name [ precedence
precedence-value ]
A traffic behavior is bound to a traffic classifier in the traffic policy.
iii. Run commit
iv. Run quit
Exit from the traffic policy view.
d. Apply the traffic policy.

NOTE
● For details about the configuration guidelines of applying traffic policies in

different views on the CE12800, see Licensing Requirements and Limitations
for MQC (CE12800).
● For details about the configuration guidelines of applying traffic policies in
different views on the CE12800E, see Licensing Requirements and Limitations
for MQC (CE12800E).
● For the CE12800 and the CE12800E equipped with FD-X series cards, run the
display traffic-policy pre-state { global [ slot slot-id ] | interface
{ interface-type interface-number } | vlan vlan-id | bridge-domain bd-id }
policy-name { inbound | outbound } command before committing the
configuration to check the information about resources occupied by the traffic
policy to be applied and determine whether the traffic policy can be
successfully applied based on the information.
● If a traffic policy needs to be applied to multiple VLANs and interfaces or
multiple traffic classifiers for matching packets from different source IP
addresses need to be bound to the same traffic policy, you are advised to add
these VLANs, source IP addresses, and interfaces to the same QoS group and
apply the traffic policy to the QoS group.
i. Run interface interface-type interface-number[.subinterface-

number ]
The interface view or layer 3 sub-interface view is displayed.
ii. Run traffic-policy policy-name inbound
A traffic policy is applied to the interface in the inbound direction.
iii. Run commit
----End
5.6.7.2 Setting the CoS Value for a TE Tunnel
Context
An SR-MPLS TE group consists of several SR-MPLS TE tunnels that forward service
packets based on the mapping between the CoS value of tunnels and CoS value of
service packets, implementing differentiated services. One SR-MPLS TE tunnel can
have one or more CoS values.
Procedure
The SR-MPLS TE tunnel interface view is displayed.
Step 3 Run mpls te service-class { service-class &<1-8> | default }
The CoS value of a tunnel is configured.

By default, no CoS value is configured for a tunnel.

When packets are mapped to the CS6 or CS7, the packets need to be processed
with the highest priority, and the packets are forwarded through the same tunnel.
Step 4 Run commit
----End
5.6.7.3 Verifying the SR-MPLS TE Group Configuration
Prerequisites
All the SR-MPLS TE group configuration has been complete.
Procedure
● Run the display diffserv domain [ brief | ds-domain-name ] command to
check the DiffServ domain configuration.
outgoing-interface } interface-type interface-number ] [ verbose ] command
to check the tunnel information.
● Run the display mpls te tunnel-interface [ tunnel interface-number ]
command to check information about the tunnel interfaces on the ingress
node.
----End
5.6.8 Maintaining SR-MPLS TE
5.6.8.1 Verifying the SR-MPLS TE Tunnel Connectivity
Procedure
● Run the ping lsp [ -a source-ip | -c count | -exp exp-value | -h ttl-value | -m
interval | -s packet-size | -t time-out | -v | -g ] * segment-routing te tunnel
interface-number [ hot-standby ] or ping lsp [ -a source-ip | -c count | -exp
exp-value | -h ttl-value | -m interval | -s packet-size | -t time-out | -v | -g ] *
segment-routing ip destination-address mask-length version draft2
[ remote remote-ip ] command to check the connectivity of the SR-MPLS TE
tunnel between the ingress and egress.
If hot-standby is configured, the hot-standby CR-LSP of the SR-MPLS TE
tunnel is checked.
● Run the tracert lsp [ -a source-ip | -exp exp-value | -h ttl-value | -s size | -g ] *
segment-routing te tunnel interface-number [ hot-standby ] [ detail ] or
tracert lsp [ -a source-ip | -exp exp-value | -h ttl-value | -t time-out | -s size |
-g ] * segment-routing ip destination-address mask-length version draft2

[ remote remote-ip ]command to trace the hops along an SR-MPLS TE

tunnel.
If the hot-standby parameter is specified, the hot-standby CR-LSP of the SR-
MPLS TE tunnel can be tested.
----End
5.6.8.2 Collecting and Checking SR-MPLS TE Tunnel Statistics
Context
To check the network status or locate network faults, you can enable traffic
statistics collection on SR-MPLS TE tunnel interfaces and collect traffic statistics on
the interfaces.
NOTE
● The traffic statistics collection period on an SR-MPLS TE tunnel must be larger than 30s.
Otherwise, the statistics are inaccurate.
● If traffic statistics collection is enabled on an SR-MPLS TE tunnel interface and a VLANIF
interface or a Layer 3 sub-interface on the tunnel, packets with the SR-MPLS TE tunnel
interface as the next hop are counted as statistics on the SR-MPLS TE tunnel interface, but
not statistics on the VLANIF interface or Layer 3 sub-interface.
● In an L3VPN over SR-MPLS TE scenario, if traffic statistics collection is enabled for both SR-
MPLS TE tunnels and L3VPN, the function takes effect for SR-MPLS TE traffic but not for
incoming L3VPN traffic.
● For cards except CE-L48XS-FDA, CE-L48XS-FD, CE-L48XS-FG, CE-L48XS-FD1, CE-L24LQ-FD,
CE-L36LQ-FD, CE-L12CQ-FD, CE-L36CQ-FG, CE-L36CQ-FD1, CE-L36CQ-SD, CE-L16CQ-FD, CE-
L08CF-FG1, and CE-L36CQ-FD, when multiple SR-MPLS TE tunnels load balance traffic using
ECMP, traffic statistics collection in the inbound direction of an SR-MPLS TE tunnel becomes
invalid.
Procedure
Step 3 Run statistic enable
Traffic statistics collection of an SR-MPLS TE tunnel is enabled.
By default, traffic statistics collection of an SR-MPLS TE tunnel is disabled.
Step 4 Run commit
----End
Follow-up Procedure
● Run display traffic statistics interface tunnel interface-numberTraffic
statistics on an SR-MPLS TE tunnel interface are displayed.

5.6.8.3 Verifying SR-MPLS TE Running Information
Context
To check SR-MPLS TE information during routine maintenance, run the following
display commands in any view.
Procedure
● Run the display default-parameter mpls te management command to
check default parameters of MPLS TE management.
● Run the display mpls te tunnel statistics or display mpls sr-te-lsp
command to check tunnel statistics.
● Run the display mpls te tunnel-interface last-error [ tunnel interface-
number ] command to check information about faults of tunnel interfaces.
● Run the display mpls te tunnel-interface failed command to check tunnels
that fail to be established or are being established.
----End
5.6.9 Configuration Examples for SR-MPLS TE

This section only provides configuration examples for individual features. For
details about multi-feature configuration examples, feature-specific configuration
examples, interoperation examples, protocol or hardware replacement examples,
and industry application examples, see the Typical Configuration Examples.
5.6.9.1 Example for Configuring an SR-MPLS TE Tunnel
Networking Requirements
On the network shown in Figure 5-23, a customer wants to establish a tunnel and
an LSP from PE1 to PE2. The SR protocol is used for path generation and data
forwarding. PE1, P1, and PE2 are the ingress, transit, and egress nodes,
respectively. P1 is responsible for collecting network topology information and
reporting collected information to the controller using Border Gateway Protocol-
link state (BGP-LS). The controller calculates LSPs based on received topology
information and delivers path information to PE1.

Figure 5-23 SR-MPLS TE tunnel networking
Controller
7.1.2.9/24
NETCONF BGP-LS
interface3
7.1.2.10/24 P1
IS-IS IS-IS
PE1 PE2
10GE1/0/1 10GE1/0/1 10GE1/0/2 10GE1/0/2
10.1.23.2/24 10.1.23.3/24 20.1.34.3/24 20.1.34.4/24
Loopback0 Loopback0 Loopback0
2.1.2.9/32 3.1.2.9/32 4.1.2.9/32
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure an IP address for each interface, and configure IS-IS on each node
to ensure there are reachable routes between them.
2. Enable MPLS, MPLS TE, and SR globally on each node and enable MPLS and
MPLS TE on each interface to establish an SR-MPLS TE tunnel.
3. Enable the IS-IS SR-MPLS TE capability on each node, so that TE information
can be advertised to other nodes.
4. Establish a BGP-LS peer relationship between P1 and the controller, so that P1
can report topology information to the controller using BGP-LS.
5. Configure a tunnel interface on PE1, and specify a tunnel IP address,
tunneling protocol, destination IP address, and tunnel bandwidth.
Data Plan
To complete the configuration, you need the following data:
● Interface IP addresses for device interconnection, as shown in Figure 5-23
● IS-IS process ID (1), IS-IS system ID of each node (converted from each node's
loopback0 IP address), and IS-IS level (level-2)
● BGP process ID (100) for establishing a BGP-LS peer relationship between the
controller and P1, as shown in Figure 5-23
Procedure
Step 1 Assign IP addresses to the interfaces.
Configure an IP address and a subnet mask for each interface. For details, see
Configuration Files in this example.
Step 2 Configure IS-IS to advertise the route to each network segment of each interface
and to advertise the host route to each loopback address (used as an LSR ID).

Configure IS-IS on PE1, P1, and PE2 to ensure there are reachable routes between
them. For details, see Configuration Files in this example.
Step 3 Configure basic MPLS functions and enable MPLS TE.
# Configure PE1. The configurations of P1 and PE2 are similar to that of PE1, and
are not mentioned here. For details, see Configuration Files in this example.
[~PE1] mpls lsr-id 2.1.2.9
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1] interface 10ge 1/0/1
[*PE1-10GE1/0/1] mpls
[*PE1-10GE1/0/1] mpls te
[*PE1-10GE1/0/1] quit
[*PE1] commit
Step 4 Enable the SR capability globally on each node.

[~PE1] segment-routing
[*PE1-segment-routing] quit
[*PE1] commit
Step 5 Enable the IS-IS SR-MPLS TE capability on each node.

[~PE1] isis 1
[~PE1-isis-1] cost-style wide
[*PE1-isis-1] traffic-eng level-2
[*PE1-isis-1] segment-routing mpls
[*PE1-isis-1] quit
[*PE1] commit
Step 6 Configure a BGP-LS peer relationship between the controller and the forwarder
(P1).
Configure a BGP-LS peer relationship between the controller and P1, so that P1
# On P1, configure the IS-IS network topology advertisement to BGP.
[~P1] isis 1
[~P1-isis-1] bgp-ls enable level-2
[*P1-isis-1] bgp-ls identifier 20
[*P1-isis-1] quit
[*P1] commit
# On P1, configure the BGP-LS route advertisement capability.

[~P1] bgp 100
[*P1-bgp] peer 7.1.2.9 as-number 100
[*P1-bgp] link-state-family unicast
[*P1-bgp-af-ls] peer 7.1.2.9 enable
[*P1-bgp-af-ls] quit
[*P1-bgp] quit
[*P1] commit
Step 7 Configure a tunnel interface on the ingress node.

# Configure PE1.
[~PE1] interface tunnel1
[*PE1-Tunnel1] ip address unnumbered interface loopback 0

[*PE1-Tunnel1] tunnel-protocol mpls te

[*PE1-Tunnel1] destination 4.1.2.9
[*PE1-Tunnel1] mpls te tunnel-id 1
[*PE1-Tunnel1] mpls te signal-protocol segment-routing
[*PE1-Tunnel1] mpls te pce delegate
[*PE1-Tunnel1] quit
[*PE1] commit
Step 8 Verify the configuration.
# After the configurations are complete, run the display bgp link-state unicast
peer command on P1. You can view information about the BGP-LS peer and its
status.
[~P1] display bgp link-state unicast peer
BGP local router ID : 11.1.1.2
Local AS number : 100
Total number of peers :1
Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv

7.1.2.9 4 100 27 48 0 00:29:11 Established 17
# Run the display interface tunnel command on PE1. You can view that the
tunnel interface status is Up.
[~PE1] display interface tunnel
Tunnel1 current state : UP (ifindex: 1554)
Line protocol current state : UP
Last line protocol up time : 2017-04-06 14:20:51
Description:
Route Port,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack0(2.1.2.9/32)
Encapsulation is TUNNEL, loopback not set
Tunnel destination 4.1.2.9
Tunnel up/down statistics 1
Tunnel ct0 bandwidth is 0 Kbit/sec
Tunnel protocol/transport MPLS/MPLS, ILM is available
primary tunnel id is 0x6001, secondary tunnel id is 0x0
Current system time: 2017-04-06 15:41:50
0 seconds output rate 0 bits/sec, 0 packets/sec
0 packets output, 0 bytes
0 output error
0 output drop
Last 300 seconds input utility rate: --
Last 300 seconds output utility rate: --
# Run the display mpls te tunnel command on PE1. You can view the
information about SR-MPLS TE tunnel establishment.
[~PE1] display mpls te tunnel -------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/OutLabel R Tunnel-name
-------------------------------------------------------------------------------
2.1.2.9 4.1.2.9 7 -/33153 I Tunnel1
-------------------------------------------------------------------------------
R: Role, I: Ingress, T: Transit, E: Egress
# Run the display mpls te tunnel path command on PE1. You can view path
information of the SR-MPLS TE tunnel.
[~PE1] display mpls te tunnel path
Tunnel Interface Name : Tunnel1
Lsp ID : 2.1.2.9 :1 :7
Hop Information
Hop 0 Link label 33153 NAI 10.1.23.3
----End

Configuration Files
● PE1 configuration file
#
sysname PE1
#
mpls lsr-id 2.1.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.2222.2222.2222.00
traffic-eng level-2
segment-routing mpls
#
interface 10GE1/0/1
undo portswitch
ip address 10.1.23.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 2.1.2.9 255.255.255.255
isis enable 1
#
interface Tunnel1
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 4.1.2.9
mpls te signal-protocol segment-routing
mpls te tunnel-id 1
mpls te pce delegate
#
return
● P1 configuration file
#
sysname P1
#
mpls lsr-id 3.1.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.1111.1111.1111.00
traffic-eng level-2
bgp-ls enable level-2
bgp-ls identifier 20
#
interface 10GE1/0/1
undo portswitch
ip address 10.1.23.3 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/2

undo portswitch
ip address 20.1.34.3 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/3
undo portswitch
ip address 7.1.2.10 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 3.1.2.9 255.255.255.255
isis enable 1
#
bgp 100
peer 7.1.2.9 as-number 100
#
ipv4-family unicast
peer 7.1.2.9 enable
#
link-state-family unicast
peer 7.1.2.9 enable
#
return

#
sysname PE2
#
mpls lsr-id 4.1.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.3333.3333.3333.00
traffic-eng level-2
#
interface 10GE1/0/2
undo portswitch
ip address 20.1.34.4 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 4.1.2.9 255.255.255.255
isis enable 1
#
return
5.6.9.2 Example for Configuring Static BFD for SR-MPLS TE Tunnels
On the network shown in Figure 5-24, a customer wants to establish a tunnel and
an LSP from PE1 to PE2. The SR protocol is used for path generation and data
forwarding. PE1, P1, and PE2 are the ingress, transit, and egress nodes,
respectively. P1 is responsible for collecting network topology information and

reporting collected information to the controller using BGP-LS. The controller

calculates LSPs based on received topology information and delivers path
information to PE1.
Static BFD for SR-MPLS TE tunnels can be configured to quickly detect a tunnel
fault and switch traffic accordingly.
NOTE
If a Huawei device connects to a non-Huawei device that does not support BFD, configure
one-arm BFD to detect the links.
Figure 5-24 Configuring static BFD for SR-MPLS TE tunnels
Controller
7.1.2.9/24
NETCONF BGP-LS
interface3
7.1.2.10/24 P1
IS-IS IS-IS
PE1 PE2
10GE1/0/1 10GE1/0/1 10GE1/0/2 10GE1/0/2
10.1.23.2/24 10.1.23.3/24 20.1.34.3/24 20.1.34.4/24
2.1.2.9/32 3.1.2.9/32 4.1.2.9/32
4. Establish a BGP-LS peer relationship between P1 and the controller, so that P1
5. Configure a tunnel interface on PE1, configure a reverse tunnel interface on
PE2, and specify a tunnel IP address, tunneling protocol, destination IP
address, and tunnel bandwidth.
6. Configure a BFD session on PE1 and PE2 to monitor the SR-MPLS TE tunnel.
Data Plan

controller and P1, as shown in Figure 5-24
● Name, local and remote discriminators of a BFD session
Procedure
Configure IS-IS on PE1, P1, and PE2 to ensure reachable routes between them. For
details, see Configuration Files in this example.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1-10GE1/0/1] mpls
[*PE1-10GE1/0/1] quit
[*PE1] commit

[*PE1] commit

[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
(P1).
Configure a BGP-LS peer relationship between the controller and P1, so that P1
# On P1, configure the IS-IS network topology advertisement to BGP.

[~P1] isis 1
[~P1-isis-1] bgp-ls enable level-2
[*P1-isis-1] bgp-ls identifier 20
[*P1-isis-1] quit
[*P1] commit
# On P1, configure the BGP-LS route advertisement capability.

[~P1] bgp 100
[*P1-bgp] peer 7.1.2.9 as-number 100
[*P1-bgp] link-state-family unicast
[*P1-bgp-af-ls] peer 7.1.2.9 enable
[*P1-bgp-af-ls] quit
[*P1-bgp] quit
[*P1] commit
Step 7 Configure a tunnel interface on the ingress node and a reverse tunnel interface on
the egress node.
# Configure PE1.
[*PE1-Tunnel1] quit
[*PE1] commit
# Configure PE2.
[*PE2-Tunnel1] quit
[*PE2] commit

# After the configurations are complete, run the display bgp link-state unicast
peer command on P1. You can view information about the BGP-LS peer and its
status.
[~P1] display bgp link-state unicast peer

7.1.2.9 4 100 27 48 0 00:29:11 Established 17
# Run the display interface tunnel command on PE1. You can view that the
tunnel interface status is Up.
[~PE1] display interface tunnel
Tunnel1 current state : UP (ifindex: 1554)
Line protocol current state : UP
Last line protocol up time : 2017-04-06 14:20:51
Description:
Route Port,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack0(2.1.2.9/32)
Encapsulation is TUNNEL, loopback not set
Tunnel destination 4.1.2.9
Tunnel up/down statistics 1

Tunnel ct0 bandwidth is 0 Kbit/sec

Tunnel protocol/transport MPLS/MPLS, ILM is available
primary tunnel id is 0x6001, secondary tunnel id is 0x0
Current system time: 2017-04-06 15:41:50
0 packets output, 0 bytes
0 output error
0 output drop
Last 300 seconds input utility rate: --
Last 300 seconds output utility rate: --
-------------------------------------------------------------------------------
2.1.2.9 4.1.2.9 7 -/33153 I Tunnel1
-------------------------------------------------------------------------------
Lsp ID : 2.1.2.9 :1 :7
Hop Information
Step 9 Configure BFD for SR-MPLS TE tunnels.

# Configure a BFD session on PE1 to detect the SR-MPLS TE tunnel, and set the
minimum intervals at which BFD packets are sent and received.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] bfd pe1tope2 bind mpls-te interface tunnel1
[*PE1-bfd-lsp-session-pe1tope2] discriminator local 12
[*PE1-bfd-lsp-session-pe1tope2] discriminator remote 21
[*PE1-bfd-lsp-session-pe1tope2] commit
# Configure a BFD session on PE2 to detect the reverse SR-MPLS TE tunnel, and
set the minimum intervals at which BFD packets are sent and received.
[~PE2] bfd
[*PE2-bfd] quit
[*PE2] bfd pe2tope1 bind mpls-te interface tunnel1
[*PE2-bfd-lsp-session-pe2tope1] discriminator local 21
[*PE1-bfd-lsp-session-pe1tope2] discriminator remote 12
[*PE2-bfd-lsp-session-pe2tope1] commit
# After the configurations are complete, run the display bfd session mpls-te
interface tunnel command on PE1 and PE2. You can view that the status of BFD
sessions is Up.
----End
Configuration Files
#
sysname PE1
#
bfd

#
mpls lsr-id 2.1.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.2222.2222.2222.00
traffic-eng level-2
#
interface 10GE1/0/1
undo portswitch
ip address 10.1.23.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 2.1.2.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 4.1.2.9
mpls te tunnel-id 1
#
bfd pe1tope2 bind mpls-te interface Tunnel1
discriminator local 12
discriminator remote 21
#
return
#
sysname P1
#
mpls lsr-id 3.1.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.1111.1111.1111.00
traffic-eng level-2
#
interface 10GE1/0/1
undo portswitch
ip address 10.1.23.3 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/2
undo portswitch
ip address 20.1.34.3 255.255.255.0

isis enable 1
mpls
mpls te
#
interface 10GE1/0/3
undo portswitch
ip address 7.1.2.10 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 3.1.2.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 7.1.2.9 enable
#
peer 7.1.2.9 enable
#
return

#
sysname PE2
#
bfd
#
mpls lsr-id 4.1.2.9
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.3333.3333.3333.00
traffic-eng level-2
#
interface 10GE1/0/2
undo portswitch
ip address 20.1.34.4 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 4.1.2.9 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 2.1.2.9
mpls te tunnel-id 1
#
bfd pe2tope1 bind mpls-te interface Tunnel1
discriminator local 21
discriminator remote 12
#
return

5.6.9.3 Example for Configuring Dynamic BFD for SR-MPLS TE LSPs
On the network shown in Figure 5-25, a customer wants to establish a tunnel as
well as primary and backup LSPs for the tunnel from PE1 to PE2. The SR protocol
is used for path generation and data forwarding. PE1, P1, and PE2 are the ingress,
transit, and egress nodes, respectively. PE2 is responsible for collecting network
topology information and reporting collected information to the controller using
BGP-LS. The controller calculates LSPs based on received topology information and
delivers path information to PE1.
The tunnel works in hot standby mode. Dynamic BFD for SR-MPLS TE LSPs can be
configured to quickly detect faults on SR-MPLS TE LSPs and protect traffic
transmitted along the SR-MPLS TE LSPs. If the primary LSP fails, traffic is switched
to the backup LSP. If the primary LSP recovers, traffic is switched back to it.
NOTE
If a Huawei device connects to a non-Huawei device that does not support BFD, configure
one-arm BFD to detect the links.
Figure 5-25 Configuring dynamic BFD for SR-MPLS TE LSPs

Controller
10.2.1.2/24
NETCONF BGP-LS
10GE1/0/2
Loopback0 10.2.1.1/24 Loopback0
1.1.1.1/32 3.3.3.3/32
10GE1/0/1 10GE1/0/1
10.1.1.1/24 IS-IS 10.1.1.2/24
PE1 PE2
10G1/0/2 10GE1/0/3
10.1.2.1/24 10.1.3.1/24
IS-IS IS-IS
10GE1/0/2 10GE1/0/3
10.1.2.2/24 10.1.3.2/24
P1
Loopback0 PrimaryLSP
2.2.2.2/32 Backup LSP

4. Establish a BGP-LS peer relationship between PE2 and the controller, so that
PE2 can report topology information to the controller using BGP-LS.
5. Configure a tunnel interface on PE1, and specify a tunnel IP address,
tunneling protocol, destination IP address, and tunnel bandwidth.
6. On PE1, configure hot-standby CR-LSPs for the tunnel.
7. On PE1, enable BFD and configure dynamic BFD for SR-MPLS TE LSPs, so that
PE2 passively creates a BFD session.
Data Plan

controller and P1, as shown in Figure 5-25.
● Name, local and remote discriminators of a BFD session
Procedure
Configure IS-IS on PE1, P1, and PE2 to ensure there are reachable routes between
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1-10GE1/0/1] mpls
[*PE1-10GE1/0/1] quit
[*PE1] commit

[*PE1] commit

[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
(PE2).
Configure a BGP-LS peer relationship between the controller and PE2, so that PE2
# On PE2, configure the IS-IS network topology advertisement to BGP.
[~PE2] isis 1
[~PE2-isis-1] bgp-ls enable level-2
[*PE2-isis-1] bgp-ls identifier 20
[*PE2-isis-1] quit
[*PE2] commit
# On PE2, configure the BGP-LS route advertisement capability.

[~PE2] bgp 100
[*PE2-bgp] peer 10.2.1.2 as-number 100
[*PE2-bgp] link-state-family unicast
[*PE2-bgp-af-ls] peer 10.2.1.2 enable
[*PE2-bgp-af-ls] quit
[*PE2-bgp] quit
[*PE2] commit
Step 7 Configure a tunnel interface on the ingress node.

# Configure PE1.
[*PE1-Tunnel1] mpls te backup hot-standby
[*PE1-Tunnel1] quit
[*PE1] commit

# After the configurations are complete, run the display mpls te tunnel-interface
command on PE1. You can view the information about the SR-MPLS TE tunnel
interface.
[~PE1] display mpls te tunnel-interface tunnel 1
Tunnel Name : Tunnel1
Signalled Tunnel Name: -
Tunnel State Desc : Primary CR-LSP Up and HotBackup CR-LSP Up
Tunnel Attributes :
Active LSP : Primary LSP
Traffic Switch :-
Session ID :1

Ingress LSR ID : 1.1.1.1 Egress LSR ID: 3.3.3.3

Admin State : UP Oper State : UP
Signaling Protocol : Segment-Routing
FTid : 32769
Tie-Breaking Policy : None Metric Type : None
Bfd Cap : None
Reopt : Disabled Reopt Freq : -
Auto BW : Disabled Threshold : -
Current Collected BW: - Auto BW Freq : -
Min BW :- Max BW :-
Offload : Disabled Offload Freq : -
Low Value :- High Value : -
Readjust Value :-
Offload Explicit Path Name: -
Tunnel Group : Primary
Interfaces Protected: -
Excluded IP Address : -
Referred LSP Count : 0
Primary Tunnel :- Pri Tunn Sum : -
Backup Tunnel :-
Group Status : Up Oam Status : None
IPTN InLabel :- Tunnel BFD Status : -
BackUp LSP Type : Hot-Standby 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 : Active LSP Control Status : PCE control
Auto BW Remain Time : - Reopt Remain Time :-
Primary LSP ID : 1.1.1.1:21
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): 0 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 : Disabled
Reroute Flag : Enabled
Pce Flag : Normal
Backup LSP ID : 1.1.1.1:26
IsBestEffortPath : No
LSP State : UP LSP Type : Hot-Standby
Setup Priority :7 Hold Priority: 7

IncludeAll : 0x0
IncludeAny : 0x0
ExcludeAny : 0x0
Affinity Prop/Mask : 0x0/0x0 Resv Style : SE
Configured Bandwidth Information:
Actual Bandwidth Information:
CT0 Bandwidth(Kbit/sec): 0 CT1Bandwidth(Kbit/sec): 0
Explicit Path Name : - Hop Limit: -
Record Route : Disabled Record Label : Disabled
Route Pinning : Disabled
FRR Flag : Disabled
IdleTime Remain :-
BFD Status :-
Soft Preemption : Disabled
Reroute Flag : Enabled
Pce Flag : Normal
-------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 21 -/33200 I Tunnel1
1.1.1.1 3.3.3.3 26 -/33153 I Tunnel1
-------------------------------------------------------------------------------
Lsp ID : 1.1.1.1 :1 :21
Hop Information

Lsp ID : 1.1.1.1 :1 :26
Hop Information
Step 9 On PE1, enable BFD and configure BFD for SR-MPLS TE LSPs.
# On the tunnel interface of PE1, configure BFD for SR-MPLS TE LSPs, set the
minimum intervals at which BFD packets are sent and received to 100 ms, and set
the local detection multiplier to 3.
[~PE1] bfd
[*PE1-bfd] quit
[*PE1] interface tunnel 1
[*PE1-Tunnel1] mpls te bfd enable
[*PE1-Tunenl1] quit
[*PE1] commit
Step 10 On PE2, enable passive BFD session creation.

[~PE2] bfd
[*PE2-bfd] mpls-passive
[*PE2-bfd] quit
[*PE2] commit

# After the configurations are complete, run the display bfd session mpls-te
interface tunnel command on PE1 and run the display bfd session all command
on PE2. You can view that the status of BFD sessions is Up.
[~PE1] display bfd session mpls-te interface tunnel 1 te-lsp
S: Static session
D: Dynamic session
IP: IP session
IF: Single-hop session
PEER: Multi-hop session
LDP: LDP session
LSP: Label switched path
TE: Traffic Engineering
AUTO: Automatically negotiated session
VXLAN: VXLAN session
(w): State in WTR
(*): State is invalid
Total UP/DOWN Session Number : 2/0
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
16385 16386 3.3.3.3 Up D/TE-LSP Tunnel1
16386 16387 3.3.3.3 Up D/TE-LSP Tunnel1
--------------------------------------------------------------------------------
[~PE2] display bfd session all
S: Static session
D: Dynamic session
IP: IP session
IF: Single-hop session
PEER: Multi-hop session
LDP: LDP session
LSP: Label switched path
TE: Traffic Engineering
AUTO: Automatically negotiated session
VXLAN: VXLAN session
(w): State in WTR
(*): State is invalid
Total UP/DOWN Session Number : 2/0
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
16386 16385 1.1.1.1 Up E_Dynamic -
16387 16386 1.1.1.1 Up E_Dynamic -
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.2222.2222.2222.00
traffic-eng level-2

#
interface 10GE1/0/1
undo portswitch
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/2
undo portswitch
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 3.3.3.3
mpls te backup hot-standby
mpls te tunnel-id 1
mpls te bfd enable
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.1111.1111.1111.00
traffic-eng level-2
#
interface 10GE1/0/2
undo portswitch
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/3
undo portswitch
ip address 10.1.3.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
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
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.3333.3333.3333.00
traffic-eng level-2
#
interface 10GE1/0/1
undo portswitch
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/2
undo portswitch
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/3
undo portswitch
ip address 10.1.3.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 10.2.1.2 enable
#
#
return
5.6.9.4 Example for Configuring an SR-MPLS TE Group to Implement

Differentiated Services
On the network shown in Figure 5-26, CE1 and CE2 connect to the SR-MPLS TE
network through PE1 and PE2, respectively. Various types of service packets are
transmitted between CE1 and CE2. Two service types are important, with peak

traffic that can reach 10,000 kbit/s and 20,000 kbit/s. The other service types are
common, each with total traffic of 50,000 kbit/s. Note that the peak traffic of all
common services may exceed 50,000 kbit/s.
An SR-MPLS TE group can be configured to preferentially forward important

services when the network bandwidth is insufficient.
Figure 5-26 SR-MPLS TE group for implementing differentiated services

NOTE
In this example, CE1 and PE1 are connected through 10GE1/0/1; CE2 and PE2 are
connected through 10GE1/0/1; PE1 and PE2 are connected through 10GE1/0/2; PE1 and PE2
connect to the controller through 10GE1/0/3.
Controller
3.3.3.3/32
NETCONF
IS-IS
CE1 PE1 PE2 CE2

SR-TE Tunnel1
SR-TE Tunnel2
SR-TE Tunnel3
1.1.1.1/32 2.2.2.2/32 4.4.4.4/32
Table 5-8 Interface IP addresses
Device Interface IP Address
CE1 10GE1/0/1 192.168.1.1/24
CE2 10GE1/0/1 192.168.2.1/24
10GE1/0/1 192.168.1.2/24
10GE1/0/2 20.1.1.1/24
PE1
10GE1/0/3 20.1.2.1/24
LoopBack0 1.1.1.1/32
10GE1/0/1 192.168.2.2/24
10GE1/0/2 20.1.1.2/24
PE2
10GE1/0/3 20.1.3.1/24
LoopBack0 2.2.2.2/32

1. Create three SR-MPLS TE tunnels between PE1 and PE2 and assign
bandwidths for them.
2. On PE1, import service flows to the three SR-MPLS TE tunnels, which form an
equal-cost multi-path routing (ECMP) group.
3. On PE1, set the class of service (CoS) values for the three SR-MPLS TE
tunnels.
4. On PE1, set the CoS values for the service packets to permit two important
services to pass through two SR-MPLS TE tunnels and all the other common
services to pass through the last SR-MPLS TE tunnel.
Data Plan
● Interface IP addresses for device interconnection, as shown in Table 5-8
● IDs of the three SR-MPLS TE tunnels: 1, 2, and 3
● Bandwidths for SR-MPLS TE tunnels 1, 2, and 3: 10,000 kbit/s, 20,000 kbit/s,
and 50,000Kbit/s
● CoS values for SR-MPLS TE tunnels 1, 2, and 3: AF4, CS7, and default
● CoS values for two important service packets: AF4 and CS7
Procedure
Configure IS-IS on PE1 and PE2 to ensure there are reachable routes between
Step 3 Configure an IS-IS neighbor relationship between the controller and PE2.
Configure an IS-IS neighbor relationship between the controller and PE2, so that
PE2 can flood network topology information to the controller using IS-IS. For
details, see Configuration Files in this example.
Step 4 Configure basic SR-MPLS TE functions.
1. Configure basic MPLS functions and enable MPLS TE.
# Configure PE1. The configuration of PE2 is similar to that of PE1, and is not
mentioned here. For details, see Configuration Files in this example.
[*PE1] mpls
[*PE1-mpls] mpls te
[*PE1-mpls] quit
[*PE1-10GE1/0/2] mpls

[*PE1-10GE1/0/2] quit
[*PE1] commit
2. Enable the SR capability globally on each node.
[*PE1] commit
3. Enable the IS-IS SR-MPLS TE capability on each node.
[~PE1] isis 1
[*PE1-isis-1] cost-style wide
[*PE1-isis-1] quit
[*PE1] commit
4. Configure tunnel interfaces on the ingress node.
# Configure tunnel interfaces Tunnel1, Tunnel2, and Tunnel3 on PE1.
[~PE1] interface tunnel 1
[*PE1-Tunnel1] quit
[*PE1-Tunnel2] quit
[*PE1-Tunnel3] quit
[*PE1] commit
5. Import traffic to the tunnels on the ingress node.
# On PE1, configure three static routes to 5.5.5.0, with Tunnel1, Tunnel2, and
Tunnel3 as the outbound tunnel interfaces to import traffic to the tunnels.
[~PE1] ip route-static 5.5.5.0 255.255.255.0 tunnel1
[*PE1] ip route-static 5.5.5.0 255.255.255.0 tunnel2
[*PE1] ip route-static 5.5.5.0 255.255.255.0 tunnel3
[*PE1] commit
Step 5 Configure the tunnel bandwidths.

# On PE1, set the required bandwidths of tunnels Tunnel1, Tunnel2, and Tunnel3
to 10,000 kbit/s, 20,000 kbit/s, and 50,000 kbit/s respectively, and enable traffic
statistics collection for the tunnels.


[*PE1-Tunnel1] mpls te bandwidth ct0 10000
[*PE1-Tunnel1] statistic enable
[*PE1-Tunnel1] quit
[*PE1-Tunnel2] quit
[*PE1-Tunnel3] quit
[*PE1] commit
Step 6 Set the CoS values for the tunnels.

# On PE1, set the CoS values for SR-MPLS TE tunnels Tunnel1, Tunnel2, and
Tunnel3 to AF4, CS7, and default.
[*PE1-Tunnel1] mpls te service-class af4 cs7
[*PE1-Tunnel1] quit
[*PE1-Tunnel2] mpls te service-class af4 cs7
[*PE1-Tunnel2] quit
[*PE1-Tunnel3] mpls te service-class default
[*PE1-Tunnel3] quit
[*PE1] commit
Step 7 Set the CoS values for packets.

1. Configure traffic classifiers.
[~PE1] acl 3002
[*PE1-acl4-advance-3002] rule permit ip destination 5.5.5.1 32
[*PE1-acl4-advance-3002] commit
[~PE1-acl4-advance-3002] quit
[~PE1] acl 3003
[*PE1-acl4-advance-3003] rule permit ip destination 5.5.5.2 32
[*PE1-acl4-advance-3003] commit
[~PE1-acl4-advance-3003] quit
[~PE1] traffic classifier c1
[*PE1-classifier-c1] if-match acl 3002
[*PE1-classifier-c1] quit
[*PE1] traffic classifier c2
[*PE1-classifier-c2] if-match acl 3003
[*PE1-classifier-c2] quit
[*PE1] commit
2. Configure traffic behavior.
[~PE1] traffic behavior b1
[*PE1-behavior-b1] remark local-precedence af4
[*PE1-behavior-b1] quit
[*PE1] traffic behavior b2
[*PE1-behavior-b2] remark local-precedence cs7
[*PE1-behavior-b2] quit
[*PE1] commit
3. Configure a traffic policy.
[~PE1] traffic policy p1
[*PE1-trafficpolicy-p1] classifier c1 behavior b1
[*PE1-trafficpolicy-p1] classifier c2 behavior b2
[*PE1-trafficpolicy-p1] quit
[*PE1] commit
4. Apply the traffic policy.
[~PE1] interface 10ge 1/0/1
[*PE1-10GE1/0/1] traffic-policy p1 inbound
[*PE1-10GE1/0/1] quit
[*PE1] commit

After the configurations are complete, run the display mpls te tunnel command
on PE1. You can view that three SR-MPLS TE tunnels are set up.
-------------------------------------------------------------------------------
1.1.1.1 2.2.2.2 1 -/864256 I Tunnel1
1.1.1.1 2.2.2.2 2 -/864256 I Tunnel2
1.1.1.1 2.2.2.2 3 -/864256 I Tunnel3
-------------------------------------------------------------------------------
Run the display ip routing-table command on PE1. You can view that the ECMP
outbound interfaces are Tunnel1, Tunnel2, and Tunnel3.
[~PE1] display ip routing-table 5.5.5.0
Proto: Protocol Pre: Preference
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table : _public_
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface
5.5.5.0/24 Static 60 0 D 1.1.1.1 Tunnel1

Static 60 0 D 1.1.1.1 Tunnel2
Static 60 0 D 1.1.1.1 Tunnel3
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
acl number 3002
rule 5 permit ip destination 5.5.5.1 32
#
acl number 3003
rule 5 permit ip destination 5.5.5.2 32
#
traffic classifier c1 type or
if-match acl 3002
#
traffic classifier c2 type or
if-match acl 3003
#
traffic behavior b1
remark local-precedence af4
#
traffic behavior b2
remark local-precedence cs7
#
traffic policy p1
classifier c1 behavior b1 precedence 5
classifier c2 behavior b2 precedence 10
#
segment-routing
#
isis 1

is-level level-2
cost-style wide
network-entity 11.1111.1111.1111.00
traffic-eng level-2
#
interface 10GE1/0/1
undo portswitch
ip address 192.168.1.2 255.255.255.0
traffic-policy p1 inbound
#
interface 10GE1/0/2
undo portswitch
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/3
undo portswitch
ip address 20.1.2.1 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface Tunnel1
destination 2.2.2.2
mpls te bandwidth ct0 10000
statistic enable
mpls te tunnel-id 1
mpls te service-class af4 cs7
#
interface Tunnel2
destination 2.2.2.2
statistic enable
mpls te tunnel-id 2
mpls te service-class af4 cs7
#
interface Tunnel3
destination 2.2.2.2
statistic enable
mpls te tunnel-id 3
mpls te service-class default
#
ip route-static 5.5.5.0 255.255.255.0 Tunnel1
#
return
#
sysname PE2
#

mpls lsr-id 2.2.2.2

#
mpls
mpls te
#
segment-routing
#
isis 1
is-level level-2
cost-style wide
network-entity 11.1111.1111.2222.00
traffic-eng level-2
#
interface 10GE1/0/1
undo portswitch
ip address 192.168.2.2 255.255.255.0
#
interface 10GE1/0/2
undo portswitch
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
#
interface 10GE1/0/3
undo portswitch
ip address 20.1.3.1 255.255.255.0
isis enable 1
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
ip route-static 5.5.5.0 255.255.255.0 192.168.2.1
#
return
● CE1 configuration file

#
sysname CE1
#
interface 10GE1/0/1
undo portswitch
ip address 192.168.1.1 255.255.255.0
#
return

#
sysname CE2
#
interface 10GE1/0/1
undo portswitch
ip address 192.168.2.1 255.255.255.0
#
return
5.7 Configuring SR-MPLS BE

This chapter describes segment routing-best effort (SR-MPLS BE) implementation
and configuration procedure.

5.7.1 Configuring an SR-MPLS BE Tunnel

Usage Scenario
SR-MPLS BE can be implemented after basic SR-MPLS BE functions are configured.
After basic SR-MPLS BE functions are configured, you can configure optimization
methods, for example, the policy for triggering SR-LSP setup and policy for
preferentially selecting the SE-BE tunnel.
Creating an SR-MPLS BE tunnel involves the following operations:

● Devices report topology information to a controller (if the controller is used to
create a tunnel) and are assigned labels.
● The devices compute paths.
Before configuring a manual SR-MPLS BE tunnel, complete the following tasks:
● Configure IS-IS to implement network layer connectivity for LSRs.

● Set an LSR ID for each LSR.
● Enable MPLS globally on all LSRs.
5.7.1.1 Configuring Basic SR-MPLS BE Functions

This section describes how to configure basic SR-MPLS BE functions.
Context
Basic SR-MPLS BE function configurations involve enabling the global segment
routing capability, configuring the segment routing global block (SRGB), and
setting a prefix segment ID (SID).
Procedure
Step 1 Globally enable the segment routing capability.
1. Run system-view

2. Run segment-routing
The segment routing view is displayed.

3. Run commit
Step 2 Configure an SRGB.

1. Run system-view

2. Run isis [ process-id ]

3. Run network-entity net
The network entity title (NET) is configured.

4. Run cost-style { wide | compatible | wide-compatible }
The IS-IS wide metric function is enabled.

5. Run segment-routing mpls
The segment routing function for an IS-IS process is enabled.

6. Run segment-routing global-block begin-value end-value
An SRGB is configured in an existing IS-IS instance.

7. Run commit
Step 3 Set an SID.

1. Run system-view

2. Run interface loopback loopback-number
A loopback interface is created, and the loopback interface view is displayed.

3. Run isis enable [ process-id ]
The IS-IS interface is enabled.

4. Run ip address ip-address { mask | mask-length }
The IP address is configured for the loopback interface.

5. Run isis prefix-sid { absolute sid-value | index index-value } [ node-disable ]
The prefix SID is set on the loopback interface.

6. Run commit
----End
5.7.1.2 (Optional) Configuring a Policy for Triggering SR-LSP Establishment

A policy can be configured to allow the ingress node to establish SR-LSPs based on
eligible routes.
Context
After segment routing is enabled, a great number of devices establish excessive
E2E LSPs, leading to resource wastes. To prevent resource wastes, a policy for
establishing LSPs can be configured. The policy allows the ingress node to use only
allowed routes to establish SR-LSPs.

Procedure
Step 2 Run isis
Step 3 Run segment-routing lsp-trigger { none | host | ip-prefix ip-prefix-name }
A policy for establishing SR-LSPs is configured on the ingress node.
● host: The ingress node is allowed to use host IP routes with 32-bit masks to
establish SR-LSPs.
● ip-prefix: The ingress node is allowed to use FECs filtered by an IP address
prefix list to establish SR-LSPs.
● none: The ingress node is disabled from establishing SR-LSPs.
Step 4 Run commit
----End
5.7.1.3 (Optional) Configuring a Policy for Preferentially Selecting an SR-

MPLS BE Tunnel
By configuring a policy for preferentially selecting an SR-MPLS BE tunnel, you can
improve the priority of the SR tunnel and preferentially select the SR tunnel.
Context
In a tunnel iteration scenario, an LDP tunnel is preferentially selected to forward
traffic by default. To enable a device to preferentially select an SR-MPLS BE tunnel,
improve the SR-MPLS BE tunnel priority so that the SR-MPLS BE tunnel takes
preference over the LDP tunnel.
Procedure
Step 2 Run segment-routing
The segment routing view is displayed.
Step 3 Run tunnel-prefer segment-routing
SR-MPLS TE tunnels are configured to take precedence over LDP tunnels.
Step 4 Run commit
----End

5.7.1.4 Verifying the SR-MPLS BE Tunnel Configuration

After successfully configure SR-MPLS BE, you can view SR-MPLS BE configurations.
Prerequisites
The SR-MPLS BE functions have been configured.
Procedure
After completing the configurations, you can run the following commands to
check the configurations.
● Run the display isis lsdb [ { level-1 | level-2 } | verbose | { local | lsp-id | is-
name symbolic-name } ] * [ process-id | vpn-instance vpn-instance-name ]
command to check IS-IS LSDB information.
● Run the display segment-routing prefix mpls forwarding command to
check the label forwarding table for segment routing.
5.7.2 Configuration Examples for SR-MPLS BE

This section provides SR-MPLS BE configuration examples, including the
networking requirements, configuration roadmap, configuration procedure, and
configuration files.
This section only provides configuration examples for individual features. For
details about multi-feature configuration examples, feature-specific configuration
examples, interoperation examples, protocol or hardware replacement examples,
and industry application examples, see the Typical Configuration Examples.
5.7.2.1 Example for Configuring an SR-MPLS BE Tunnel
In Figure 5-27, devices run IS-IS. Segment routing is used and enables each device
to advertise the SR capability and supported SRGB. In addition, the advertising end
advertises a prefix SID offset within the SRGB range. The receive end computes an
effective label value to generate a forwarding entry.
Figure 5-27 SR-MPLS BE tunnel networking

SR Domain
AS: 100
Loopback1
2.2.2.9/32
10GE1/0/1
PE1 10GE1/0/1 172.2.1.2/24 PE2
172.1.1.1/24
Loopback1 Loopback1
1.1.1.9/32 3.3.3.9/32
10GE1/0/1 P1 10GE1/0/2
172.1.1.2/24 172.2.1.1/24

2. Configure MPLS and segment routing on the backbone network and establish
SR LSPs.
Procedure
Step 1 Configure IP addresses for interfaces.
# Configure PE1.
<HUAWEI> system-view
[~HUAWEI] sysname PE1
[*HUAWEI] commit
[~PE1] interface loopback 1
[*PE1-LoopBack1] ip address 1.1.1.9 32
[*PE1-LoopBack1] quit
[*PE1-10GE1/0/1] undo portswitch
[*PE1-10GE1/0/1] ip address 172.1.1.1 24
[*PE1-10GE1/0/1] quit
[*PE1] commit
# Configure P1.
[~HUAWEI] sysname P1
[*HUAWEI] commit
[~P1] interface loopback 1
[*P1-LoopBack1] ip address 2.2.2.9 32
[*P1-LoopBack1] quit
[*P1] interface 10ge 1/0/1
[*P1-10GE1/0/1] undo portswitch
[*P1-10GE1/0/1] ip address 172.1.1.2 24
[*P1-10GE1/0/1] quit
[*P1-10GE1/0/2] ip address 172.2.1.1 24
[*P1-10GE1/0/2] quit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2-10GE1/0/1] ip address 172.2.1.2 24
[*PE2-10GE1/0/1] quit
[*PE2] commit
Step 2 Configure an IGP protocol on the MPLS backbone network to implement

connectivity between the PEs and P1. IS-IS is used as an IGP protocol in this
example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] is-level level-1

[*PE1-isis-1] network-entity 10.0000.0000.0001.00

[*PE1-isis-1] quit
[*PE1] commit
[~PE1-LoopBack1] isis enable 1
[*PE1-10GE1/0/1] isis enable 1
[*PE1-10GE1/0/1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] is-level level-1
[*P1-isis-1] network-entity 10.0000.0000.0002.00
[*P1-isis-1] quit
[*P1] commit
[~P1-LoopBack1] isis enable 1
[*P1-10GE1/0/1] isis enable 1
[*P1-10GE1/0/1] quit
[*P1-10GE1/0/2] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2-10GE1/0/1] quit
[*PE2] commit
Step 3 Configure the basic MPLS functions on the backbone network.

# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[~P1] mpls lsr-id 2.2.2.9
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
Step 4 Configure segment routing on the backbone network.

# Configure PE1.

[*PE1-segment-routing] tunnel-prefer segment-routing
[*PE1] commit
[~PE1] isis 1
[*PE1-isis-1] segment-routing global-block 160000 161000
[*PE1-isis-1] quit
NOTE
The SRGB value range varies according to a live network and the range the set as required.
Here is an example only.
[*PE1] interface loopback 1
[*PE1-LoopBack1] isis prefix-sid index 10
[*PE1] commit
# Configure P1.
[~P1] segment-routing
[*P1-segment-routing] tunnel-prefer segment-routing
[*P1-segment-routing] quit
[*P1] commit
[~P1] isis 1
[~P1-isis-1] cost-style wide
[*P1-isis-1] segment-routing mpls
[*P1-isis-1] segment-routing global-block 161001 162000
[*P1-isis-1] quit
NOTE
[*P1] interface loopback 1
[*P1-LoopBack1] isis prefix-sid index 20
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
NOTE
[*PE2] commit
After completing the configuration, run the display segment-routing prefix mpls
forwarding command on PEs, and you can view that prefix label is in the Active
state. In the following example, the command output on PE1 is used.
[~PE1] display segment-routing prefix mpls forwarding
Segment Routing Prefix MPLS

Forwarding Information
--------------------------------------------------------------
Role : I-Ingress, T-Transit, E-Egress, I&T-Ingress And Transit
Prefix Label OutLabel Interface
NextHop Role MPLSMtu Mtu State
--------------------------------------------------------------------------------------------------------------
1.1.1.9/32 160010 NULL Loop1 127.0.0.1 E --- 1500 Active
2.2.2.9/32 160020 3 10GE1/0/1 172.1.1.2 I&T --- 1500 Active
3.3.3.9/32 160030 161031 10GE1/0/1 172.1.1.2 I&T --- 1500 Active
Total information(s): 3
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
tunnel-prefer segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
segment-routing global-block 160000 161000
#
interface 10GE1/0/1
undo portswitch
ip address 172.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
isis prefix-sid index 10
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
interface 10GE1/0/1
undo portswitch
ip address 172.1.1.2 255.255.255.0
isis enable 1
#

interface 10GE1/0/2
undo portswitch
ip address 172.2.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
interface 10GE1/0/1
undo portswitch
ip address 172.2.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
5.7.2.2 Example for Configuring L3VPN Services Iterated to an SR-MPLS BE

Tunnel
In Figure 5-28, CE1 and CE2 belong to vpna. L3VPN services are iterated to an SR-
MPLS BE tunnel to allow users within the same VPN to securely access each other.

Figure 5-28 L3VPN iterated to an SR-MPLS BE tunnel

SR Domain
AS: 100
Loopback1
2.2.2.9/32
10GE1/0/1
PE1 10GE1/0/1 172.2.1.2/24 PE2
172.1.1.1/24
Loopback1 Loopback1
1.1.1.9/32 3.3.3.9/32
10GE1/0/1 P1 10GE1/0/2
10GE1/0/2 10GE1/0/2
172.1.1.2/24 172.2.1.1/24
10.1.1.2/24 10.2.1.2/24
10GE1/0/1 10GE1/01
AS: 65410 10.1.1.1/24 AS: 65420
10.2.1.1/24
CE1 CE2
Loopback1 Loopback1
11.1.1.1/32 22.2.2.2/32
SR LSPs.
3. Enable Multi-protocol Extensions for Interior Border Gateway Protocol (MP-
IBGP) on PEs to exchange VPN routing information.
4. Configure VPN instances on the PEs and bind each interface that connects a
PE to a CE to a VPN instance.
5. Configure External Border Gateway Protocol (EBGP) on the CEs and PEs to
exchange VPN routing information.
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1-10GE1/0/1] ip address 172.1.1.1 24
[*PE1-10GE1/0/1] quit
[*PE1] commit
# Configure P1.

[*HUAWEI] commit
[*P1-10GE1/0/1] ip address 172.1.1.2 24
[*P1-10GE1/0/1] quit
[*P1-10GE1/0/2] ip address 172.2.1.1 24
[*P1-10GE1/0/2] quit
[*P1] commit
# Configure PE2.
[*HUAWEI] commit
[*PE2-10GE1/0/1] ip address 172.2.1.2 24
[*PE2-10GE1/0/1] quit
[*PE2] commit
Step 2 Configure an IGP protocol on the MPLS backbone network to implement

connectivity between the PEs and P1. IS-IS is used as an IGP protocol in this
example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*PE1-10GE1/0/1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1-10GE1/0/1] quit
[*P1-10GE1/0/2] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1


[*PE2-isis-1] quit
[*PE2] commit
[*PE2-10GE1/0/1] quit
[*PE2] commit
# Configure PE1.
[*PE1] mpls
[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit
# Configure PE1.
[*PE1] commit
[~PE1] isis 1
[*PE1-isis-1] quit
NOTE
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit

NOTE
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1
[*PE2-isis-1] quit
NOTE
[*PE2] commit
Segment Routing Prefix MPLS
Forwarding Information
--------------------------------------------------------------
Prefix Label OutLabel Interface
NextHop Role MPLSMtu Mtu State
--------------------------------------------------------------------------------------------------------------
2.2.2.9/32 160020 3 10GE1/0/1 172.1.1.2 I&T --- 1500 Active
3.3.3.9/32 160030 161031 10GE1/0/1 172.1.1.2 I&T --- 1500 Active
Step 5 Set up an MP-IBGP peer relationship between PEs.

# Configure PE1.
[~PE1] bgp 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] quit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] ipv4-family vpnv4
[*PE2-bgp-af-vpnv4] peer 1.1.1.9 enable

[*PE2-bgp-af-vpnv4] commit
[~PE2-bgp-af-vpnv4] quit
[~PE2-bgp] quit
After completing the configuration, run the display bgp peer or display bgp
vpnv4 all peer command on PEs, and you can view that a BGP peer relationship is
set up between PEs and the BGP peer relationship is in the Established state. In
the following example, the command output on PE1 is used.
[~PE1] display bgp peer
3.3.3.9 4 100 2 6 0 00:00:12 Established 0
[~PE1] display bgp vpnv4 all peer
3.3.3.9 4 100 12 18 0 00:09:38 Established 0
Step 6 Configure VPN instances in the IPv4 address family on each PE and connect each
PE to a CE.
# 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] quit
[*PE1-vpn-instance-vpna] quit
[*PE1-10GE1/0/2] ip binding vpn-instance vpna
[*PE1-10GE1/0/2] ip address 10.1.1.2 24
[*PE1-10GE1/0/2] quit
[*PE1] commit
# Configure PE2.
[~PE2] ip vpn-instance vpna
[*PE2-vpn-instance-vpna] ipv4-family
[*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] quit
[*PE2-vpn-instance-vpna] quit
[*PE2-10GE1/0/2] ip binding vpn-instance vpna
[*PE2-10GE1/0/2] ip address 10.2.1.2 24
[*PE2-10GE1/0/2] quit
[*PE2] commit
# Assign an IP address to each interface on CEs as shown in Figure 5-28. The

detailed configuration procedure is not provided here. For details, see
Configuration Files.
After the configuration, run the display ip vpn-instance verbose command on

PEs to view the configurations of VPN instances. Each PE can successfully ping its
connected CE.
Step 7 Set up EBGP peer relationships between PEs and CEs.

# Configure CE1. The configuration of CE2 is similar to the configuration of CE1,

and are not provided here. For details, see Configuration Files.
[~CE1] bgp 65410
[*CE1-bgp] peer 10.1.1.2 as-number 100
[*CE1-bgp] network 11.1.1.1 32
[*CE1-bgp] quit
[*CE1] commit
# Configure PE1. The configuration of PE2 is similar to the configuration of PE1,

and are not provided here. For details, see Configuration Files.
[~PE1] bgp 100
[*PE1-bgp] ipv4-family vpn-instance vpna
[*PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[*PE1-bgp-vpna] quit
[*PE1-bgp] quit
[*PE1] commit
After the configuration, run the display bgp vpnv4 vpn-instance peer command
on PEs, and you can view that BGP peer relationships between PEs and CEs have
been established and are in the Established state.
In the following example, the peer relationship between PE1 and CE1 is used.
[~PE1] display bgp vpnv4 vpn-instance vpna peer
VPN-Instance vpna, Router ID 1.1.1.9:

10.1.1.1 4 65410 11 9 0 00:06:37 Established 1

Run the display ip routing-table vpn-instance command on each PE to view the
routes to CEs' loopback interfaces.
In the following example, the command output on PE1 is used.
[~PE1] display ip routing-table vpn-instance vpna
Proto: Protocol Pre: Preference
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table: vpna
Destinations : 6 Routes : 6
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.1.0/24 Direct 0 0 D 10.1.1.2 10GE1/0/2

10.1.1.2/32 Direct 0 0 D 127.0.0.1 10GE1/0/2
10.1.1.255/32 Direct 0 0 D 127.0.0.1 10GE1/0/2
11.1.1.1/32 EBGP 255 0 RD 10.1.1.1 10GE1/0/2
22.2.2.2/32 IBGP 255 0 RD 3.3.3.9 10GE1/0/1
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
----End
Configuration Files
#
sysname PE1
#

ip vpn-instance vpna
ipv4-family
route-distinguisher 100:1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
interface 10GE1/0/1
undo portswitch
ip address 172.1.1.1 255.255.255.0
isis enable 1
#
interface 10GE1/0/2
undo portswitch
ip binding vpn-instance vpna
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpna
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
interface 10GE1/0/1

undo portswitch
ip address 172.1.1.2 255.255.255.0
isis enable 1
#
interface 10GE1/0/2
undo portswitch
ip address 172.2.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ip vpn-instance vpna
ipv4-family
route-distinguisher 200:1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
interface 10GE1/0/1
undo portswitch
ip address 172.2.1.2 255.255.255.0
isis enable 1
#
interface 10GE1/0/2
undo portswitch
ip binding vpn-instance vpna
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
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
#
return


#
sysname CE1
#
interface 10GE1/0/1
undo portswitch
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 11.1.1.1 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.1.1.1 255.255.255.255
#
return

#
sysname CE2
#
interface 10GE1/0/1
undo portswitch
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 22.2.2.2 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
network 22.2.2.2 255.255.255.255
#
return
5.7.2.3 Example for Configuring Non-Labeled Public BGP Routes to Be

Iterated to an SR-MPLS BE tunnel
If an Internet user uses a backbone network that performs IP forwarding to access
the Internet, core backbone network devices on the forwarding path need to learn
a large number of Internet routes. This imposes a heavy load on core backbone
network devices and affects the performance of these devices. To solve this
problem, you can enable access devices to iterate non-labeled public BGP routes
or non-labeled static routes to an SR tunnel so that users can access the Internet
through the SR tunnel. The iteration to the SR tunnel prevents the problems
induced by insufficient performance, heavy burdens, and service transmission on
the core devices on the backbone network.
In Figure 5-29, non-labeled public BGP routes are configured and iterated to an
SR-MPLS BE tunnel.

Figure 5-29 Non-labeled public BGP route iteration to an SR-MPLS BE tunnel

SR domain
AS: 100
User Loopback1 Loopback1 Loopback1
network 1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
10GE1/0/1 10GE1/0/2
172.1.1.2/24 172.2.1.2/24
10GE1/0/1 10GE1/0/1
User PE1 172.1.1.1/24 P1 172.2.1.1/24 PE2
network
BGP
SR LSPs.
3. Enable IBGP on PEs to exchange VPN routing information.
4. Enable PEs to iterate non-labeled public BGP routes to the SR-MPLS BE
tunnel.
Procedure
# Configure PE1.
[*HUAWEI] commit
[*PE1-10GE1/0/1] ip address 172.1.1.1 24
[*PE1-10GE1/0/1] quit
[*PE1] commit
# Configure P1.
[*HUAWEI] commit
[*P1-10GE1/0/1] ip address 172.1.1.2 24
[*P1-10GE1/0/1] quit
[*P1-10GE1/0/2] ip address 172.2.1.2 24
[*P1-10GE1/0/2] quit
[*P1] commit
# Configure PE2.

[*HUAWEI] commit
[*PE2-10GE1/0/1] ip address 172.2.1.1 24
[*PE2-10GE1/0/1] quit
[*PE2] commit
Step 2 Configure an IGP protocol on the backbone network to implement connectivity

between the PEs. IS-IS is used as an IGP protocol in this example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] quit
[*PE1] commit
[*PE1-10GE1/0/1] quit
[*PE1] commit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] quit
[*P1] commit
[*P1-10GE1/0/1] quit
[*P1-10GE1/0/2] quit
[*P1] commit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] quit
[*PE2] commit
[*PE2-10GE1/0/1] quit
[*PE2] commit
# Configure PE1.
[*PE1] mpls

[*PE1-mpls] commit
[~PE1-mpls] quit
# Configure P1.
[*P1] mpls
[*P1-mpls] commit
[~P1-mpls] quit
# Configure PE2.
[*PE2] mpls
[*PE2-mpls] commit
[~PE2-mpls] quit

# Configure PE1.
[*PE1] commit
[~PE1] isis 1
[*PE1-isis-1] quit
NOTE
[*PE1] commit
# Configure P1.
[*P1] commit
[~P1] isis 1
[*P1-isis-1] quit
NOTE
[*P1] commit
# Configure PE2.
[*PE2] commit
[~PE2] isis 1


[*PE2-isis-1] quit
NOTE
[*PE2] commit
Segment Routing Prefix MPLS Forwarding Information
--------------------------------------------------------------
Prefix Label OutLabel Interface NextHop Role MPLSMtu Mtu State
--------------------------------------------------------------------------------------------------------------
2.2.2.9/32 160020 3 10GE1/0/1 172.1.1.2 I&T --- 1500 Active
3.3.3.9/32 160030 161031 10GE1/0/1 172.1.1.2 I&T --- 1500 Active
Step 5 Establish an IBGP peer relationship between PEs.
# Configure PE1.
[~PE1] bgp 100
[*PE1-bgp] commit
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[*PE2-bgp] commit
[~PE2-bgp] quit
After completing the configuration, run the display bgp peer command on PEs,
and you can view that BGP peer relationships between PEs have been established
and are in the Established state. In the following example, the command output
on PE1 is used.
[~PE1] display bgp peer
Total number of peers : 1
3.3.3.9 4 100 2 6 0 00:00:12 Established 0
Step 6 Enable PEs to iterate non-labeled public BGP routes to the SR-MPLS BE tunnel.
# Configure PE1.

[~PE1] tunnel-policy p1
[*PE1-tunnel-policy-p1] tunnel select-seq sr-lsp load-balance-number 1
[*PE1-tunnel-policy-p1] quit
[*PE1] route recursive-lookup tunnel tunnel-policy p1
[*PE1] commit
# Configure PE2.
[~PE2] tunnel-policy p1
[*PE2-tunnel-policy-p1] tunnel select-seq sr-lsp load-balance-number 1
[*PE2-tunnel-policy-p1] quit
[*PE2] route recursive-lookup tunnel tunnel-policy p1
[*PE2] commit
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0001.00
#
interface 10GE1/0/1
undo portswitch
ip address 172.1.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
route recursive-lookup tunnel tunnel-policy p1
#
tunnel-policy p1
tunnel select-seq sr-lsp load-balance-number 1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#

segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0002.00
#
interface 10GE1/0/1
undo portswitch
ip address 172.1.1.2 255.255.255.0
isis enable 1
#
interface 10GE1/0/2
undo portswitch
ip address 172.2.1.2 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.9
#
mpls
#
segment-routing
#
isis 1
is-level level-1
cost-style wide
network-entity 10.0000.0000.0003.00
#
interface 10GE1/0/1
undo portswitch
ip address 172.2.1.1 255.255.255.0
isis enable 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
route recursive-lookup tunnel tunnel-policy p1
#
tunnel-policy p1
tunnel select-seq sr-lsp load-balance-number 1
#
return

01-05 Segment Routing Configuration

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01-05 Segment Routing Configuration

Uploaded by

Copyright:

Available Formats

CloudEngine 12800 Series Switches

Configuration Guide - MPLS 5 Segment Routing Configuration

5 Segment Routing Configuration

5.1 Overview of Segment Routing

5.1 Overview of Segment Routing

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 289

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 290

● Better smooth evolution to SDN networks.

5.2 Understanding Segment Routing

5.2.1 Segment Routing Implementation

Table 5-1 Segment category

Label Generation Function

Prefix Manually A prefix segment identifies the prefix of a

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 291

Label Generation Function

Adjacency Allocated by An adjacency segment identifies an adjacency on a

Figure 5-1 Adjacency SIDs, prefix SIDs, and node SIDs

Adjacency SID: 1001, 1002, 1003

In simple words, a prefix segment indicates a destination address, and an

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 292

Figure 5-2 Prefix segment-based forwarding path

Figure 5-3 Adjacency segment-based forwarding path

Adjacency Segment + Node Segment

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 293

Figure 5-4 Adjacency segment + node segment-based forwarding path

Label Conflicts and Handling Rules

The process of handling the label conflicts is as follows:

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 294

● Devices report topology information to a controller (if the controller is used to

Figure 5-5 Prefix label-based LSP creation

1 Distribute Prefix SID and SRGB

2 3 4 Compute Label and OuterLabel

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 295

Table 5-2 Process of creating an LSP

1 D An SRGB is configured on D and a prefix SID is configured on the

2 C C parses the prefix SID released by D and computes a label value

3 B The calculation process is similar to C:

4 A The calculation process is similar to C:

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 296

● Pop: After the packets leave an SR domain, a node finds an outbound

Figure 5-6 Prefix label-based data forwarding

Push Swap Swap Pop

26100 36100 16100

Table 5-3 Packet forwarding process

1 A Receives a data packet, adds label 26100 to the packet, and

4 D Removes label 16100 and forwards the packet along a matching

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 297

networking (SDN). SR-MPLS TE outperforms RSVP-TE in this situation. Table 5-4

Table 5-4 Comparison between SR-MPLS TE and RSVP-TE

Item SR-MPLS TE RSVP-TE

Control SR, which is an extension to IGP, RSVP-TE is used as the control

Label Each link is distributed only a A label is distributed to each LSP.

Path An intermediate device does not Configurations must be delivered

Stitching Label and Stitching Node

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 298

5.2.3.1 Label Distribution

Figure 5-7 IS-IS-based label distribution

IS-IS SR is enabled on PE1, PE2, and P1 through P4 to establish IS-IS neighbor

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 299

Distributed by the controller

Figure 5-8 Controller-based label distribution

Issue 09 (2021-06-03) Copyright © Huawei Technologies Co., Ltd. 300

5.2.3.2 SR-MPLS TE Tunnel Establishment

Figure 5-9 SR-MPLS TE tunnel