· Color—Color attribute for the forwarding path. You can use the color attribute to distinguish an SR-MPLS TE policy from other SR-MPLS TE policies that are configured for the same source and destination nodes.

· End point—IPv4 or IPv6 address of the destination node.

Candidate path

A candidate path is a forwarding path that an SR-MPLS TE policy can use to forward packets.

An SR-MPLS TE policy can have multiple candidate paths. Two SR-MPLS TE policies cannot share the same candidate path.

Preference

Candidate paths are uniquely identified by their preference values. An SR-MPLS TE policy chooses a candidate path from all its candidate paths based on the preference values.

Segment list

A segment list is a list of SIDs that indicates a packet forwarding subpath. Each SID identifies the segment for forwarding packets to the next hop along the subpath.

A segment list is also call a SID list.

A candidate path can have a single SID list or multiple SID lists that use different weight values.

Weight

A SID list can have a weight value. After an SR-MPLS TE policy chooses a candidate path with multiple SID lists, the traffic will be load shared among the subpaths based on weight values.

SR-MPLS TE policy tunnel

An SR-MPLS TE policy tunnel is a virtual point-to-point connection between the node deployed with the SR-MPLS TE policy and the destination node of the SR-MPLS TE policy. The tunnel is automatically created upon SR-MPLS TE policy creation. SR-MPLS TE policy tunnels use SRLSPs.

SR-MPLS TE policy group

An SR-MPLS TE policy group is a collection of SR-MPLS TE policies. You can add SR-MPLS TE policies to an SR-MPLS TE policy group to implement SR-MPLS TE policy based forwarding according to DSCP values of packets.

SR-MPLS TE policy creation

An SR-MPLS TE policy can be created in the following modes:

· Manual configuration from CLI

In this mode, you manually configure the candidate settings for the SR-MPLS TE policy, such as candidate path preferences, SID lists, and weights.

· Learning from a BGP IPv4 SR policy route

To support SR-MPLS TE policy, MP-BGP defines the BGP IPv4 SR policy address family and the Network Layer Reachability Information (NLRI), that is, BGP IPv4 SR policy route information. A BGP IPv4 SR policy route contains SR-MPLS TE policy settings, including the BSID, color, endpoint, candidate preferences, SID lists, and SID list weights.

The device can advertise its local SR-MPLS TE policy settings to its BGP IPv4 SR policy peer through a BGP IPv4 SR policy route. The peer device can create an SR-MPLS TE policy according to the received SR-MPLS TE policy settings.

· Automatic creation by ODN

When the device receives a BGP route, it compares the color extended attribute value of the BGP route with the color value of the ODN template. If the color values match, the device automatically generates an SR-MPLS TE policy and two candidate paths for the policy.

¡ The policy uses the BGP route's next hop address as the end-point address and the ODN template's color value as the color attribute value of the policy.

¡ The candidate paths use preferences 100 and 200. You must configure the SID lists for the candidate path with preference 200 through dynamic calculation based on affinity attribute or Flex-Algo, and use PCE to compute the SID lists for the candidate path with preference 100. For more information about SID list computation using PCE, see "SID list creation through dynamic path calculation."

You can also manually create candidate paths for an ODN-created SR-MPLS TE policy.

SID list creation through dynamic path calculation

SID list creation through dynamic path calculation is supported on the source node of manually created SR-MPLS TE policies and automatically generated SR-MPLS TE policies through ODN.

The dynamic path calculation is performed based on affinity attribute or Flex-Algo.

Dynamic path calculation based on affinity attribute

An SR-MPLS TE policy performs dynamic path calculation based on affinity attribute as follows:

1. Select the links based on the affinity attribute rule.

The SR-MPLS TE policy selects links containing the bit values associated with the specified affinity attribute as required by the affinity attribute rule.

¡ Link attribute—A 32-bit binary number. Each bit represents an attribute with a value of 0 or 1.

¡ Affinity attribute bit position—The value range is 0 to 32. When the affinity attribute value is N, it is compared with the N+1 bit of the link attribute. The affinity attribute applies to the link only if the N+1 bit value of the link attribute is 1.

For example, for affinity attribute name blue associated with bit 1 and affinity attribute name red associated with bit 5, the link selection varies by affinity attribute rule type:

¡ For the include-any affinity attribute rule, a link is available for use if the link attribute has the second bit (associated with affinity attribute blue) or sixth bit (associated with affinity attribute red) set to 1.

¡ For the include-all affinity attribute rule, a link is available for use if the link attribute has both the second bit (associated with affinity attribute blue) and sixth bit (associated with affinity attribute red) set to 1.

¡ For the exclude-any affinity attribute rule, a link is not available for use if the link attribute has the second bit (associated with affinity attribute blue) or sixth bit (associated with affinity attribute red) set to 1.

2. Select the links based on the specified metric.

The SR-MPLS TE policy supports the following metrics:

¡ Hop count—Selects the link with minimum hops.

¡ IGP link cost—Selects the link with minimum IGP link cost.

¡ Lowest interface latency—Selects the link with the lowest interface latency.

¡ TE cost—Selects the link with minimum TE cost.

After path calculation, the device sorts all link- or node-associated SIDs on the path in an ascending order of distance, and creates an SID list for the SR-MPLS TE policy. During SID selection, prefix SIDs take precedence over adjacency SIDs.

Dynamic path calculation based on Flex-Algo

The SR-MPLS TE policy uses the specified Flex-Algo to perform dynamic path calculation. After path calculation, the device sorts all link- or node-associated SIDs on the path in an ascending order of distance, and creates an SID list for the SR-MPLS TE policy. During SID selection, prefix SIDs take precedence over adjacency SIDs.

For more information about path calculation based on Flex-Algo, see IS-IS configuration in Layer 3—IP Routing Configuration Guide.

SID list computation using PCE

On an SR-MPLS TE policy network, an SR node can act as a Path Computation Client (PCC) to use the paths computed by the Path Computation Element (PCE) to create SID lists for a candidate path.

Basic concepts

· PCE—An entity that provides path computation for network devices. It can provide intra-area path computation as well as complete SID list computation on a complicated network. A PCE can be stateless or stateful.

¡ Stateless PCE—Provides only path computation.

¡ Stateful PCE—Knows all path information maintained by a PCC, and performs intra-area path recomputation and optimization to make full use of the network resources. A stateful PCE can be active or passive.

- Active stateful PCE—Maintains the SID lists of a PCC, optimizes the paths in real time according to the network situation, and notifies the PCC to update path information.

- Passive stateful PCE—Only maintains the SID lists of a PCC. A passive stateful PCE does not optimize the paths or notify the PCC to update paths.

· PCC—A PCC sends a request to a PCE for path computation and uses the path information returned by the PCE to establish forwarding paths. For a PCC to establish a PCEP session with a PCE, the PCC and PCE must be of the same type.

¡ Stateless PCC—Sends path computation requests to a PCE.

¡ Stateful PCC—Delegates SID list information to a stateful PCE. A stateful PCE can be active or passive.

- Active stateful PCC—Reports its SID list information to a PCE, and uses the paths computed by the PCE to create and update the SID lists.

- Passive stateful PCC—Only reports its SID list information to a PCE but does not use the PCE to compute or update path information for the SID lists.

· PCEP—Path Computation Element Protocol. PCEP runs between a PCC and a PCE, or between PCEs. It is used to establish PCEP sessions to exchange PCEP messages over TCP connections.

PCE path computation

As shown in Figure 1, the PCE path computation procedure is as follows:

1. The PCC sends a path computation request to the PCE.

2. The PCE computes paths after it receives the request.

3. The PCE replies the PCC with the computed path information.

4. The PCC creates SID lists for the SR-MPLS TE policy candidate path according to the path information computed by the PCE.

Figure 1 Path computation using PCE

‌

SR-MPLS TE policy validity

The following describes the rules for identifying the validity of a SR-MPLS TE policy:

1. An SR-MPLS TE policy is valid only if it has valid candidate paths.

2. A candidate path is valid only if it has a valid SID list.

3. A SID list is valid if none of the following situations exists:

¡ The SID list is empty.

¡ The weight of the SID list is 0.

¡ An SR node cannot find the outgoing interface or next hop address based on the SID at the top of the SID list stack.

SR-MPLS TE policy routing procedure

The following describes how the device chooses and uses an SR-MPLS TE policy to route a packet:

1. Upon receiving a packet whose stack top label is a BSID, the device identifies the valid SR-MPLS TE policies based on the BSID.

2. If multiple valid SR-MPLS TE policies are available, the device chooses the SR-MPLS TE policy that was first bound to the BSID.

3. If the chosen SR-MPLS TE policy has multiple candidate paths, the device chooses the candidate path with the greatest preference value.

4. If the chosen candidate path has multiple SID lists, the traffic will be load shared based on the weight values among the subpaths identified by the SID lists. The load of SID list x is equal to Weight x/(Weight 1 + Weight 2 + … + Weight n).

For example, Device A in Figure 2 first chooses a valid SR-MPLS TE policy by BSID. Then, the device chooses a candidate path by preference. The candidate path has two valid SID lists: SID list 1 and SID list 2. The weight value of SID list 1 is 20 and the weight value of SID list 2 is 80. One fifth of the traffic will be forwarded through the subpath identified by SID list 1. Four fifth of the traffic will be forwarded through the subpath identified by SID list 2.

Figure 2 SR-MPLS TE policy routing diagram

SR-MPLS TE policy forwarding procedure

As shown in Figure 3, the SR-MPLS TE policy forwarding procedure is as follows:

1. After Device A receives a packet with the stack top label 16001, it searches its LFIB and determines that the label is a BSID. Then, Device A obtains the outgoing label stack and next hop (Device B), pops the BSID, pushes SID list {20002, 21003, 22004}, and forwards the packet to Device B. 20002 is the SID of the segment for a packet to travel from Device A to Device B. 21003 is the SID of the segment for a packet to travel from Device B to Device C. 22004 is the SID of the segment for a packet to travel from Device C to Device D.

2. After Device B receives the packet, it searches its LFIB by the incoming label and determines that the next hop is Device C. Then, Device B forwards the packet to Device C.

3. After Device C receives the packet, it searches its LFIB by the incoming label and determines that the next hop is Device D. Then, Device C forwards the packet to Device D.

4. After Device D receives the packet, it identifies whether the packet is carrying a label. If yes, Device D searches its LFIB to forward the packet. If not, Device D searches its IP FIB to forward the packet.

Figure 3 SR-MPLS TE policy forwarding diagram

Traffic steering to an SR-MPLS TE policy

You can steer traffic to an SR-MPLS TE policy for further forwarding based on the following criteria:

· BSID—Upon receiving a packet whose stack top label is a BSID, the device chooses an SR-MPLS TE policy based on the BSID to forward the packet.

· Color—The device searches for an SR-MPLS TE policy with the color value and end point that are the same as the color extended community attribute and next hop of a BGP route. If an SR-MPLS TE policy is found, route recursion is performed for the BGP route. Packets matching the BGP route will be steered to the SR-MPLS TE policy for further forwarding.

· Tunnel policy—In an MPLS L3VPN or EVPN L3VPN, use a tunnel policy to specify the paths of an SR-MPLS TE policy as preferred tunnels or tunnels for load sharing. This allows the paths to be used as public network tunnels to carry VPN packets. For more information about tunnel policies, see MPLS Configuration Guide.

· DSCP value—Create color-to-DSCP mappings for an SR-MPLS TE policy group, and create a tunnel policy that binds a destination IP address to the SR-MPLS TE policy group. Upon receiving a packet with the specified destination IP address, the device searches for the SR-MPLS TE policy containing the color value mapped to the DSCP value of the packet. The device will use the SR-MPLS TE policy to forward the packet.

· Static route—Associate a static route with an SR-MPLS TE policy so that packets matching the static route will be steered to the SR-MPLS TE policy for forwarding.

· Flowspec—Redirect traffic to an SR-MPLS TE policy through a Flowspec rule. The device uses the SR-MPLS TE policy to forward the packets that match the Flowspec rule. For more information about Flowspec, see ACL and QoS Configuration Guide.

SR-MPLS TE policy CBTS

About SR-MPLS TE policy CBTS

SR-MPLS TE policy Class Based Tunnel Selection (CBTS) enables dynamic routing and forwarding of traffic with service class values over different SR-MPLS TE policy tunnels between the same tunnel headend and tailend. CBTS uses a dedicated tunnel for a certain class of service to implement differentiated forwarding for services.

How SR-MPLS TE policy CBTS works

SR-MPLS TE policy CBTS processes traffic mapped to a priority as follows:

1. Uses a traffic behavior to set a service class value for the traffic. For more information about setting a service class value in traffic behavior view, see the remark service-class command in ACL and QoS Command Reference.

2. Compares the service class value of the traffic with the service class values of the SR-MPLS TE policy tunnels and forwards the traffic to a matching tunnel.

SR-MPLS TE policy tunnel selection rules

SR-MPLS TE policy CBTS uses the following rules to select an SR-MPLS TE policy tunnel for the traffic to be forwarded:

· If an SR-MPLS TE policy tunnel has the same service class value as the traffic, CBTS uses this tunnel.

· If multiple SR-MPLS TE policy tunnels have the same service class value as the traffic, CBTS selects a tunnel based on the flow forwarding mode:

¡ If only one flow exists and flow-based forwarding is set, CBTS randomly selects a matching tunnel for packets of the same flow.

¡ If multiple flows exist or if only one flow exists but packet-based forwarding is set, CBTS uses all matching tunnels to load share the packets.

For more information about the flow identification and load sharing mode, see the ip load-sharing mode command in Layer 3—IP Services Command Reference.

· If the traffic does not match any SR-MPLS TE policy tunnels by service class value, CBTS randomly selects a tunnel from all SR-MPLS TE policy tunnels with the lowest forwarding priority. An SR-MPLS TE policy that has a smaller service class value has a lower forwarding priority. An SR-MPLS TE policy that is not configured with a service class value has the lowest priority.

SR-MPLS TE policy CBTS application scenario

As shown in Figure 4, CBTS selects SR-MPLS TE policy tunnels for traffic from Device A to Device B as follows:

· Uses SR-MPLS TE policy B to forward traffic with service class value 3.

· Uses SR-MPLS TE policy C to forward traffic with service class value 6.

· Uses SR-MPLS TE policy A to forward traffic with service class value 4.

· Uses SR-MPLS TE policy A to forward traffic with no service class value.

Figure 4 SR-MPLS TE policy CBTS application scenario

‌

SR-MPLS TE policy association with BFD

Echo BFD for SR-MPLS TE policy

Echo BFD establishes a BFD session for each SID list in the primary candidate path and backup candidate path (if any) of an SR-MPLS TE policy to detect availability of the corresponding forwarding paths. When BFD detects that all the SID lists of the primary candidate path are invalid, it notifies the SR-MPLS TE policy to switch traffic to the backup candidate path. If the backup candidate path does not exist, the device does not forward traffic through the SR-MPLS TE policy any longer.

As shown in Figure 5, configure an SR-MPLS TE policy on Device A and use echo BFD to detect the SR-MPLS TE policy. The detection process is as follows:

1. The source node (Device A) and sends BFD echo packets that each encapsulate a SID list of the primary and backup candidate paths of the SR-MPLS TE policy.

2. After the end-point node (Device D) receives a BFD echo packet, it sends the BFD echo packet back to the source node by using the IP routing table.

3. If the source node can receive the BFD echo packet within the detection timeout time, it determines the corresponding SID list (forwarding path) of the SR-MPLS TE policy is available. If no BFD echo packet is received, the device determines that the SID list is faulty. If all the SID lists for the primary path are faulty, BFD triggers a primary-to-backup path switchover.

Figure 5 Echo BFD for SR-MPLS TE policy procedure

‌

SBFD for SR-MPLS TE policy

Typically, SR-MPLS TE policies use SBFD to maintain policy state and detect path failures. By default, SBFD detects the SID lists for only the candidate path of the highest preference in an SR-MPLS TE policy.

Figure 6 SR-MPLS TE policy association with SBFD

‌

As shown in Figure 6, the SR-MPLS TE policy is associated with SBFD on source node Device A. The end point IP address is specified as the remote discriminator of the SBFD session. If the candidate path of the highest preference in the SR-MPLS TE policy has multiple SID lists, multiple SBFD sessions are established to detect the forwarding path for each SID list. All SBFD sessions use the same remote discriminator.

The SR-MPLS TE policy uses SBFD to detect the forwarding paths as follows:

1. The source node (Device A) sends an SBFD packet that encapsulates the target SID lists of the SR-MPLS TE policy.

2. Upon receiving the SBFD packet, the destination node (Device E) sends a response along the shortest path obtained through routing table lookup.

3. Upon receiving the SBFD response, Device A determines that the forwarding path for the SID list is available. If no response is received, Device A determines that the forwarding path is faulty. If all SID lists for the current candidate path are faulty, another candidate path takes over.

NOTE:

Because SBFD responses are forwarded according to the IP routing table lookup, all SBFD sessions for the SR-MPLS TE policies that have the same source and destination nodes use the same path to send responses. A failure of the SBFD response path will cause all the SBFD sessions to be down and consequentially packets cannot be forwarded through the SR-MPLS TE policies.

‌

SR-MPLS TE policy hot standby

If an SR-MPLS TE policy has multiple valid candidate paths, the device chooses the candidate path with the greatest preference value. If the chosen path fails, the SR-MPLS TE policy must select another candidate path. During path reselection, packet loss might occur to affect service continuity.

The SR-TE hot standby feature can address this issue. This feature takes the candidate path with the greatest preference value as the primary path and that with the second greatest preference value as the standby path. As shown in Figure 7, when the forwarding paths corresponding to all SID lists of the primary path fails, the standby path immediately takes over to minimize service interruption.

Figure 7 SR-MPLS TE policy hot standby

‌

You can configure both the hot standby and SBFD features for an SR-MPLS TE policy. Use SBFD to detect the availability of the primary and standby paths specified for hot standby. If all SID lists of the primary path become unavailable, the standby path takes over and a path recalculation is performed. The standby path becomes the new primary path, and a new standby path is selected. If both the primary and standby paths fail, the SR-MPLS TE policy will calculate new primary and standby paths.

MP-BGP extension for SR-MPLS TE policy-based routing

To support SR-MPLS TE policies, MP-BGP increases the following definitions:

· BGP IPv4 SR-MPLS TE policy address family.

· BGP IPv4 SR policy routes, which are also called SR-MPLS TE policy NLRI.

BGP IPv4 SR policy route information carries SR-MPLS TE policy settings, including the BSIDs, color values, end points, preference values, and weight values. After the device advertises BGP IPv4 SR policy routes to a peer, the peer can also use SR-MPLS TE policies to steer traffic.

The device supports the color extended community attribute. Upon receiving a packet that matches a route with the color extended community attribute, the device searches for an SR-MPLS TE policy that has the same color value as the route. If an SR-MPLS TE policy is found, the device forwards the packet based on the SR-MPLS TE policy. If not, the device uses the optimal route to forward the packet.

The color extended community attribute is in the format of 2-bit Color-Only flag:32-bit user-defined color value, for example, 10:3.

SR-MPLS TE policy configuration tasks at a glance

To configure an SR-MPLS TE policy, perform the following tasks:

1. Create an SR-MPLS TE policy and configure the settings:

a. Creating an SR-MPLS TE policy

b. Configuring a PCEP session

This task is required when you use PCE to compute SID lists.

c. Configuring a candidate path to use manually configured SID lists

d. (Optional.) Enabling strict SID encapsulation for SID lists

e. (Optional.) Configuring dynamic path calculation timers

f. (Optional.) Enabling the device to distribute SR-MPLS TE policy path information to BGP-LS

g. (Optional.) Shutting down an SR-MPLS TE policy

2. (Optional.) Configuring BGP to advertise BGP IPv4 SR policy routes

a. Enabling BGP to advertise BGP IPv4 SR policy routes

b. Configuring BGP to redistribute routes from the SR-MPLS TE policy

c. (Optional.) Advertising BGP IPv4 SR policy routes to EBGP peers

d. (Optional.) Filtering BGP IPv4 SR policy routes by router ID

e. (Optional.) Configuring BGP to control BGP IPv4 SR policy route selection and advertisement

f. (Optional.) Maintaining BGP sessions

3. (Optional.) Steering traffic to an SR-MPLS TE policy

4. Configure high availability features for SR-MPLS TE policies

¡ Enabling SBFD for SR-MPLS TE policies

¡ Configuring the BFD echo packet mode for SR-MPLS TE policies

¡ Enabling hot standby for SR-MPLS TE policies

¡ Configuring path switchover and deletion delays for SR-MPLS TE policies

¡ Setting the delay time for bringing up SR-MPLS TE policies

¡ Configuring candidate path reoptimization for SR-MPLS TE policies

5. (Optional.) Configuring SR-MPLS TE policy CBTS

6. (Optional.) Configuring traffic forwarding statistics for SR-MPLS TE policies

7. (Optional.) Enabling SR-MPLS TE policy logging

Creating an SR-MPLS TE policy

Manually creating an SR-MPLS TE policy and configuring its attributes

About this task

An SR-MPLS TE policy is identified by the following items: BSID, color, and end point. Upon receiving a packet whose stack top label is a BSID, the device chooses an SR-MPLS TE policy based on the BSID to forward the packet.

You can bind a BSID to the policy manually, or set only the color and end point attributes of the policy so the system automatically assigns a BSID to the policy. If you use both methods, the manually bound BSID takes effect.

Restrictions and guidelines

If you configure an MPLS label as the BSID but the label is not in the range of the SRGB or SRLB or is already used by a protocol, the configuration does not take effect. For more information about SRGB or SRLB, see "Configuring MPLS SR."

Each SR-MPLS TE policy must have a unique color value and end-point address.

An SR-MPLS TE policy and an SRv6 TE policy cannot have the same color value, end-point IPv6 address, and candidate path preferences.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter the SR TE view.

traffic-engineering

4. Create an SR-MPLS TE policy and enter its view.

policy policy-name

5. (Optional.) Configure a BSID for the policy.

binding-sid mpls mpls-label

6. Set the color and endpoint attributes.

color color-value end-point { ipv4 ipv4-address | ipv6 ipv6-address }

By default, the color and endpoint attributes of an SR-MPLS TE policy are not configured.

Automatically creating SR-MPLS TE policies by using ODN

About this task

When the device receives a BGP route, if the color extended attribute value of the BGP route is the same as the color value of an ODN template, the device automatically creates an SR-MPLS TE policy and two candidate paths for the policy. The automatically created candidate paths use preferences 100 and 200.

You can specify an IP prefix list to filter BGP routes. The BGP routes permitted by the specified IP prefix list can trigger ODN to create SR-MPLS TE policies. The BGP routes denied by the specified IP prefix list cannot trigger ODN to create SR-MPLS TE policies.

An ODN-created SR-MPLS TE policy is deleted immediately when the matching BGP route is deleted. To avoid packet loss before the new forwarding path is computed, you can configure a proper deletion delay time for the SR-MPLS TE policy.

Restrictions and guidelines

You must configure candidate paths for an ODN-created SR-MPLS TE policy.

· For the ODN-created candidate path preference 200, configure the SID lists for the candidate path by using the dynamically calculated paths.

· For the ODN-created candidate path preference 100, use PCE to compute the SID lists for the candidate path. This method is not supported in the current software version.

· Manually create candidate paths that use preferences other than 100 and 200, and then configure the SID lists for the candidate paths.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Create an ODN template and enter SR-TE-ODN view.

on-demand color color-value

5. (Optional.) Configure the ODN SR-MPLS TE policy generation policy.

restrict prefix-list-name

By default, a BGP route can trigger ODN to create an SR-MPLS TE policy when the route's color attribute value is the same as the ODN color.

6. (Optional.) Configure the deletion delay time for ODN-created SR-MPLS TE policies.

delete-delay delay-time

By default, the deletion delay time for ODN-created SR-MPLS TE policies is 180000 milliseconds.

Configuring a PCEP session

Restrictions and guidelines

For more information about the PCEP commands, see MPLS TE commands in MPLS Command Reference.

Discovering PCEs

About this task

You can manually specify a PCE by using the pce static command on a PCC. A PCC sends PCEP connection requests to the discovered PCEs but does not accept requests from the PCEs.

Procedure

1. Enter system view.

system-view

2. Enter PCC view.

pce-client

3. Specify the IP address of the PCE.

pce static ip-address

Enabling the SR capability for a PCC

About this task

To establish a PCEP session that supports SR, you must enable the SR capability on the devices at both sides of the PCEP session.

Procedure

1. Enter system view.

system-view

2. Enter PCC view.

pce-client

3. Enable the SR capability for the PCC device.

pce capability segment-routing

By default, a PCC device does not have the SR capability.

Configuring PCEP session parameters

About this task

This task allows you to configure parameters for a PCC to establish PCEP sessions to manually specified PCEs.

Procedure

1. Enter system view.

system-view

2. Enter PCC view.

pce-client

3. Set the path computation request timeout time.

pce request-timeout value

By default, the request timeout time is 10 seconds.

4. Set the PCEP session dead timer.

pce deadtimer value

By default, the PCEP session deadtimer is 120 seconds.

5. Set the keepalive interval for PCEP sessions.

pce keepalive interval

By default, the keepalive interval is 30 seconds.

6. Set the minimum acceptable keepalive interval and the maximum number of allowed unknown messages received from the PCE peer.

pce tolerance { min-keepalive value | max-unknown-messages value }

By default, the minimum acceptable keepalive interval is 10 seconds, and the maximum number of allowed unknown messages in a minute is 5.

7. Configure PCEP session authentication for a peer. Choose one option as needed:

¡ Configure the keychain authentication.

pce peer ip-address keychain keychain-name

¡ Configure the MD5 authentication.

pce peer ip-address md5 { cipher | plain } string

By default, PCEP session authentication is not configured.

For two devices to establish a PCEP session, you must configure the same authentication mode and specify the same key string on both devices.

Configuring a candidate path and a SID list for the path

Restrictions and guidelines

Do not configure an SR-MPLS TE policy candidate path to use both manually configured SID lists and PCE-computed SID lists.

The Flex-Algo-based dynamic path calculation takes precedence over the affinity attribute-based dynamic path calculation for an SR-MPLS TE policy.

Configuring a candidate path to use manually configured SID lists

About this task

After you add nodes to a SID list, the system will sort the nodes in ascending order of node index.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Create a SID list and enter its view.

segment-list segment-list-name

5. Add a node to the SID list.

index index-number mpls label label-value

6. Return to system view.

quit

7. Enter SR-MPLS TE policy view.

policy policy-name

8. Create and enter SR-MPLS TE policy candidate path view.

candidate-paths

9. Set the preference for a candidate path and enter candidate path preference view.

preference preference-value

By default, no candidate path preferences are set.

Each preference represents a candidate path.

10. Specify an explicit path for the candidate path.

explicit segment-list segment-list-name [ weight weight-value ]

A candidate path can have multiple SID lists.

Configuring a candidate path to create an SID list through affinity attribute-based path calculation

Creating a name-to-bit mapping for an affinity attribute

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Create the constraints mapping and enter its view.

affinity-map

5. Create a name-to-bit mapping for an affinity attribute.

name name bit-position bit-position-number

By default, no name-to-bit mapping is configured for an affinity attribute.

Configuring affinity attribute rules

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-MPLS TE policy view.

policy policy-name

5. Enter SR-MPLS TE policy candidate path view.

candidate-paths

6. Enter SR-MPLS TE policy candidate path preference view.

preference preference-value

Each preference represents a candidate path.

7. Create SR-MPLS TE policy constraints and enter constraints view.

constraints

8. Create and enter the affinity attribute view.

affinity

9. Configure affinity attribute rules.

¡ Configure the include-all affinity attribute rule and enter its view.

include-all

¡ Configure the include-any affinity attribute rule and enter its view.

include-any

¡ Configure the exclude-any affinity attribute rule and enter its view.

exclude-any

10. Specify an affinity attribute for an affinity attribute rule.

name name

By default, no affinity attribute is specified for an affinity attribute rule.

Configuring dynamic path calculation based on affinity attribute rule

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-MPLS TE policy view.

policy policy-name

5. Enter SR-MPLS TE policy candidate path view.

candidate-paths

6. Enter SR-MPLS TE policy candidate path preference view.

preference preference-value

Each preference represents a candidate path.

7. Enable dynamic path calculation and create and enter SR-MPLS TE policy path preference dynamic view.

dynamic

By default, dynamic path calculation is disabled.

8. Create a metric type and enter its view.

metric

9. Specify a metric.

type { hopcount | igp | latency | te }

By default, no metric is specified. The SR-MPLS TE policy cannot perform dynamic path calculation.

10. (Optional.) Configure the maximum number of SIDs in an SID list.

sid-limit limit-value

By default, the number of SIDs in an SID list is not limited.

This command limits the number of SIDs in the SID lists for the candidate paths of an SR-MPLS TE policy during metric-based path calculation.

Configuring a candidate path to create an SID list through Flex-Algo-based path calculation

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-MPLS TE policy view.

policy policy-name

5. Enter SR-MPLS TE policy candidate path view.

candidate-paths

6. Enter SR-MPLS TE policy candidate path preference view.

preference preference-value

Each preference represents a candidate path.

7. Enable dynamic path calculation and create and enter SR-MPLS TE policy path preference dynamic view.

dynamic

By default, dynamic path calculation is disabled.

8. Return to SR-MPLS TE policy candidate path preference view.

quit

9. Create SR-MPLS TE policy constraints and enter constraints view.

constraints

10. Create the segment constraints and enter its view.

segments

11. Specify a Flex-Algo for an SR-MPLS TE policy.

sid-algorithm algorithm-id

By default, no Flex-Algo is associated with an SR-MPLS TE policy.

Configuring a candidate path to use PCE-computed SID lists

Prerequisites

Before you perform this task, configure a PCEP session first.

Procedure

1. Enter system view.

system-view

2. Enter SR view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-MPLS TE policy view.

policy policy-name

5. Create and enter SR-MPLS TE policy candidate path view.

candidate-paths

6. Set the preference for a candidate path and enter SR-MPLS TE policy path preference view.

preference preference-value

By default, no candidate path preferences are set.

Each preference represents a candidate path.

7. Create and enter SR-MPLS TE policy path preference dynamic view.

dynamic

8. Enable a candidate path to use PCE to compute the SID lists.

pcep

By default, a candidate path does not use PCE to compute SID lists.

Configuring an ODN-created candidate path to create an SID list through affinity attribute-based path calculation

Creating a name-to-bit mapping for an affinity attribute

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Create the constraints mapping and enter its view.

affinity-map

5. Create a name-to-bit mapping for an affinity attribute.

name name bit-position bit-position-number

By default, no name-to-bit mapping is configured for an affinity attribute.

Configuring affinity attribute rules

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-TE-ODN view.

on-demand color color-value

5. Enable dynamic path calculation and create and enter SR-TE-ODN dynamic view.

dynamic

By default, dynamic path calculation is disabled.

6. Create the affinity attribute rule and enter its view.

affinity { include-all | include-any | exclude-any }

7. Specify an affinity attribute for an affinity attribute rule.

name name

By default, no affinity attribute is specified for an affinity attribute rule.

Configuring dynamic path calculation based on affinity attribute rule

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-TE-ODN view.

on-demand color color-value

5. (Optional.) Configure the maximum depth for the SID label stack.

maximum-sid-depth value

By default, no maximum depth is set for the SID label stack.

To implement dynamic path calculation for ODN-generated SR-MPLS TE policies, use this command to control the number of SIDs in the SID lists for the candidate paths of the SR-MPLS TE policies.

6. Enable dynamic path calculation and create and enter SR-TE-ODN dynamic view.

dynamic

By default, dynamic path calculation is disabled.

7. Create a metric type and enter its view.

metric

8. Specify a metric.

type { hopcount | igp | latency | te }

By default, no metric is specified. The SR-MPLS TE policy cannot perform dynamic path calculation.

Configuring an ODN-created candidate path to create an SID list through Flex-Algo-based path calculation

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-TE-ODN view.

on-demand color color-value

5. (Optional.) Configure the maximum depth for the SID label stack.

maximum-sid-depth value

By default, no maximum depth is set for the SID label stack.

To implement dynamic path calculation for ODN-generated SR-MPLS TE policies, use this command to control the number of SIDs in the SID lists for the candidate paths of the SR-MPLS TE policies.

6. Enable dynamic path calculation and create and enter SR-TE-ODN dynamic view.

dynamic

By default, dynamic path calculation is disabled.

7. Specify a Flex-Algo for an SR-MPLS TE policy.

sid-algorithm algorithm-id

By default, no Flex-Algo is associated with an SR-MPLS TE policy.

Configuring an ODN-created candidate path to use PCE-computed SID lists

Prerequisites

Before you perform this task, configure a PCEP session first.

Procedure

1. Enter system view.

system-view

2. Enter SR view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-TE-ODN view.

on-demand color color-value

5. Enter SR-TE-ODN dynamic view.

dynamic

6. Enable a candidate path to use PCE to compute the SID lists.

pcep

By default, a candidate path does not use PCE to compute SID lists.

Configuring PCE delegation to create candidate paths and SID lists

About this task

After PCE delegation for an SR-MPLS TE policy is enabled, the PCC delegates the policy's candidate paths to a PCE. The PCC creates or updates candidate paths according to the creation or update requests received from the PCE.

When the device delegates only part of its SR-MPLS TE policies to a PCE, the PCE does not have complete SR-MPLS TE policy candidate path information to calculate global bandwidth information. You can enable the device to report information about the undelegated SR-MPLS TE policies to the PCE without using the PCE to compute candidate paths for the policies. This feature is referred to as the passive delegation report only feature.

Restrictions and guidelines

You can configure the PCE delegation and passive delegation report only features for all SR-MPLS TE policies globally in SR TE view or for a specific SR-MPLS TE policy in SR TE policy view. The policy-specific configuration takes precedence over the global configuration. An SR-MPLS TE policy uses the global configuration only when it has no policy-specific configuration.

In SR TE view, if you execute both the sr-policy pce delegation enable command and the sr-policy pce passive-delegate report-only enable command, the sr-policy pce passive-delegate report-only enable command takes effect.

In SR-MPLS TE policy view, if you execute both the pce delegation command and the pce passive-delegate report-only command, the pce passive-delegate report-only command takes effect.

Prerequisites

Before you perform this task, configure a PCEP session first.

Configuring PCE delegation parameters

1. Enter system view.

system-view

2. Enter PCC view.

pce-client

3. Set the delegation priority of a PCE.

pce peer ip-address delegation-priority priority

By default, the delegation priority of a PCE is 65535.

A smaller value represents a higher priority.

4. Set the redelegation timeout interval.

pce redelegation-timeout value

By default, the redelegation timeout interval is 30 seconds.

5. Set the state timeout interval on the PCC.

pce state-timeout value

By default, the state timeout interval is 60 seconds.

Enabling delegation

1. Enter system view.

system-view

2. Enter PCC view.

pce-client

3. Configure the PCEP device type as active stateful or passive stateful.

pcep type { active-stateful | passive-stateful }

By default, the PCEP device type is stateless.

4. Return to system view.

quit

5. Enter SR view.

segment-routing

6. Enter SR TE view.

traffic-engineering

7. Enable PCE delegation for SR-MPLS TE policies globally.

sr-policy pce delegation enable

By default, PCE delegation for SR-MPLS TE policies is disabled globally.

8. Globally enable the PCC to report candidate information of an SR-MPLS TE policy to the PCE without delegating the policy to the PCE.

sr-policy pce passive-delegate report-only enable

By default, this feature is disabled globally.

9. Enter SR-MPLS TE policy view.

policy policy-name

10. Enable PCE delegation for the SR-MPLS TE policy.

pce delegation { enable | disable }

By default, an SR-MPLS TE policy uses the PCE delegation setting configured in SR TE view.

11. Enable the PCC to report candidate information of the SR-MPLS TE policy to the PCE without delegating the policy to the PCE.

pce passive-delegate report-only { enable | disable }

By default, an SR-MPLS TE policy uses the passive delegation report only setting configured in SR TE view.

Enabling strict SID encapsulation for SID lists

About this task

The SID list of an SR-MPLS TE policy can be formed by prefix SIDs and adjacency SIDs. A prefix SID cannot uniquely identify a link. When the links in the network flap frequently, the forwarding paths of the SR-MPLS TE policy might change. To ensure stability of forwarding paths, perform this task to enable the SR-MPLS TE policy to include only adjacency SIDs in the calculated SID lists.

Prerequisites

Perform this task on the source node of an SR-MPLS TE policy.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enable strict SID encapsulation for SID lists.

¡ Execute the following commands in sequence to enable this feature in SR-MPLS TE policy path preference dynamic view.

policy policy-name

candidate-paths

preference preference-value

dynamic

strict-sid-only enable

¡ Execute the following commands in sequence to enable this feature in SR-TE-ODN dynamic view.

on-demand color color-value

dynamic

strict-sid-only enable

By default, strict SID encapsulation is disabled for SID lists.

Configuring dynamic path calculation timers

About this task

Perform this task to avoid excessive resource consumption caused by frequent network changes.

If you specify the maximum-interval, minimum-interval, and incremental-interval settings for the command, the following situations will occur:

· For the first path calculation triggered for the SR-MPLS TE policy, the minimum-interval setting applies.

· For the nth (n > 1) path calculation triggered for the SR-MPLS TE policy, the device adds a value of incremental-interval × 2n-2 based on the minimum-interval setting. The total value does not exceed the maximum-interval setting.

If the value of minimum-interval + incremental-interval × 2n-2 is larger than or equal to the value of maximum-interval, the device uses the conservative keyword and SR-MPLS TE policy flapping condition to adjust the path calculation intervals:

· If the conservative keyword is specified:

¡ If SR-MPLS TE policy flappings occur, the maximum-interval setting applies.

¡ If no SR-MPLS TE policy flappings occur, the maximum interval applies for once, and then the minimum interval applies.

· If the conservative keyword is not specified:

¡ If SR-MPLS TE policy flappings occur, the maximum interval applies for three consecutive times, and then the minimum interval applies.

¡ If no SR-MPLS TE policy flappings occur, the maximum interval applies for once, and then the minimum interval applies.

Restrictions and guidelines

The value of the minimum-interval or incremental-interval argument cannot be greater than the maximum-interval argument.

To increase path calculation frequency for faster path calculation, configure a fixed interval.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Configure the dynamic path calculation timers.

sr-policy calc-schedule-interval { maximum-interval [ minimum-interval [ incremental-interval [ conservative ] ] ] | millisecond interval }

By default, the maximum, minimum, and incremental intervals for dynamic path calculation are 5 seconds, 50 milliseconds, and 200 milliseconds, respectively.

Enabling the device to distribute SR-MPLS TE policy path information to BGP-LS

About this task

This feature enables the device to distribute SR-MPLS TE policy candidate path information to BGP-LS. BGP-LS advertises the SR-MPLS TE policy candidate path information to meet application requirements.

Prerequisites

Before you configure this feature, enable the device to exchange LS information with the related peer or peer group. For more information about the LS exchange capability, see the BGP LS configuration in Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enable the device to distribute SR-MPLS TE policy candidate path information to BGP-LS.

distribute bgp-ls

By default, the device cannot distribute SR-MPLS TE policy candidate path information to BGP-LS.

Shutting down an SR-MPLS TE policy

About this task

If multiple SR-MPLS TE policies exist on the device, you can shut down unnecessary SR-MPLS TE policies to prevent them from affecting traffic forwarding.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-MPLS TE policy view.

policy policy-name

5. Shut down the SR-MPLS TE policy.

shutdown

By default, an SR-MPLS TE policy is not administratively shut down.

Configuring BGP to advertise BGP IPv4 SR policy routes

Restrictions and guidelines for BGP IPv4 SR policy route advertisement

For more information about BGP commands, see Layer 3—IP Routing Commands.

Enabling BGP to advertise BGP IPv4 SR policy routes

1. Enter system view.

system-view

2. Configure a global router ID.

router id router-id

By default, no global router ID is configured.

3. Enable a BGP instance and enter its view.

bgp as-number [ instance instance-name ]

By default, BGP is disabled and no BGP instances exist.

4. Configure a peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

5. Create the BGP IPv4 SR-MPLS TE policy address family and enter its view.

address-family ipv4 sr-policy

6. Enable BGP to exchange SR-MPLS TE policy routing information with the peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, the device cannot use BGP to exchange SR-MPLS TE policy routing information with a peer or peer group.

Configuring BGP to redistribute routes from the SR-MPLS TE policy

About this task

After you configure BGP to redistribute BGP IPv4 SR policy routes, the system will redistribute the local BGP IPv4 SR policy routes to the BGP routing table and advertise the routes to IBGP peers. Then, the peers can forward traffic based on the SR-MPLS TE policy.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 SR-MPLS TE policy address family view.

address-family ipv4 sr-policy

4. Enable BGP to redistribute routes from the SR-MPLS TE policy.

import-route sr-policy

By default, BGP does not redistribute BGP IPv4 SR policy routes.

Advertising BGP IPv4 SR policy routes to EBGP peers

About this task

By default, only IBGP peers exchange BGP IPv4 SR policy routes. Perform this task to advertise BGP IPv4 SR policy routes to EBGP peers.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 SR-MPLS TE policy address family view.

address-family ipv4 sr-policy

4. Advertise BGP IPv4 SR policy routes to EBGP peers.

advertise ebgp enable

By default, BGP IPv4 SR policy routes are not advertised to EBGP peers.

Filtering BGP IPv4 SR policy routes by router ID

About this task

When a large number of BGP IPv4 SR policy routes exist in the network, perform this task to enable the device to process only specific BGP IPv4 SR policy routes.

Upon receiving BGP IPv4 SR policy routes, the device checks the Route Target (RT) attribute in received BGP IPv4 SR policy routes. Only the routes containing the local router ID in the RT attribute are accepted.

Restrictions and guidelines

To avoid incorrect route learning or filtering, configure a routing policy to add an appropriate RT attribute to BGP IPv4 SR policy routes before using this feature.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 SR-MPLS TE policy address family view.

address-family ipv4 sr-policy

4. Enable BGP IPv4 SR policy route filtering by router ID.

router-id filter

By default, BGP IPv4 SR policy route filtering by router ID is disabled.

Configuring BGP to control BGP IPv4 SR policy route selection and advertisement

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 SR-MPLS TE policy address family view.

address-family ipv4 sr-policy

4. Configure the NEXT_HOP attribute for routes. Choose one option as needed:

¡ Specify the local router as the next hop for routes sent to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } next-hop-local

¡ Configure the device to not change the next hop of routes advertised to peers.

peer { group-name | ipv4-address [ mask-length ] } next-hop-invariable

By default, BGP sets the local router as the next hop for all routes sent to an EBGP peer or peer group. BGP does not set the local router as the next hop for routes sent to an IBGP peer or peer group.

The peer next-hop-local and peer next-hop-invariable commands are mutually exclusive.

5. Allow a local AS number to exist in the AS_PATH attribute of routes from a peer or peer group, and to set the number of times the local AS number can appear.

peer { group-name | ipv4-address [ mask-length ] } allow-as-loop [ number ]

By default, the local AS number is not allowed to exist in the AS_PATH attribute of routes from a peer or peer group.

6. Specify a preferred value for routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } preferred-value value

By default, the preferred value is 0 for routes received from a peer or peer group.

7. Set the maximum number of routes that can be received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-limit prefix-number [ { alert-only | discard | reconnect reconnect-time } | percentage-value ] *

By default, the number of routes that can be received from a peer or peer group is not limited.

8. Configure the device as a route reflector and specify a peer or peer group as a client.

peer { group-name | ipv4-address [ mask-length ] } reflect-client

By default, neither the route reflector nor the client is configured.

9. Specify a prefix list to filter routes received from or advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } prefix-list ipv4-prefix-list-name { export | import }

By default, no prefix list based filtering is configured.

10. Apply a routing policy to routes incoming from or outgoing to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-policy route-policy-name { export | import }

By default, no routing policy is applied to routes incoming from or outgoing to a peer or peer group.

11. Advertise the COMMUNITY attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } advertise-community

By default, no COMMUNITY attribute is advertised to any peers or peer groups.

12. Advertise the extended community attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } advertise-ext-community

By default, no extended community attribute is advertised to any peers or peer groups.

Maintaining BGP sessions

To maintain BGP sessions, execute the following commands in user view:

· Reset BGP sessions for the BGP IPv4 SR-MPLS TE policy address family.

reset bgp [ instance instance-name ] { as-number | ipv4-address [ mask-length ] | all | external | group group-name | internal } ipv4 sr-policy

· Manually soft-reset BGP sessions for the BGP IPv4 SR-MPLS TE policy address family.

refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] | all | external | group group-name | internal } { export | import } ipv4 sr-policy

Steering traffic to an SR-MPLS TE policy

Configuring color-based traffic steering

About this task

To steer traffic to an SR-MPLS TE policy based on colors, you can configure a color extended community for routes that do not carry a color extended community in the following methods:

· Configure a routing policy to add a color value to routes.

· Configure a default color value.

The color value specified in the routing policy is preferred.

Restrictions and guidelines

The default color value applies only to the VPN routes or public network routes learned from a remote PE.

The default color value is used only for SR-MPLS TE policy traffic steering. It does not used in route advertisement.

Configuring a routing policy to add a color value to routes

1. Enter system view.

system-view

2. Enter routing policy node view.

route-policy route-policy-name { deny | permit } node node-number

3. Set the color extended community attribute for BGP routes.

apply extcommunity color color [ additive ]

By default, no BGP route attributes are configured.

4. Return to system view.

quit

5. Enter BGP instance view.

bgp as-number [ instance instance-name ]

6. Enter BGP IPv4 unicast address family view, BGP IPv6 unicast address family view, BGP VPNv4 address family view, or BGP VPNv6 address family view.

¡ Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

¡ Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

¡ Enter BGP VPNv4 address family view.

address-family vpnv4

¡ Enter BGP VPNv6 address family view.

address-family vpnv6

7. Specify a routing policy to filter routes advertised to or received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-policy route-policy-name { export | import }

By default, no routing policy is specified.

Configuring a default color value for VPN routes

1. Enter system view.

system-view

2. Enter VPN instance view.

ip vpn-instance vpn-instance-name [ index vpn-index ]

3. Enter VPN instance IPv4 address family view or VPN instance IPv6 address family view.

¡ Enter VPN instance IPv4 address family view.

address-family ipv4

¡ Enter VPN instance IPv6 address family view.

address-family ipv6

4. Configure a default color value for L3VPN route recursion to an SR-MPLS TE policy.

default-color color-value [ evpn ]

By default, no default color is configured for L3VPN route recursion to an SR-MPLS TE policy.

Configuring a default color value for public network routes

1. Enter system view.

system-view

2. Enter pubic instance view.

ip public-instance

3. Enter public instance IPv4 or IPv6 address family view.

¡ Enter public instance IPv4 address family view

address-family ipv4

¡ Enter public instance IPv6 address family view.

address-family ipv6

4. Configure a default color value for public network route recursion to an SR-MPLS TE policy.

default-color color-value

By default, no default color value is configured for public network route recursion to an SR-MPLS TE policy.

Configuring tunnel policy-based traffic steering

1. Enter system view.

system-view

2. Create a tunnel policy and enter tunnel policy view.

tunnel-policy tunnel-policy-name [ default ]

3. Configure the tunnel policy. Choose one option as needed:

¡ Configure an SR-MPLS TE policy tunnel as a preferred tunnel.

preferred-path sr-policy name sr-policy-name

By default, no preferred tunnels are configured.

¡ Configure a tunnel load sharing policy.

select-seq sr-policy load-balance-number number

By default, no tunnel load sharing policies are configured.

For more information about the commands, see MPLS Command Reference.

4. Return to system view.

quit

5. Enter VPN instance view, VPN instance IPv4 address family view, or VPN instance IPv6 address family view.

¡ Enter VPN instance view.

ip vpn-instance vpn-instance-name

¡ Execute the following commands in sequence to enter VPN instance IPv4 address family view.

ip vpn-instance vpn-instance-name

address-family ipv4

¡ Execute the following commands in sequence to enter VPN instance IPv6 address family view.

ip vpn-instance vpn-instance-name

address-family ipv6

6. Apply a tunnel policy to the VPN instance.

tnl-policy tunnel-policy-name

By default, no tunnel policy is applied to the VPN instance.

For more information about this command, see MPLS Command Reference.

Configuring DSCP-based traffic steering

About this task

Each SR-MPLS TE policy in an SR-MPLS TE policy group has a different color attribute value. By configuring color-to-DSCP mappings for an SR-MPLS TE policy group, you associate DSCP values to SR-MPLS TE policies. This allows IP packets containing a specific DSCP value to be steered to the corresponding SR-MPLS TE policy for further forwarding.

Restrictions and guidelines

You can map the color values of only valid SR-MPLS TE policies to DSCP values.

You can configure color-to-DSCP mappings separately for the IPv4 address family and IPv6 address family. For a specific address family, a DSCP value can be mapped to only one color value.

Use the color match dscp default command to specify the default SR-MPLS TE policy for an address family. If no SR-MPLS TE policy in an SR-MPLS TE policy group matches a specific DSCP value, the default SR-MPLS TE policy is used to forward packets containing the DSCP value. Only one default SR-MPLS TE policy can be specified for an address family.

If no default SR-MPLS TE policy is configured for a specific address family in a SR-MPLS TE policy group, the following conditions exist:

· If color-to-DSCP mappings are configured, the packets that fail to match any SR-MPLS TE policies are steered to the SR-MPLS TE policy associated with the smallest DSCP value.

· If all packets fail to match an SR-MPLS TE policy (for example, because no color-to-DSCP mappings are configured), the packets processed as follows:

¡ The packets are steered to the default SR-MPLS TE policy of the other address family.

¡ If neither address family is configured with the default SR-MPLS TE policy, the packets are steered to the SR-MPLS TE policy associated with the smallest DSCP value in the current address family.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Create and enter the SR TE view.

traffic-engineering

4. Create an SR-MPLS TE policy group and enter its view.

policy-group group-id

5. Configure the endpoint IP address for the SR-MPLS TE policy group.

end-point ipv4 ipv4-address

By default, no endpoint IP address is configured for the SR-MPLS TE policy group.

The SR-MPLS TE policies added to the SR-MPLS TE policy group must use the same endpoint IP address as the SR-MPLS TE policy group.

6. Create color-to-DSCP mappings for the SR-MPLS TE policy group.

color color-value match dscp { ipv4 | ipv6 } dscp-value-list

color color-value match dscp { ipv4 | ipv6 } default

By default, no color-to-DSCP mappings are created for the SR-MPLS TE policy group.

DSCP-based traffic steering cannot function if no color-to-DSCP mappings are created.

7. Return to system view.

quit

8. Create a tunnel policy and enter tunnel policy view.

tunnel-policy tunnel-policy-name [ default ]

9. Bind the SR-MPLS TE policy group to a destination IP address.

binding-destination dest-ip-address sr-policy group sr-policy-group-id [ ignore-destination-check ] [ down-switch ]

By default, a tunnel policy does not bind any SR-MPLS TE policy group to a destination IP address.

For more information about the command, see MPLS Command Reference.

Configuring static route-based traffic steering

Restrictions and guidelines

After you configure this feature, execute the route-replicate command in public instance IPv4 address family view to replicate the routes of the specified VPN instance to the public network, so the public network can use the VPN routes to forward user traffic.

Procedure

1. Enter system view.

system-view

2. Configure a static route and associate it with an SR-MPLS TE policy.

Public network:

ip route-static dest-address { mask-length | mask } sr-policy policy-name [ preference preference ] [ tag tag-value ] [ description text ]

VPN:

ip route-static vpn-instance s-vpn-instance-name dest-address { mask-length | mask } sr-policy policy-name [ preference preference ] [ tag tag-value ] [ description text ]

By default, no static route is configured.

For more information about the commands, see static routing commands in Layer 3—IP Routing Command Reference.

Configuring Flowspec rule-based traffic steering

Creating and activating an IPv4 Flowspec rule

1. Enter system view.

system-view

2. Create an IPv4 Flowspec rule.

flow-route flowroute-name

3. Configure a match criterion.

if-match match-criteria

4. Apply an action that redirects packets to an SR-MPLS TE policy.

apply redirect next-hop ipv4-address color color

By default, no action is configured.

5. Commit the match criterion and action.

commit

By default, match criteria and actions are not committed.

Applying an IPv4 Flowspec rule to the public network

1. Enter system view.

system-view

2. Enter Flowspec view.

flowspec

3. Create a Flowspec IPv4 address family for the public network and enter its view.

address-family ipv4

4. Apply an IPv4 Flowspec rule to the public network. Choose one option as needed:

¡ Apply an IPv4 Flowspec rule.

flow-route flowroute-name

By default, no IPv4 Flowspec rule is applied to the public network.

¡ Apply an IPv4 Flowspec rule and associate it with a Flowspec interface group.

flow-route flowroute-name flow-interface-group group-id

By default, no Flowspec interface group is associated with an IPv4 Flowspec rule.

Applying an IPv4 Flowspec rule to a VPN instance

1. Enter system view.

system-view

2. Configure a VPN instance.

a. Create a VPN instance and enter VPN instance view.

ip vpn-instance vpn-instance-name

b. Configure an RD for the VPN instance.

route-distinguisher route-distinguisher

By default, no RD is configured for a VPN instance.

c. Configure route targets for the VPN instance.

vpn-target { vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ] }

By default, no route targets are configured.

For more information about the ip vpn-instance, route-distinguisher, and vpn-target commands, see MPLS L3VPN commands in MPLS Command Reference.

3. Enter the IPv4 Flowspec address family view of the VPN instance.

address-family ipv4 flowspec

4. Configure an RD for the IPv4 Flowspec address family.

route-distinguisher route-distinguisher

By default, no RD is configured for the IPv4 Flowspec address family.

5. Configure route targets for the IPv4 Flowspec address family.

vpn-target vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ]

By default, no route targets are configured for the IPv4 Flowspec address family.

The route targets configured must be the same as the route targets configured previously for the VPN instance.

6. Execute the quit command twice to return to system view.

7. Enter Flowspec view.

flowspec

8. Create a Flowspec IPv4 address family and associate the address family with the VPN instance.

address-family ipv4 vpn-instance vpn-instance-name

9. Apply an IPv4 Flowspec rule to the Flowspec IPv4 VPN instance address family. Choose one option as needed:

¡ Apply an IPv4 Flowspec rule.

flow-route flowroute-name

By default, no IPv4 Flowspec rule is applied to a Flowspec IPv4 VPN instance address family.

¡ Apply an IPv4 Flowspec rule and associate it with a Flowspec interface group.

flow-route flowroute-name flow-interface-group group-id

By default, no Flowspec interface group is associated with an IPv4 Flowspec rule.

Enabling BGP to distribute IPv4 Flowspec rules

1. Enter system view.

system-view

2. Enter BGP instance view:

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 Flowspec address family view, BGP-VPN IPv4 Flowspec address family view, or BGP VPNv4 Flowspec address family view:

¡ Enter BGP IPv4 Flowspec address family view to distribute public network IPv4 Flowspec rules:

address-family ipv4 flowspec

¡ Enter BGP-VPN IPv4 Flowspec address family view to distribute private network IPv4 Flowspec rules:

ip vpn-instance vpn-instance-name

address-family ipv4 flowspec

¡ Enter BGP VPNv4 Flowspec address family view to distribute VPNv4 Flowspec rules:

address-family vpnv4 flowspec

4. Enable BGP Flowspec peers to exchange routing information.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } enable

By default, BGP Flowspec peers cannot exchange routing information.

Enabling SBFD for SR-MPLS TE policies

Restrictions and guidelines

You can enable SBFD for all SR-MPLS TE policies globally in SR TE view or for a specific SR-MPLS TE policy in SR-MPLS TE policy view. The policy-specific configuration takes precedence over the global configuration. An SR-MPLS TE policy uses the global configuration only when it has no policy-specific configuration.

You cannot enable echo SBFD for SR-MPLS TE policies with endpoint IPv6 addresses.

If both SBFD and echo BFD are enabled for an SR-MPLS TE policy, the device first establishes the SBFD session.

If both echo SBFD and echo BFD are enabled for an SR-MPLS TE policy, the device first establishes the echo SBFD session.

Prerequisites

Before you configure this feature, execute the mpls bfd enable command to enable MPLS BFD. For more information about the mpls bfd enable command, see MPLS OAM commands in MPLS Command Reference.

For an SBFD session, the source IP address of packets is selected using the following order:

1. Source IP address specified by the source-address command.

2. IP address specified by the mpls lsr-idor sbfd source-ipv6 command.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enable SBFD for all SR-MPLS TE policies.

sr-policy sbfd enable [ encapsulation-mode ipv4 ] [ proxy-reflector ] [ remote remote-id ] [ template template-name ] [ backup-template backup-template-name ]

sr-policy sbfd echo enable [ template template-name ] [ backup-template backup-template-name ]

By default, SBFD is disabled for all SR-MPLS TE policies.

5. (Optional.) Configure SBFD detection timer parameters.

sr-policy sbfd timer { detect-multiplier multiplier-value | min-tx-interval transmit-interval }

By default, no SBFD detection timer parameters are configured.

6. (Optional.) Globally enable BFD session down events to trigger SR-MPLS TE policy path reselection.

sr-policy bfd trigger path-down enable

By default, this feature is disabled.

7. (Optional.) Configure the delay time for the device to notify an SR-MPLS TE policy of the BFD/SBFD session down event.

sr-policy bfd first-fail-timer seconds

By default, the delay time for the device to notify an SR-MPLS TE policy of the BFD/SBFD session down event is 60 seconds.

8. Enter SR-MPLS TE policy view.

policy policy-name

9. (Optional.) Specify the source address for SR-MPLS TE Policy SBFD packets.

source-address { ipv4 ipv4-address | ipv6 ipv6-address }

By default, no source address for SR-MPLS TE Policy SBFD packets.

10. Configure SBFD for the SR-MPLS TE policy.

sbfd { disable | enable [ encapsulation-mode { ipv4 | ipv6 } ] [ proxy-reflector [ disable ] ] [ remote remote-id ] [ template template-name ] [ backup-template backup-template-name ] }

sbfd echo { disable | enable [ template template-name ] [ backup-template backup-template-name ] }

By default, SBFD is not configured for an SR-MPLS TE policy.

11. (Optional.) Configure BFD session down events to trigger SR-MPLS TE policy path reselection.

bfd trigger path-down { disable | enable }

By default, this feature is not configured for an SR-MPLS TE policy, and the configuration in SR TE view applies.

Configuring the BFD echo packet mode for SR-MPLS TE policies

Restrictions and guidelines

You can configure echo packet mode BFD for all SR-MPLS TE policies globally in SR TE view or for a specific SR-MPLS TE policy in SR-MPLS TE policy view. The policy-specific configuration takes precedence over the global configuration. An SR-MPLS TE policy uses the global configuration only when it has no policy-specific configuration.

The device supports echo packet mode BFD and SBFD for an SR-MPLS TE policy. If both modes are configured for the same SR-MPLS TE policy, SBFD takes effect.

For echo packet mode BFD, the source IP address of BFD packets is selected using the following order:

1. Source IP address of the BFD echo packets specified by the source-address command.

2. Source IP address of the BFD echo packets specified by the bfd echo-source-ip or bfd echo-source-ipv6 command.

3. Source IP address of the BFD session specified by the bfd echo command.

4. Source IP address of the BFD session specified by the sr-policy bfd echo command.

The source IP address of the BFD session specified by the bfd echo or sr-policy bfd echo command on the source node of an SR-MPLS TE policy is the destination IP address of the BFD echo packets. When the source IP address and destination IP address of the BFD session are the same, a network device deployed with security features, for example, uRPF takes the echo packets as illegal packets and intercept them. This practice can cause BFD echo session setup failures. To avoid this issue, make sure the source and destination IP addresses of BFD echo packets are not the same.

If the bfd echo-source-ip or bfd echo-source-ipv6 command is not executed in system view, both the source and destination IP addresses of BFD echo packets are the source IP address specified for the BFD session for an SR-MPLS TE policy. To avoid being overwhelmed by ICMP redirects from the remote device, execute the bfd echo-source-ip or bfd echo-source-ipv6 command in system view to specify the source IP address for BFD echo packets as an IP address that does not belong to any subnet of a local interface.

To successfully establish a BFD session for an SR-MPLS TE policy, the remote device must be able to reach the BFD session source IP address specified for the SR-MPLS TE policy on the local device.

Prerequisites

Before you configure this feature, execute the mpls bfd enable command to enable MPLS BFD. For more information about the mpls bfd enable command, see MPLS OAM commands in MPLS Command Reference.

Procedure

1. Enter system view.

system-view

2. Configure the source IP address of BFD echo packets.

¡ Configure the source IPv4 address of BFD echo packets.

bfd echo-source-ip ip-address

¡ Configure the source IPv6 address of BFD echo packets.

bfd echo-source-ipv6 ipv6-address

By default, no source IP address is configured for BFD echo packets.

As a best practice, specify the source IP address as an IP address that does not belong to any subnet of a local interface.

For more information about this command, see BFD commands in High Availability Command Reference.

3. Enter segment routing view.

segment-routing

4. Enter SR TE view.

traffic-engineering

5. Enable echo packet mode BFD for all SR-MPLS TE policies and configure the BFD session parameters.

sr-policy bfd echo { source-ip ipv4-address | source-ipv6 ipv6-address } [ template template-name ] [ backup-template backup-template-name ]

By default, the echo packet mode BFD is disabled for all SR-MPLS TE policies.

6. (Optional.) Globally enable BFD session down events to trigger SR-MPLS TE policy path reselection.

sr-policy bfd trigger path-down enable

By default, this feature is disabled.

7. (Optional.) Configure the delay time for the device to notify an SR-MPLS TE policy of the BFD/SBFD session down event.

sr-policy bfd first-fail-timer seconds

By default, the delay time for the device to notify an SR-MPLS TE policy of the BFD/SBFD session down event is 60 seconds.

8. Enter SR-MPLS TE policy view.

policy policy-name

9. (Optional.) Specify the source IP address of BFD echo packets for the SR-MPLS TE policy.

source-address { ipv4 ipv4-address | ipv6 ipv6-address }

By default, no source IP address of BFD echo packets is specified for an SR-MPLS TE policy.

10. Configure the echo packet mode BFD for the SR-MPLS TE policy.

bfd echo { disable | enable [ source-ip ipv4-address | source-ipv6 ipv6-address ] [ template template-name ] [ backup-template backup-template-name ] }

By default, the echo packet mode BFD is not configured for an SR-MPLS TE policy. An SR-MPLS TE policy uses the echo BFD settings configured in SR TE view.

If you do not specify the source-ip or source-ipv6 keyword in this command for an SR-MPLS TE policy, you must enable the echo packet mode BFD globally in SR TE view. Otherwise, the device cannot establish a BFD session for the SR-MPLS TE policy.

11. (Optional.) Configure BFD session down events to trigger SR-MPLS TE policy path reselection.

bfd trigger path-down { disable | enable }

By default, this feature is not configured for an SR-MPLS TE policy, and the configuration in SR TE view applies.

Enabling hot standby for SR-MPLS TE policies

About this task

The hot standby feature takes the candidate path with the highest preference in the SR-MPLS TE policy as the main path and that with the second highest preference as the backup path. When all SID lists of the main path fails, the backup path immediately takes over to minimize service interruption.

If the multilevel hot standby feature is enabled, a secondary backup path is also provided for the main path besides the backup path. The secondary backup path is the candidate path with the third highest preference in the SR-MPLS TE policy. When all SID lists of the mail path fails, the backup path immediately takes over the service. If the backup path fails, too, the secondary backup path takes over the service to minimize service interruption.

Restrictions and guidelines

You can enable hot standby for all SR-MPLS TE policies globally in SR TE view or for a specific SR-MPLS TE policy in SR-MPLS TE policy view. The policy-specific configuration takes precedence over the global configuration. An SR-MPLS TE policy uses the global configuration only when it has no policy-specific configuration.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enable hot standby for all SR-MPLS TE policies.

sr-policy backup hot-standby enable [ multilevel-backup ]

By default, hot standby is disabled for all SR-MPLS TE policies.

5. Enter SR-MPLS TE policy view.

policy policy-name

6. Configure hot standby for the SR-MPLS TE policy.

backup hot-standby { disable | enable [ multilevel-backup ] }

By default, hot standby is not configured for an SR-MPLS TE policy.

Configuring path switchover and deletion delays for SR-MPLS TE policies

About this task

The switchover delay and deletion delay mechanism is used to avoid traffic forwarding failure during a forwarding path (SID list) switchover.

When updating an SR-MPLS TE policy forwarding path, the device first establishes the new forwarding path before it deletes the old one. During the new path setup process, the device uses the old path to forward traffic until the switchover delay timer expires. When the switchover delay timer expires, the device switches traffic to the new path. The old path is deleted when the deletion delay timer expires.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Configure the switchover delay time and deletion delay time for the SR-MPLS TE policy forwarding path.

sr-policy switch-delay switch-delay-time delete-delay delete-delay-time

By default, the switchover delay time and deletion delay time for the SR-MPLS TE policy forwarding path is 5000 milliseconds and 20000 milliseconds, respectively.

Setting the delay time for bringing up SR-MPLS TE policies

About this task

After an SR-MPLS TE policy recovers from a fault, the device waits for the delay time before bringing up the SR-MPLS TE policy. This is to ensure that the fault is completely removed so as to avoid packet loss caused by SR-MPLS TE policy flapping.

After this command is executed, the device starts different delay timers for an SR-MPLS TE policy according to the SBFD configuration for the SR-MPLS TE policy.

· If SBFD is not enabled, the device starts an LSP delay timer when the SID list state changes from Down to Up.

· If SBFD is enabled, the device starts an SBFD delay timer when the SBFD session state changes from Down to Up.

Restrictions and guidelines

To view the SBFD configuration, SID list state, and SBFD session state, execute the display segment-routing te policy command.

Set a proper SR-MPLS TE policy up delay time according to your network conditions. A very long delay time will cause an SR-MPLS TE policy to be unable to process user traffic for a long time.

You can set the delay time for all SR-MPLS TE policies globally in SR TE view or for a specific SR-MPLS TE policy in SR-MPLS TE policy view. The policy-specific configuration takes precedence over the global configuration. An SR-MPLS TE policy uses the global configuration only when it has no policy-specific configuration.

If you execute this command for multiple times, the most recent configuration takes effect. A new delay time setting does not apply to the SR-MPLS TE policies that are already in a policy-up delay process.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Set the policy-up delay time for all SR-MPLS TE policies.

sr-policy up-delay delay-time

By default, the device does not delay bringing up SR-MPLS TE policies.

5. Enter SR-MPLS TE policy view.

policy policy-name

6. Set the policy-up delay time for the SR-MPLS TE policy.

up-delay delay-time

By default, no policy-up delay time is set for an SR-MPLS TE policy and the policy-up delay time set in SR TE view applies.

Configuring candidate path reoptimization for SR-MPLS TE policies

About this task

This feature enables the PCE to periodically compute paths and notify the PCC to update path information, so that SR-MPLS TE policies can use the optimal path to establish the candidate path.

For example, an SR-MPLS TE policy uses a path other than the optimal path to establish the candidate path because the optimal path does not have sufficient link bandwidth. This feature enables the SR-MPLS TE policy to switch the candidate path to the optimal path when the link bandwidth becomes sufficient.

Restrictions and guidelines

You can configure candidate path reoptimization for all SR-MPLS TE policies globally in SR TE view or for a specific SR-MPLS TE policy in SR-MPLS TE policy view. The policy-specific configuration takes precedence over the global configuration. An SR-MPLS TE policy uses the global configuration only when it has no policy-specific configuration.

Procedure

1. Enter system view.

system-view

2. Enter SR view.

segment-routing

3. Enter SR TE view

traffic-engineering

4. Enable candidate path reoptimization for SR-MPLS TE policies globally.

sr-policy reoptimization [ frequency seconds ]

By default, candidate path reoptimization is disabled for SR-MPLS TE policies globally.

5. Enter SR-MPLS TE policy view.

policy policy-name

6. Configure candidate path reoptimization for the SR-MPLS TE policy.

reoptimization { disable | enable [ frequency seconds ] }

By default, candidate path reoptimization is not configured for an SR-MPLS TE policy, and the configuration in SR TE view applies.

7. Return to user view.

quit

8. Immediately reoptimize all SR-MPLS TE policies enabled with candidate path reoptimization.

sr-policy immediate-reoptimization

Configuring SR-MPLS TE policy CBTS

Restrictions and guidelines

If multiple SR-MPLS TE policies have the same service class value as a flow, the device randomly selects one of the policies to forward the flow in the following situation:

· The flow is the only flow to be forwarded.

· The load balancing mode is per flow.

In this case, the traffic forwarding statistics for a service class is about all SR-MPLS TE policies that forward the traffic of the service class. To view traffic forwarding information of each SR-MPLS TE policy that performs load balancing, use the display segment-routing te forwarding policy name policy-name verbose command.

Prerequisites

Before configuring CBTS, you must configure a QoS traffic behavior to mark the MPLS TE service class values for packets by using the remark service-class command. For more information, see QoS policy commands in ACL and QoS Command Reference.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enter SR-MPLS TE policy view.

policy policy-name

5. Set a service class value for the SR-MPLS TE policy.

service-class service-class-value

By default, no service class value is set for an SR-MPLS TE policy. The default service class value is 255 for the SR-MPLS TE policy, which means the SR-MPLS TE policy has the lowest forwarding priority.

Configuring traffic forwarding statistics for SR-MPLS TE policies

About SR-MPLS TE policy traffic forwarding statistics

This feature collects statistics on traffic forwarded by SR-MPLS TE policies.

Restrictions and guidelines

You can configure the SR-MPLS TE policy forwarding statistics feature for all SR-MPLS TE policies globally in SR TE view or for a specific SR-MPLS TE policy in SR-MPLS TE policy view. The policy-specific configuration takes precedence over the global configuration. An SR-MPLS TE policy uses the global configuration only when it has no policy-specific configuration.

Prerequisites

Before you enable SR-MPLS TE policy forwarding statistics for a service class, use the accounting command to configure the traffic accounting action. For more information, see QoS policy commands in ACL and QoS Command Reference.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enable traffic forwarding statistics for all SR-MPLS TE policies globally.

forwarding statistics [ service-class ] enable

By default, traffic forwarding statistics is disabled for all SR-MPLS TE policies globally.

If you specify the service-class keyword, the device collects statistics on the total traffic as well as the traffic of each service class that are forwarded by SR-MPLS TE policies.

5. (Optional.) Set the SR TE forwarding statistics interval.

forwarding statistics interval interval

By default, the SR TE forwarding statistics interval is 30 seconds.

6. Enter SR-MPLS TE policy view.

policy policy-name

7. Configure traffic forwarding statistics for the SR-MPLS TE policy.

forwarding statistics { disable | [ service-class ] enable }

By default, an SR-MPLS TE policy uses the traffic forwarding statistics configuration in SR TE view.

If you specify the service-class keyword, the device collects statistics on the total traffic as well as the traffic of each service class that are forwarded by the SR-MPLS TE policy.

Enabling SR-MPLS TE policy logging

About this task

This feature enables the device to log SR-MPLS TE policy state changes to facilitate audit of SR-MPLS TE policy operations. The SR-MPLS TE policy log messages are sent to the information center and output as configured in the information center. For more information about information center, see Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter segment routing view.

segment-routing

3. Enter SR TE view.

traffic-engineering

4. Enable SR-MPLS TE policy logging.

sr-policy log enable

By default, SR-MPLS TE policy logging is disabled.

Verifying and maintaining SR-MPLS TE policies

Displaying BGP SR-MPLS TE policy routing information

Perform all display tasks in any view.

· Display BGP peer or peer group information.

display bgp [ instance instance-name ] peer ipv4 sr-policy [ ipv4-address mask-length | { ipv4-address | group-name group-name } log-info | [ ipv4-address ] verbose ]

· Display BGP IPv4 SR-MPLS TE policy routing information.

display bgp [ instance instance-name ] routing-table ipv4 sr-policy [ sr-policy-prefix [ advertise-info | as-path | cluster-list | community | ext-community ] | { color color-value | end-point ipv4 ipv4-address } * | peer ipv4-address { advertised-routes | received-routes } [ statistics ] [ color color-value | end-point ipv4 ipv4-address ] * | statistics [ color color-value | end-point ipv4 ipv4-address ] * ]

display bgp [ instance instance-name ] routing-table ipv4 sr-policy [ statistics ] community [ community-number&<1-32> | aa:nn&<1-32> ] [ internet | no-advertise | no-export | no-export-subconfed ] [ whole-match ]

display bgp [ instance instance-name ] routing-table ipv4 sr-policy [ statistics ] community-list { basic-community-list-number | comm-list-name | adv-community-list-number } [ whole-match ]

display bgp [ instance instance-name ] routing-table ipv4 sr-policy [ statistics ] ext-community [ bandwidth link-bandwidth-value | color color | rt route-target | soo site-of-origin ]&<1-32> [ whole-match ]

Verifying the SR-MPLS TE policy configuration and running status

Perform all display tasks in any view.

· Display SR-MPLS TE policy information.

display segment-routing te policy [ odn | pce ] [ name policy-name | down | up | { color color-value | end-point { ipv4 ipv4-address | ipv6 ipv6-address } } * ]

· Display SR-MPLS TE policy statistics.

display segment-routing te policy statistics

· Display SR-MPLS TE policy group information.

display segment-routing te policy-group [ group-id ] [ verbose ]

· Display SR-MPLS TE policy database information.

display segment-routing te database [ link | node | prefix ]

· Display information about the most recent down event for SR-MPLS TE policies.

display segment-routing te policy last-down-reason [ binding-sid bsid | color color-value end-point { ipv4 ipv4-address | ipv6 ipv6-address } | policy-name policy-name ]

· Display SR-TE SID list information.

display segment-routing te segment-list [ name segment-list-name | id id-value ]

· Display SBFD information for SR-MPLS TE policies.

display segment-routing te sbfd [ down | policy { { color color-value | end-point { ipv4 ipv4-address | ipv6 ipv6-address } } * | name policy-name } | up ]

· Display BFD information for SR-MPLS TE policies.

display segment-routing te bfd [ down | policy { { color color-value | end-point { ipv4 ipv4-address | ipv6 ipv6-address } } * | name policy-name } | up ]

Displaying and clearing SR-TE forwarding information

To display SR-TE forwarding information, execute the following command in any view:

display segment-routing te forwarding [ policy { policy-name | { color color-value | end-point { ipv4 ipv4-address | ipv6 ipv6-address } } * } ] [ verbose ]

To clear SR-TE forwarding statistics, execute the following command in user view:

reset segment-routing te forwarding statistics [ binding-sid binding-sid | color color-value end-point { ipv4 ipv4-address | ipv6 ipv6-address } | name policy-name ]

Displaying SR-MPLS TE policy related information stored in the PCE

· Display SR-MPLS TE policy information stored in the PCE process.

display pce segment-routing policy database [ color color-value { ipv4 ipv4-address | ipv6 ipv6-address } | policyname policy-name] [ verbose ]

· Display information about the SR-MPLS TE policy Initiate messages cached in the PCE process.

display pce segment-routing policy initiate-cache

SR-MPLS TE policy configuration examples

Example: Configuring SR-MPLS TE policy-based forwarding

Network configuration

As shown in Figure 8, perform the following tasks on the devices to implement SR-MPLS TE policy-based forwarding:

· Configure Device A through Device D to run IS-IS to implement Layer 3 connectivity.

· Configure MPLS SR on Device A through Device D to establish an SRLSP.

· Configure an SR-MPLS TE policy on Device A to forward user packets along path Device A > Device B > Device C > Device D.

Figure 8 Network diagram

‌

Device	Interface	IP address	Device	Interface	IP address
Device A	Loop1	1.1.1.1/32	Device B	Loop1	2.2.2.2/32
	HGE1/0/1	12.0.0.1/24		HGE1/0/1	12.0.0.2/24
	HGE1/0/2	14.0.0.1/24		HGE1/0/2	23.0.0.2/24
Device C	Loop1	3.3.3.3/32	Device D	Loop1	4.4.4.4/32
	HGE1/0/1	34.0.0.3/24		HGE1/0/1	34.0.0.4/24
	HGE1/0/2	23.0.0.3/24		HGE1/0/2	14.0.0.4/24

Prerequisites

By default, interfaces on the device are in administratively down state. Use the undo shutdown command to bring up interfaces as needed in the corresponding interface view.

Procedure

1. Configure IP addresses and masks for interfaces. (Details not shown.)

2. Configure Device A:

# Configure IS-IS and set the IS-IS cost style to wide.

<DeviceA> system-view

[DeviceA] isis 1

[DeviceA-isis-1] network-entity 00.0000.0000.0001.00

[DeviceA-isis-1] cost-style wide

[DeviceA-isis-1] quit

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] isis enable 1

[DeviceA-HundredGigE1/0/1] quit

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] isis enable 1

[DeviceA-HundredGigE1/0/2] quit

[DeviceA] interface loopback 1

[DeviceA-LoopBack1] isis enable 1

[DeviceA-LoopBack1] quit

# Configure the MPLS LSR ID, and enable MPLS and MPLS TE.

[DeviceA] mpls lsr-id 1.1.1.1

[DeviceA] mpls te

[DeviceA-te] quit

[DeviceA] interface hundredgige 1/0/1

[DeviceA-HundredGigE1/0/1] mpls enable

[DeviceA-HundredGigE1/0/1] quit

[DeviceA] interface hundredgige 1/0/2

[DeviceA-HundredGigE1/0/2] mpls enable

[DeviceA-HundredGigE1/0/2] quit

# Configure the SRGB and enable MPLS SR in IPv4 unicast address family view.

[DeviceA] isis 1

[DeviceA-isis-1] segment-routing global-block 16000 16999

[DeviceA-isis-1] address-family ipv4

[DeviceA-isis-1-ipv4] segment-routing mpls

[DeviceA-isis-1-ipv4] quit

[DeviceA-isis-1] quit

# Configure the IS-IS prefix SID.

[DeviceA] interface loopback 1

[DeviceA-LoopBack1] isis prefix-sid index 10

[DeviceA-LoopBack1] quit

# Configure an SID list.

[DeviceA] segment-routing

[DeviceA-segment-routing] traffic-engineering

[DeviceA-sr-te] segment-list s1

[DeviceA-sr-te-sl-s1] index 10 mpls label 16020

[DeviceA-sr-te-sl-s1] index 20 mpls label 17030

[DeviceA-sr-te-sl-s1] index 30 mpls label 18040

[DeviceA-sr-te-sl-s1] quit

# Create an SR-MPLS TE policy and set the attributes.

[DeviceA-sr-te] policy p1

[DeviceA-sr-te-policy-p1] binding-sid mpls 15000

[DeviceA-sr-te-policy-p1] color 10 end-point ipv4 4.4.4.4

# Configure a candidate path for the SR-MPLS TE policy and specify an explicit path for the candidate path.

[DeviceA-sr-te-policy-p1] candidate-paths

[DeviceA-sr-te-policy-p1-path] preference 10

[DeviceA-sr-te-policy-p1-path-pref-10] explicit segment-list s1

[DeviceA-sr-te-policy-p1-path-pref-10] quit

[DeviceA-sr-te-policy-p1-path] quit

[DeviceA-sr-te-policy-p1] quit

[DeviceA-sr-te] quit

[DeviceA-segment-routing] quit

3. Configure Device B:

# Configure IS-IS and set the IS-IS cost style to wide.

<DeviceB> system-view

[DeviceB] isis 1

[DeviceB-isis-1] network-entity 00.0000.0000.0002.00

[DeviceB-isis-1] cost-style wide

[DeviceB-isis-1] quit

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] isis enable 1

[DeviceB-HundredGigE1/0/1] quit

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] isis enable 1

[DeviceB-HundredGigE1/0/2] quit

[DeviceB] interface loopback 1

[DeviceB-LoopBack1] isis enable 1

[DeviceB-LoopBack1] quit

# Configure the MPLS LSR ID, and enable MPLS and MPLS TE.

[DeviceB] mpls lsr-id 2.2.2.2

[DeviceB] mpls te

[DeviceB-te] quit

[DeviceB] interface hundredgige 1/0/1

[DeviceB-HundredGigE1/0/1] mpls enable

[DeviceB-HundredGigE1/0/1] quit

[DeviceB] interface hundredgige 1/0/2

[DeviceB-HundredGigE1/0/2] mpls enable

[DeviceB-HundredGigE1/0/2] quit

# Configure the SRGB and enable MPLS SR in IPv4 unicast address family view.

[DeviceB] isis 1

[DeviceB-isis-1] segment-routing global-block 17000 17999

[DeviceB-isis-1] address-family ipv4

[DeviceB-isis-1-ipv4] segment-routing mpls

[DeviceB-isis-1-ipv4] quit

[DeviceB-isis-1] quit

# Configure the IS-IS prefix SID.

[DeviceB] interface loopback 1

[DeviceB-LoopBack1] isis prefix-sid index 20

[DeviceB-LoopBack1] quit

4. Configure Device C:

# Configure IS-IS and set the IS-IS cost style to wide.

<DeviceC> system-view

[DeviceC] isis 1

[DeviceC-isis-1] network-entity 00.0000.0000.0003.00

[DeviceC-isis-1] cost-style wide

[DeviceC-isis-1] quit

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] isis enable 1

[DeviceC-HundredGigE1/0/1] quit

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] isis enable 1

[DeviceC-HundredGigE1/0/2] quit

[DeviceC] interface loopback 1

[DeviceC-LoopBack1] isis enable 1

[DeviceC-LoopBack1] quit

# Configure the MPLS LSR ID, and enable MPLS and MPLS TE.

[DeviceC] mpls lsr-id 3.3.3.3

[DeviceC] mpls te

[DeviceC-te] quit

[DeviceC] interface hundredgige 1/0/1

[DeviceC-HundredGigE1/0/1] mpls enable

[DeviceC-HundredGigE1/0/1] quit

[DeviceC] interface hundredgige 1/0/2

[DeviceC-HundredGigE1/0/2] mpls enable

[DeviceC-HundredGigE1/0/2] quit

# Configure the SRGB and enable MPLS SR in IPv4 unicast address family view.

[DeviceC] isis 1

[DeviceC-isis-1] segment-routing global-block 18000 18999

[DeviceC-isis-1] address-family ipv4

[DeviceC-isis-1-ipv4] segment-routing mpls

[DeviceC-isis-1-ipv4] quit

[DeviceC-isis-1] quit

# Configure the IS-IS prefix SID.

[DeviceC] interface loopback 1

[DeviceC-LoopBack1] isis prefix-sid index 30

[DeviceC-LoopBack1] quit

5. Configure Device D:

# Configure IS-IS and set the IS-IS cost style to wide.

<DeviceD> system-view

[DeviceD] isis 1

[DeviceD-isis-1] network-entity 00.0000.0000.0004.00

[DeviceD-isis-1] cost-style wide

[DeviceD-isis-1] quit

[DeviceD] interface hundredgige 1/0/1

[DeviceD-HundredGigE1/0/1] isis enable 1

[DeviceD-HundredGigE1/0/1] quit

[DeviceD] interface hundredgige 1/0/2

[DeviceD-HundredGigE1/0/2] isis enable 1

[DeviceD-HundredGigE1/0/2] quit

[DeviceD] interface loopback 1

[DeviceD-LoopBack1] isis enable 1

[DeviceD-LoopBack1] quit

# Configure the MPLS LSR ID, and enable MPLS and MPLS TE.

[DeviceD] mpls lsr-id 4.4.4.4

[DeviceD] mpls te

[DeviceD-te] quit

[DeviceD] interface hundredgige 1/0/1

[DeviceD-HundredGigE1/0/1] mpls enable

[DeviceD-HundredGigE1/0/1] quit

[DeviceD] interface hundredgige 1/0/2

[DeviceD-HundredGigE1/0/2] mpls enable

[DeviceD-HundredGigE1/0/2] quit

# Configure the SRGB and enable MPLS SR in IPv4 unicast address family view.

[DeviceD] isis 1

[DeviceD-isis-1] segment-routing global-block 19000 19999

[DeviceD-isis-1] address-family ipv4

[DeviceD-isis-1-ipv4] segment-routing mpls

[DeviceD-isis-1-ipv4] quit

[DeviceD-isis-1] quit

# Configure the IS-IS prefix SID.

[DeviceD] interface loopback 1

[DeviceD-LoopBack1] isis prefix-sid index 40

[DeviceD-LoopBack1] quit

Verifying the configuration

# Display SR TE policy information on Device A.

[DeviceA] display segment-routing te policy

Name/ID: p1/0

Color: 10

Endpoint: 4.4.4.4

Name from Bgp:

Name from PCE:

BSID:

Mode: Explict Type: Type_1 Request state: Succeeded

Current BSID: 15000 Explicit BSID: 15000 Dynamic BSID: -

Reference counts: 4

Flags: A/BS/NC

Status: Up

AdminStatus: Up

Forwarding status: Active

Up time: 2019-10-25 11:16:15

Down time: 2019-10-25 11:16:00

Hot-standby: Not configured

Statistics: Not configured

Statistics by service class: Not configured

SBFD: Not configured

BFD echo: Not configured

Drop-upon-invalid: Disabled

BFD trigger path-down: Disabled

PolicyNID: 6201

Service-class: -

Candidate paths state: Configured

PCE delegation: Not configured

PCE delegate report-only: Not configured

Reoptimization: Not configured

Candidate paths statistics:

CLI paths: 1 BGP paths: 0

PCEP paths: 0 ODN paths: 0

Candidate paths:

Preference : 10

CPathName:

ProtoOrigin: CLI Discriminator: 10

Instance ID: 0 Node address: 0.0.0.0

Originator: 0, 0.0.0.0

Optimal: Y Flags: V/A

Dynamic: Not configured

PCEP: Not configured

Explict SID list:

ID: 1 Name: s1

Weight: 1 Nid: 24117249

State: Up State(-): -

The output shows that the SR-MPLS TE policy is in up state. The device can use the SR-MPLS TE policy to forward packets.

# Display SR TE forwarding information on Device A.

[DeviceA] display segment-routing te forwarding verbose

Total Forwarding entries: 1

Policy name/ID: p1/0

Binding SID: 15000

Policy NID: 0x01400001

Forwarding status: Active

Main path:

SegList Name/ID: s1/1

SegList NID: 0x01700001

Weight: 1

Forwarding status: Active

Outgoing NID: 0x01600001

OutLabels: 3

Interface: HGE1/0/1

NextHop: 12.0.0.2

Path ID: 0

Label stack: {17030, 18040}

The output shows that the label stack for packets forwarded by using the SR-MPLS TE policy is {17030, 18040}.

# Display MPLS LSP information on Device A.

[DeviceA] display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

12.0.0.2 Local -/- HGE1/0/1

14.0.0.4 Local -/- HGE1/0/2

1.1.1.1/32 ISIS 16010/- -

2.2.2.2/32 ISIS 16020/3 HGE1/0/1

2.2.2.2/32 ISIS -/3 HGE1/0/1

3.3.3.3/32 ISIS 16030/17030 HGE1/0/1

3.3.3.3/32 ISIS -/17030 HGE1/0/1

3.3.3.3/32 ISIS 16030/19030 HGE1/0/2

3.3.3.3/32 ISIS -/19030 HGE1/0/2

4.4.4.4/32 ISIS 16040/3 HGE1/0/2

4.4.4.4/32 ISIS -/3 HGE1/0/2

4.4.4.4/32/20971521 SRPolicy -/17030 HGE1/0/1

18040

24117249 SRPolicy -/- LSINDEX23068673

4.4.4.4/10 SRPolicy 15000/- LSINDEX20971521

The output shows that the forwarding paths used by the SR-MPLS TE policy.

10-Segment Routing Configuration Guide

Configuring SR-MPLS TE policies

About SR-MPLS TE policies

SR-MPLS TE policy identification

Candidate path

Preference

Segment list

Weight

SR-MPLS TE policy tunnel

SR-MPLS TE policy group

Dynamic path calculation based on affinity attribute

Dynamic path calculation based on Flex-Algo

Basic concepts

PCE path computation

Traffic steering to an SR-MPLS TE policy

About SR-MPLS TE policy CBTS

How SR-MPLS TE policy CBTS works

SR-MPLS TE policy tunnel selection rules

SR-MPLS TE policy CBTS application scenario

Echo BFD for SR-MPLS TE policy

SBFD for SR-MPLS TE policy

MP-BGP extension for SR-MPLS TE policy-based routing

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Discovering PCEs

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

Creating a name-to-bit mapping for an affinity attribute

Configuring affinity attribute rules

Configuring dynamic path calculation based on affinity attribute rule

Prerequisites

Procedure

Creating a name-to-bit mapping for an affinity attribute

Configuring affinity attribute rules

Configuring dynamic path calculation based on affinity attribute rule

Prerequisites

Procedure

About this task

Restrictions and guidelines

Prerequisites

Configuring PCE delegation parameters

Enabling delegation

About this task

Prerequisites

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Prerequisites

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

Maintaining BGP sessions

About this task

Restrictions and guidelines

Configuring a routing policy to add a color value to routes

Configuring a default color value for VPN routes

Configuring a default color value for public network routes

About this task

Restrictions and guidelines

Procedure

Restrictions and guidelines