Segment Routing Configuration Guide for Cisco NCS 6000 Series Routers, IOS XR Release 7.4.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This module provides information about segment routing for traffic engineering (SR-TE) policies, how to configure SR-TE policies,
and how to steer traffic into an SR-TE policy.
SR-TE Policy Overview
Segment routing for traffic engineering (SR-TE) uses a “policy” to steer traffic through the network. An SR-TE policy path
is expressed as a list of segments that specifies the path, called a segment ID (SID) list. Each segment is an end-to-end
path from the source to the destination, and instructs the routers in the network to follow the specified path instead of
following the shortest path calculated by the IGP. If a packet is steered into an SR-TE policy, the SID list is pushed on
the packet by the head-end. The rest of the network executes the instructions embedded in the SID list.
An SR-TE policy is identified as an ordered list (head-end, color, end-point):
Head-end – Where the SR-TE policy is instantiated
Color – A numerical value that distinguishes between two or more policies to the same node pairs (Head-end – End point)
End-point – The destination of the SR-TE policy
Every SR-TE policy has a color value. Every policy between the same node pairs requires a unique color value.
An SR-TE policy uses one or more candidate paths. A candidate path is a single segment list (SID-list) or a set of weighted
SID-lists (for weighted equal cost multi-path [WECMP]). A candidate path is either dynamic or explicit. See SR-TE Policy Path Types section for more information.
Usage Guidelines and Limitations
Observe the following guidelines and limitations for the platform.
Broadcast links are not supported, configure IGP's interface as P2P (point-to-point).
The ECMP path-set of an IGP route with a mix of SR-TE Policy paths (Autoroute Include) and unprotected native paths is supported.
The ECMP path-set of an IGP route with a mix of SR-TE Policy paths (Autoroute Include) and protected (LFA/TI-LFA) native paths
is not supported.
Before configuring SR-TE policies, use the distribute link-state command under IS-IS or OSPF to distribute the link-state database to external services.
GRE tunnel as primary interface for an SR policy is not supported.
GRE tunnel as backup interface for an SR policy with TI-LFA protection is not supported.
Head-end computed inter-domain SR policy with Flex Algo constraint and IGP redistribution is not supported.
Instantiation of an SR Policy
An SR policy is instantiated, or implemented, at the head-end router.
The following sections provide details on the SR policy instantiation methods:
Segment Routing On-Demand Next Hop (SR-ODN) allows a service head-end router to automatically instantiate an SR policy to
a BGP next-hop when required (on-demand). Its key benefits include:
SLA-aware BGP service – Provides per-destination steering behaviors where a prefix, a set of prefixes, or all prefixes from a service can be associated
with a desired underlay SLA. The functionality applies equally to single-domain and multi-domain networks.
Simplicity – No prior SR Policy configuration needs to be configured and maintained. Instead, operator simply configures a small set
of common intent-based optimization templates throughout the network.
Scalability – Device resources at the head-end router are used only when required, based on service or SLA connectivity needs.
The following example shows how SR-ODN works:
An egress PE (node H) advertises a BGP route for prefix T/t. This advertisement includes an SLA intent encoded with a BGP
color extended community. In this example, the operator assigns color purple (example value = 100) to prefixes that should
traverse the network over the delay-optimized path.
The route reflector receives the advertised route and advertises it to other PE nodes.
Ingress PEs in the network (such as node F) are pre-configured with an ODN template for color purple that provides the node
with the steps to follow in case a route with the intended color appears, for example:
Contact SR-PCE and request computation for a path toward node H that does not share any nodes with another LSP in the same
disjointness group.
At the head-end router, compute a path towards node H that minimizes cumulative delay.
In this example, the head-end router contacts the SR-PCE and requests computation for a path toward node H that minimizes
cumulative delay.
After SR-PCE provides the compute path, an intent-driven SR policy is instantiated at the head-end router. Other prefixes
with the same intent (color) and destined to the same egress PE can share the same on-demand SR policy. When the last prefix
associated with a given [intent, egress PE] pair is withdrawn, the on-demand SR policy is deleted, and resources are freed
from the head-end router.
An on-demand SR policy is created dynamically for BGP global or VPN (service) routes. The following services are supported
with SR-ODN:
IPv4 BGP global routes
IPv6 BGP global routes (6PE)
VPNv4
VPNv6 (6vPE)
EVPN-VPWS (single-homing)
SR-ODN Configuration Steps
To configure SR-ODN, complete the following configurations:
Define the SR-ODN template on the SR-TE head-end router.
(Optional) If using Segment Routing Path Computation Element (SR-PCE) for path computation:
Configure SR-PCE. For detailed SR-PCE configuration information, see Configure SR-PCE.
Configure the head-end router as Path Computation Element Protocol (PCEP) Path Computation Client (PCC). For detailed PCEP
PCC configuration information, see Configure the Head-End Router as PCEP PCC.
The following RPL attach-points for setting/matching BGP color extended communities are supported:
Note
The following table shows the supported RPL match operations; however, routing policies are required primarily to set BGP
color extended community. Matching based on BGP color extended communities is performed automatically by ODN's on-demand color
template.
Use the on-demand colorcolor command to create an ODN template for the specified color value. The head-end router automatically follows the actions defined
in the template upon arrival of BGP global or VPN routes with a BGP color extended community that matches the color value
specified in the template.
The color range is from 1 to 4294967295.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# on-demand color 10
Note
Matching based on BGP color extended communities is performed automatically via ODN's on-demand color template. RPL routing
policies are not required.
Use the on-demand colorcolordynamic command to associate the template with on-demand SR policies with a locally computed dynamic path (by SR-TE head-end router
utilizing its TE topology database) or centrally (by SR-PCE). The head-end router will first attempt to install the locally
computed path; otherwise, it will use the path computed by the SR-PCE.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# on-demand color 10dynamic
Use the on-demand colorcolordynamic pcep command to indicate that only the path computed by SR-PCE should be associated with the on-demand SR policy. With this configuration,
local path computation is not attempted; instead the head-end router will only instantiate the path computed by the SR-PCE.
Router(config-sr-te)# on-demand color 10dynamic pcep
Configure Dynamic Path Optimization Objectives
Use the metric type {igp | te | latency} command to configure the metric for use in path computation.
Router(config-sr-te-color-dyn)# metric type te
Use the metric margin {absolutevalue| relativepercent} command to configure the On-Demand dynamic path metric margin. The range for value and percent is from 0 to 2147483647.
Use the disjoint-path group-idgroup-idtype {link | node | srlg | srlg-node} [sub-idsub-id] command to configure the disjoint-path constraints. The group-id and sub-id range is from 1 to 65535.
Router(config-sr-te-color-dyn)# disjoint-path group-id 775 type link
Use the affinity {include-any | include-all | exclude-any} {nameWORD} command to configure the affinity constraints.
Router(config-sr-te-color-dyn)# affinity exclude-any name CROSS
Use the maximum-sid-depthvalue command to customize the maximum SID depth (MSD) constraints advertised by the router.
The default MSD value is equal to the maximum MSD supported by the platform ().
Use the sid-algorithmalgorithm-number command to configure the SR Flexible Algorithm constraints. The algorithm-number range is from 128 to 255.
Router(config-sr-te-color-dyn)# sid-algorithm 128
Configuring SR-ODN: Examples
Configuring SR-ODN: Layer-3 Services Examples
The following examples show end-to-end configurations used in implementing SR-ODN on the head-end router.
Configuring ODN Color Templates: Example
Configure ODN color templates on routers acting as SR-TE head-end nodes. The following example shows various ODN color templates:
color 10: minimization objective = te-metric
color 20: minimization objective = igp-metric
color 21: minimization objective = igp-metric; constraints = affinity
color 22: minimization objective = te-metric; path computation at SR-PCE; constraints = affinity
segment-routing
traffic-eng
on-demand color 10
dynamic
metric
type te
!
!
!
on-demand color 20
dynamic
metric
type igp
!
!
!
on-demand color 21
dynamic
metric
type igp
!
affinity exclude-any
name CROSS
!
!
!
on-demand color 22
dynamic
pcep
!
metric
type te
!
affinity exclude-any
name CROSS
!
!
!
!
!
end
Configuring BGP Color Extended Community Set: Example
The following example shows how to configure BGP color extended communities that are later applied to BGP service routes via
route-policies.
Note
In most common scenarios, egress PE routers that advertise BGP service routes apply (set) BGP color extended communities.
However, color can also be set at the ingress PE router.
Configuring RPL to Set BGP Color (Layer-3 Services): Examples
The following example shows various representative RPL definitions that set BGP color community.
The examples include the set color action only. The last RPL example performs the set color action for selected destinations based on a prefix-set.
route-policy SET_COLOR_LOW_LATENCY_TE
set extcommunity color color10-te
pass
end-policy
!
route-policy SET_COLOR_HI_BW
set extcommunity color color20-igp
pass
end-policy
!
prefix-set sample-set
88.1.0.0/24
end-set
!
route-policy SET_COLOR_GLOBAL
if destination in sample-set then
set extcommunity color color10-te
else
pass
endif
end-policy
Applying RPL to BGP Services (Layer-3 Services): Example
The following example shows various RPLs that set BGP color community being applied to BGP Layer-3 VPN services (VPNv4/VPNv6)
and BGP global.
The L3VPN examples show the RPL applied at the VRF export attach-point.
The BGP global example shows the RPL applied at the BGP neighbor-out attach-point.
Use the show bgp vrf command to display BGP prefix information for VRF instances. The following output shows the BGP VRF table including a prefix
(88.1.1.0/24) with color 10 advertised by router 10.1.1.8.
RP/0/RP0/CPU0:R4# show bgp vrf vrf_cust1
BGP VRF vrf_cust1, state: Active
BGP Route Distinguisher: 10.1.1.4:101
VRF ID: 0x60000007
BGP router identifier 10.1.1.4, local AS number 100
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000007 RD version: 282
BGP main routing table version 287
BGP NSR Initial initsync version 31 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.1.1.4:101 (default for vrf vrf_cust1)
*> 44.1.1.0/24 40.4.101.11 0 400 {1} i
*>i55.1.1.0/24 10.1.1.5 100 0 500 {1} i
*>i88.1.1.0/24 10.1.1.8 C:10 100 0 800 {1} i
*>i99.1.1.0/24 10.1.1.9 100 0 800 {1} i
Processed 4 prefixes, 4 paths
The following output displays the details for prefix 88.1.1.0/24. Note the presence of BGP extended color community 10, and
that the prefix is associated with an SR policy with color 10 and BSID value of 24036.
RP/0/RP0/CPU0:R4# show bgp vrf vrf_cust1 88.1.1.0/24
BGP routing table entry for 88.1.1.0/24, Route Distinguisher: 10.1.1.4:101
Versions:
Process bRIB/RIB SendTblVer
Speaker 282 282
Last Modified: May 20 09:23:34.112 for 00:06:03
Paths: (1 available, best #1)
Advertised to CE peers (in unique update groups):
40.4.101.11
Path #1: Received by speaker 0
Advertised to CE peers (in unique update groups):
40.4.101.11
800 {1}
10.1.1.8 C:10 (bsid:24036) (metric 20) from 10.1.1.55 (10.1.1.8)
Received Label 24012
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 273
Extended community: Color:10 RT:100:1
Originator: 10.1.1.8, Cluster list: 10.1.1.55
SR policy color 10, up, registered, bsid 24036, if-handle 0x08000024
Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 10.1.1.8:101
Verifying Forwarding (CEF) Table
Use the show cef vrf command to display the contents of the CEF table for the VRF instance. Note that prefix 88.1.1.0/24 points to the BSID label
corresponding to an SR policy. Other non-colored prefixes, such as 55.1.1.0/24, point to BGP next-hop.
The following output displays CEF details for prefix 88.1.1.0/24. Note that the prefix is associated with an SR policy with
BSID value of 24036.
RP/0/RP0/CPU0:R4# show cef vrf vrf_cust1 88.1.1.0/24
88.1.1.0/24, version 51, internal 0x5000001 0x0 (ptr 0x98c60ddc) [1], 0x0 (0x0), 0x208 (0x98425268)
Updated May 20 09:23:34.216
Prefix Len 24, traffic index 0, precedence n/a, priority 3
via local-label 24036, 5 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0x97091ec0 0x0]
recursion-via-label
next hop VRF - 'default', table - 0xe0000000
next hop via 24036/0/21
next hop srte_c_10_ep labels imposed {ImplNull 24012}
Verifying SR Policy
Use the show segment-routing traffic-eng policy command to display SR policy information.
The following outputs show the details of an on-demand SR policy that was triggered by prefixes with color 10 advertised by
node 10.1.1.8.
RP/0/RP0/CPU0:R4# show segment-routing traffic-eng policy color 10 tabular
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
1010.1.1.8upup24036
The following outputs show the details of the on-demand SR policy for BSID 24036.
Note
There are 2 candidate paths associated with this SR policy: the path that is computed by the head-end router (with preference
200), and the path that is computed by the SR-PCE (with preference 100). The candidate path with the highest preference is
the active candidate path (highlighted below) and is installed in forwarding.
This use case shows how to set up a pair of ELINE services using EVPN-VPWS between two sites. Services are carried over SR
policies that must not share any common links along their paths (link-disjoint). The SR policies are triggered on-demand based
on ODN principles. An SR-PCE computes the disjoint paths.
This use case uses the following topology with 2 sites: Site 1 with nodes A and B, and Site 2 with nodes C and D.
Figure 1. Topology for Use Case: SR-ODN for EVPN-VPWS
Table 1. Use Case Parameters
IP Addresses of Loopback0 (Lo0) Interfaces
SR-PCE Lo0: 10.1.1.207
Site 1:
Node A Lo0: 10.1.1.5
Node B Lo0: 10.1.1.6
Site 2:
Node C Lo0: 10.1.1.2
Node D Lo0: 10.1.1.4
EVPN-VPWS Service Parameters
ELINE-1:
EVPN-VPWS EVI 100
Node A: AC-ID = 11
Node C: AC-ID = 21
ELINE-2:
EVPN-VPWS EVI 101
Node B: AC-ID = 12
Node D: AC-ID = 22
ODN BGP Color Extended Communities
Site 1 routers (Nodes A and B):
set color 10000
match color 11000
Site 2 routers (Nodes C and D):
set color 11000
match color 10000
Note
These colors are associated with the EVPN route-type 1 routes of the EVPN-VPWS services.
PCEP LSP Disjoint-Path Association Group ID
Site 1 to Site 2 LSPs (from Node A to Node C/from Node B to Node D):
group-id = 775
Site 2 to Site 1 LSPs (from Node C to Node A/from Node D to Node B):
group-id = 776
The use case provides configuration and verification outputs for all devices.
For cases when PCC nodes support, or signal, PCEP association-group object to indicate the pair of LSPs in a disjoint set,
there is no extra configuration required at the SR-PCE to trigger disjoint-path computation.
Note
SR-PCE also supports disjoint-path computation for cases when PCC nodes do not support PCEP association-group object. See
Configure the Disjoint Policy (Optional) for more information.
Configuration: Site 1 Node A
This section depicts relevant configuration of Node A at Site 1. It includes service configuration, BGP color extended community,
and RPL. It also includes the corresponding ODN template required to achieve the disjointness SLA.
Nodes in Site 1 are configured to set color 10000 on originating EVPN routes, while matching color 11000 on incoming EVPN
routes from routers located at Site 2.
Since both nodes in Site 1 request path computation from SR-PCE using the same disjoint-path group-id (775), the PCE will
attempt to compute disjointness for the pair of LSPs originating from Site 1 toward Site 2.
/* EVPN-VPWS configuration */
interface GigabitEthernet0/0/0/3.2500 l2transport
encapsulation dot1q 2500
rewrite ingress tag pop 1 symmetric
!
l2vpn
xconnect group evpn_vpws_group
p2p evpn_vpws_100
interface GigabitEthernet0/0/0/3.2500
neighbor evpn evi 100 target 21 source 11
!
!
!
!
/* BGP color community and RPL configuration */
extcommunity-set opaque color-1000010000
end-set
!
route-policy SET_COLOR_EVPN_VPWS
if evpn-route-type is 1 and rd in (ios-regex '.*..*..*..*:(100)') then
set extcommunity color color-10000
endif
pass
end-policy
!
router bgp 65000
neighbor 10.1.1.253
address-family l2vpn evpn
route-policy SET_COLOR_EVPN_VPWS out
!
!
!
/* ODN template configuration */
segment-routing
traffic-eng
on-demand color 11000
dynamic
pcep
!
metric
type igp
!
disjoint-path group-id 775 type link
!
!
!
!
Configuration: Site 1 Node B
This section depicts relevant configuration of Node B at Site 1.
/* EVPN-VPWS configuration */
interface TenGigE0/3/0/0/8.2500 l2transport
encapsulation dot1q 2500
rewrite ingress tag pop 1 symmetric
!
l2vpn
xconnect group evpn_vpws_group
p2p evpn_vpws_101
interface TenGigE0/3/0/0/8.2500
neighbor evpn evi 101 target 22 source 12
!
!
!
!
/* BGP color community and RPL configuration */
extcommunity-set opaque color-1000010000
end-set
!
route-policy SET_COLOR_EVPN_VPWS
if evpn-route-type is 1 and rd in (ios-regex '.*..*..*..*:(101)') then
set extcommunity color color-10000
endif
pass
end-policy
!
router bgp 65000
neighbor 10.1.1.253
address-family l2vpn evpn
route-policy SET_COLOR_EVPN_VPWS out
!
!
!
/* ODN template configuration */
segment-routing
traffic-eng
on-demand color 11000
dynamic
pcep
!
metric
type igp
!
disjoint-path group-id 775 type link
!
!
!
!
Configuration: Site 2 Node C
This section depicts relevant configuration of Node C at Site 2. It includes service configuration, BGP color extended community,
and RPL. It also includes the corresponding ODN template required to achieve the disjointness SLA.
Nodes in Site 2 are configured to set color 11000 on originating EVPN routes, while matching color 10000 on incoming EVPN
routes from routers located at Site 1.
Since both nodes on Site 2 request path computation from SR-PCE using the same disjoint-path group-id (776), the PCE will
attempt to compute disjointness for the pair of LSPs originating from Site 2 toward Site 1.
/* EVPN-VPWS configuration */
interface GigabitEthernet0/0/0/3.2500 l2transport
encapsulation dot1q 2500
rewrite ingress tag pop 1 symmetric
!
l2vpn
xconnect group evpn_vpws_group
p2p evpn_vpws_100
interface GigabitEthernet0/0/0/3.2500
neighbor evpn evi 100 target 11 source 21
!
!
!
!
/* BGP color community and RPL configuration */
extcommunity-set opaque color-1100011000
end-set
!
route-policy SET_COLOR_EVPN_VPWS
if evpn-route-type is 1 and rd in (ios-regex '.*..*..*..*:(100)') then
set extcommunity color color-11000
endif
pass
end-policy
!
router bgp 65000
neighbor 10.1.1.253
address-family l2vpn evpn
route-policy SET_COLOR_EVPN_VPWS out
!
!
!
/* ODN template configuration */
segment-routing
traffic-eng
on-demand color 10000
dynamic
pcep
!
metric
type igp
!
disjoint-path group-id 776 type link
!
!
!
!
Configuration: Site 2 Node D
This section depicts relevant configuration of Node D at Site 2.
/* EVPN-VPWS configuration */
interface GigabitEthernet0/0/0/1.2500 l2transport
encapsulation dot1q 2500
rewrite ingress tag pop 1 symmetric
!
l2vpn
xconnect group evpn_vpws_group
p2p evpn_vpws_101
interface GigabitEthernet0/0/0/1.2500
neighbor evpn evi 101 target 12 source 22
!
!
!
!
/* BGP color community and RPL configuration */
extcommunity-set opaque color-1100011000
end-set
!
route-policy SET_COLOR_EVPN_VPWS
if evpn-route-type is 1 and rd in (ios-regex '.*..*..*..*:(101)') then
set extcommunity color color-11000
endif
pass
end-policy
!
router bgp 65000
neighbor 10.1.1.253
address-family l2vpn evpn
route-policy SET_COLOR_EVPN_VPWS out
!
!
!
/* ODN template configuration */
segment-routing
traffic-eng
on-demand color 10000
dynamic
pcep
!
metric
type igp
!
disjoint-path group-id 776 type link
!
!
!
!
Verification: SR-PCE
Use the show pce ipv4 peer command to display the SR-PCE’s PCEP peers and session status. SR-PCE performs path computation for the 4 nodes depicted
in the use-case.
RP/0/0/CPU0:SR-PCE# show pce ipv4 peer
Mon Jul 15 19:41:43.622 UTC
PCE's peer database:
--------------------
Peer address: 10.1.1.2State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 10.1.1.4State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 10.1.1.5State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 10.1.1.6State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Use the show pce association group-id command to display information for the pair of LSPs assigned to a given association group-id value.
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE
services between site 1 and site 2. In particular, disjoint LSPs from site 1 to site 2 are identified by association group-id
775. The output includes high-level information for LSPs associated to this group-id:
At Node A (10.1.1.5): LSP symbolic name = bgp_c_11000_ep_10.1.1.2_discr_100
At Node B (10.1.1.6): LSP symbolic name = bgp_c_11000_ep_10.1.1.4_discr_100
In this case, the SR-PCE was able to achieve the desired disjointness level; therefore the Status is shown as "Satisfied".
RP/0/0/CPU0:SR-PCE# show pce association group-id 775
Thu Jul 11 03:52:20.770 UTC
PCE's association database:
----------------------
Association: Type Link-Disjoint, Group 775, Not Strict
Associated LSPs:
LSP[0]:
PCC 10.1.1.6, tunnel name bgp_c_11000_ep_10.1.1.4_discr_100, PLSP ID 18, tunnel ID 17, LSP ID 3, Configured on PCC
LSP[1]:
PCC 10.1.1.5, tunnel name bgp_c_11000_ep_10.1.1.2_discr_100, PLSP ID 18, tunnel ID 18, LSP ID 3, Configured on PCC
Status: Satisfied
Use the show pce lsp command to display detailed information of an LSP present in the PCE's LSP database. This output shows details for the LSP
at Node A (10.1.1.5) that is used to carry traffic of EVPN VPWS EVI 100 towards node C (10.1.1.2).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE
services between site 1 and site 2. In particular, disjoint LSPs from site 2 to site 1 are identified by association group-id
776. The output includes high-level information for LSPs associated to this group-id:
At Node C (10.1.1.2): LSP symbolic name = bgp_c_10000_ep_10.1.1.5_discr_100
At Node D (10.1.1.4): LSP symbolic name = bgp_c_10000_ep_10.1.1.6_discr_100
In this case, the SR-PCE was able to achieve the desired disjointness level; therefore, the Status is shown as "Satisfied".
RP/0/0/CPU0:SR-PCE# show pce association group-id 776
Thu Jul 11 03:52:24.370 UTC
PCE's association database:
----------------------
Association: Type Link-Disjoint, Group 776, Not Strict
Associated LSPs:
LSP[0]:
PCC 10.1.1.4, tunnel name bgp_c_10000_ep_10.1.1.6_discr_100, PLSP ID 16, tunnel ID 14, LSP ID 1, Configured on PCC
LSP[1]:
PCC 10.1.1.2, tunnel name bgp_c_10000_ep_10.1.1.5_discr_100, PLSP ID 6, tunnel ID 21, LSP ID 3, Configured on PCC
Status: Satisfied
Use the show pce lsp command to display detailed information of an LSP present in the PCE's LSP database. This output shows details for the LSP
at Node C (10.1.1.2) that is used to carry traffic of EVPN VPWS EVI 100 towards node A (10.1.1.5).
This section depicts verification steps at Node A.
Use the show bgp l2vpn evpn command to display BGP prefix information for EVPN-VPWS EVI 100 (rd 10.1.1.5:100). The output includes an EVPN route-type
1 route with color 11000 originated at Node C (10.1.1.2).
RP/0/RSP0/CPU0:Node-A# show bgp l2vpn evpn rd 10.1.1.5:100
Wed Jul 10 18:57:57.704 PST
BGP router identifier 10.1.1.5, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 360
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.1.1.5:100 (default for vrf VPWS:100)
*> [1][0000.0000.0000.0000.0000][11]/120
0.0.0.0 0 i
*>i[1][0000.0000.0000.0000.0000][21]/12010.1.1.2 C:11000 100 0 i
The following output displays the details for the incoming EVPN RT1. Note the presence of BGP extended color community 11000,
and that the prefix is associated with an SR policy with color 11000 and BSID value of 80044.
RP/0/RSP0/CPU0:Node-A# show bgp l2vpn evpn rd 10.1.1.5:100 [1][0000.0000.0000.0000.0000][21]/120
Wed Jul 10 18:57:58.107 PST
BGP routing table entry for [1][0000.0000.0000.0000.0000][21]/120, Route Distinguisher: 10.1.1.5:100
Versions:
Process bRIB/RIB SendTblVer
Speaker 360 360
Last Modified: Jul 10 18:36:18.369 for 00:21:40
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.1.1.2 C:11000 (bsid:80044) (metric 40) from 10.1.1.253 (10.1.1.2)
Received Label 80056
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install
Received Path ID 0, Local Path ID 1, version 358
Extended community: Color:11000 RT:65000:100
Originator: 10.1.1.2, Cluster list: 10.1.1.253
SR policy color 11000, up, registered, bsid 80044, if-handle 0x00001b20
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 10.1.1.2:100
Use the show l2vpn xconnect command to display the state associated with EVPN-VPWS EVI 100 service.
RP/0/RSP0/CPU0:Node-A# show l2vpn xconnect group evpn_vpws_group
Wed Jul 10 18:58:02.333 PST
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ----------------------------- -----------------------------
evpn_vpws_group
evpn_vpws_100UP Gi0/0/0/3.2500 UP EVPN 100,21,10.1.1.2 UP
----------------------------------------------------------------------------------------
The following output shows the details for the service. Note that the service is associated with the on-demand SR policy with
color 11000 and end-point 10.1.1.2 (node C).
RP/0/RSP0/CPU0:Node-A# show l2vpn xconnect group evpn_vpws_group xc-name evpn_vpws_100 detail
Wed Jul 10 18:58:02.755 PST
Group evpn_vpws_group, XC evpn_vpws_100, state is up; Interworking none
AC: GigabitEthernet0/0/0/3.2500, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2500, 2500]
MTU 1500; XC ID 0x120000c; interworking none
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
drops: illegal VLAN 0, illegal length 0
EVPN: neighbor 10.1.1.2, PW ID: evi 100, ac-id 21, state is up ( established )
XC ID 0xa0000007
Encapsulation MPLS
Source address 10.1.1.5
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_11000_ep_10.1.1.2, On-Demand, fallback enabled
Tunnel : Up
Load Balance Hashing: src-dst-mac
EVPN Local Remote
------------ ------------------------------ -----------------------------
Label 80040 80056
MTU 1500 1500
Control word enabled enabled
AC ID 11 21
EVPN type Ethernet Ethernet
------------ ------------------------------ -----------------------------
Create time: 10/07/2019 18:31:30 (1d17h ago)
Last time status changed: 10/07/2019 19:42:00 (1d16h ago)
Last time PW went down: 10/07/2019 19:40:55 (1d16h ago)
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
Use the show segment-routing traffic-eng policy command with tabular option to display SR policy summary information.
The following output shows the on-demand SR policy with BSID 80044 that was triggered by EVPN RT1 prefix with color 11000
advertised by node C (10.1.1.2).
RP/0/RSP0/CPU0:Node-A# show segment-routing traffic-eng policy color 11000 tabular
Wed Jul 10 18:58:00.732 PST
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
1100010.1.1.2upup80044
The following output shows the details for the on-demand SR policy. Note that the SR policy's active candidate path (preference
100) is computed by SR-PCE (10.1.1.207).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE
services between site 1 and site 2. Specifically, from site 1 to site 2, LSP at Node A (srte_c_11000_ep_10.1.1.2) is link-disjoint
from LSP at Node B (srte_c_11000_ep_10.1.1.4).
This section depicts verification steps at Node B.
Use the show bgp l2vpn evpn command to display BGP prefix information for EVPN-VPWS EVI 101 (rd 10.1.1.6:101). The output includes an EVPN route-type
1 route with color 11000 originated at Node D (10.1.1.4).
RP/0/RSP0/CPU0:Node-B# show bgp l2vpn evpn rd 10.1.1.6:101
Wed Jul 10 19:08:54.964 PST
BGP router identifier 10.1.1.6, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 322
BGP NSR Initial initsync version 7 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.1.1.6:101 (default for vrf VPWS:101)
*> [1][0000.0000.0000.0000.0000][12]/120
0.0.0.0 0 i
*>i[1][0000.0000.0000.0000.0000][22]/120 10.1.1.4 C:11000 100 0 i
Processed 2 prefixes, 2 paths
The following output displays the details for the incoming EVPN RT1. Note the presence of BGP extended color community 11000,
and that the prefix is associated with an SR policy with color 11000 and BSID value of 80061.
RP/0/RSP0/CPU0:Node-B# show bgp l2vpn evpn rd 10.1.1.6:101 [1][0000.0000.0000.0000.0000][22]/120
Wed Jul 10 19:08:55.039 PST
BGP routing table entry for [1][0000.0000.0000.0000.0000][22]/120, Route Distinguisher: 10.1.1.6:101
Versions:
Process bRIB/RIB SendTblVer
Speaker 322 322
Last Modified: Jul 10 18:42:10.408 for 00:26:44
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.1.1.4 C:11000 (bsid:80061) (metric 40) from 10.1.1.253 (10.1.1.4)
Received Label 80045
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install
Received Path ID 0, Local Path ID 1, version 319
Extended community: Color:11000 RT:65000:101
Originator: 10.1.1.4, Cluster list: 10.1.1.253
SR policy color 11000, up, registered, bsid 80061, if-handle 0x00000560
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 10.1.1.4:101
Use the show l2vpn xconnect command to display the state associated with EVPN-VPWS EVI 101 service.
RP/0/RSP0/CPU0:Node-B# show l2vpn xconnect group evpn_vpws_group
Wed Jul 10 19:08:56.388 PST
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ----------------------------- -----------------------------
evpn_vpws_group
evpn_vpws_101UP Te0/3/0/0/8.2500 UP EVPN 101,22,10.1.1.4 UP
----------------------------------------------------------------------------------------
The following output shows the details for the service. Note that the service is associated with the on-demand SR policy with
color 11000 and end-point 10.1.1.4 (node D).
RP/0/RSP0/CPU0:Node-B# show l2vpn xconnect group evpn_vpws_group xc-name evpn_vpws_101
Wed Jul 10 19:08:56.511 PST
Group evpn_vpws_group, XC evpn_vpws_101, state is up; Interworking none
AC: TenGigE0/3/0/0/8.2500, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2500, 2500]
MTU 1500; XC ID 0x2a0000e; interworking none
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
drops: illegal VLAN 0, illegal length 0
EVPN: neighbor 10.1.1.4, PW ID: evi 101, ac-id 22, state is up ( established )
XC ID 0xa0000009
Encapsulation MPLS
Source address 10.1.1.6
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_11000_ep_10.1.1.4, On-Demand, fallback enabled
Tunnel : Up
Load Balance Hashing: src-dst-mac
EVPN Local Remote
------------ ------------------------------ -----------------------------
Label 80060 80045
MTU 1500 1500
Control word enabled enabled
AC ID 12 22
EVPN type Ethernet Ethernet
------------ ------------------------------ -----------------------------
Create time: 10/07/2019 18:32:49 (00:36:06 ago)
Last time status changed: 10/07/2019 18:42:07 (00:26:49 ago)
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
Use the show segment-routing traffic-eng policy command with tabular option to display SR policy summary information.
The following output shows the on-demand SR policy with BSID 80061 that was triggered by EVPN RT1 prefix with color 11000
advertised by node D (10.1.1.4).
RP/0/RSP0/CPU0:Node-B# show segment-routing traffic-eng policy color 11000 tabular
Wed Jul 10 19:08:56.146 PST
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
1100010.1.1.4upup80061
The following output shows the details for the on-demand SR policy. Note that the SR policy's active candidate path (preference
100) is computed by SR-PCE (10.1.1.207).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE
services between site 1 and site 2. Specifically, from site 1 to site 2, LSP at Node B (srte_c_11000_ep_10.1.1.4) is link-disjoint
from LSP at Node A (srte_c_11000_ep_10.1.1.2).
This section depicts verification steps at Node C.
Use the show bgp l2vpn evpn command to display BGP prefix information for EVPN-VPWS EVI 100 (rd 10.1.1.2:100). The output includes an EVPN route-type
1 route with color 10000 originated at Node A (10.1.1.5).
RP/0/RSP0/CPU0:Node-C# show bgp l2vpn evpn rd 10.1.1.2:100
BGP router identifier 10.1.1.2, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 21
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.1.1.2:100 (default for vrf VPWS:100)
*>i[1][0000.0000.0000.0000.0000][11]/12010.1.1.5 C:10000 100 0 i
*> [1][0000.0000.0000.0000.0000][21]/120
0.0.0.0 0 i
The following output displays the details for the incoming EVPN RT1. Note the presence of BGP extended color community 10000,
and that the prefix is associated with an SR policy with color 10000 and BSID value of 80058.
RP/0/RSP0/CPU0:Node-C# show bgp l2vpn evpn rd 10.1.1.2:100 [1][0000.0000.0000.0000.0000][11]/120
BGP routing table entry for [1][0000.0000.0000.0000.0000][11]/120, Route Distinguisher: 10.1.1.2:100
Versions:
Process bRIB/RIB SendTblVer
Speaker 20 20
Last Modified: Jul 10 18:36:20.503 for 00:45:21
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.1.1.5 C:10000 (bsid:80058) (metric 40) from 10.1.1.253 (10.1.1.5)
Received Label 80040
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install
Received Path ID 0, Local Path ID 1, version 18
Extended community: Color:10000 RT:65000:100
Originator: 10.1.1.5, Cluster list: 10.1.1.253
SR policy color 10000, up, registered, bsid 80058, if-handle 0x000006a0
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 10.1.1.5:100
Use the show l2vpn xconnect command to display the state associated with EVPN-VPWS EVI 100 service.
RP/0/RSP0/CPU0:Node-C# show l2vpn xconnect group evpn_vpws_group
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ----------------------------- -----------------------------
evpn_vpws_group
evpn_vpws_100UP Gi0/0/0/3.2500 UP EVPN 100,11,10.1.1.5 UP
----------------------------------------------------------------------------------------
The following output shows the details for the service. Note that the service is associated with the on-demand SR policy with
color 10000 and end-point 10.1.1.5 (node A).
RP/0/RSP0/CPU0:Node-C# show l2vpn xconnect group evpn_vpws_group xc-name evpn_vpws_100
Group evpn_vpws_group, XC evpn_vpws_100, state is up; Interworking none
AC: GigabitEthernet0/0/0/3.2500, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2500, 2500]
MTU 1500; XC ID 0x1200008; interworking none
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
drops: illegal VLAN 0, illegal length 0
EVPN: neighbor 10.1.1.5, PW ID: evi 100, ac-id 11, state is up ( established )
XC ID 0xa0000003
Encapsulation MPLS
Source address 10.1.1.2
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_10000_ep_10.1.1.5, On-Demand, fallback enabled
Tunnel : Up
Load Balance Hashing: src-dst-mac
EVPN Local Remote
------------ ------------------------------ -----------------------------
Label 80056 80040
MTU 1500 1500
Control word enabled enabled
AC ID 21 11
EVPN type Ethernet Ethernet
------------ ------------------------------ -----------------------------
Create time: 10/07/2019 18:36:16 (1d19h ago)
Last time status changed: 10/07/2019 19:41:59 (1d18h ago)
Last time PW went down: 10/07/2019 19:40:54 (1d18h ago)
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
Use the show segment-routing traffic-eng policy command with tabular option to display SR policy summary information.
The following output shows the on-demand SR policy with BSID 80058 that was triggered by EVPN RT1 prefix with color 10000
advertised by node A (10.1.1.5).
RP/0/RSP0/CPU0:Node-C# show segment-routing traffic-eng policy color 10000 tabular
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
1000010.1.1.5upup80058
The following output shows the details for the on-demand SR policy. Note that the SR policy's active candidate path (preference
100) is computed by SR-PCE (10.1.1.207).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE
services between site 1 and site 2. Specifically, from site 2 to site 1, LSP at Node C (srte_c_10000_ep_10.1.1.5) is link-disjoint
from LSP at Node D (srte_c_10000_ep_10.1.1.6).
This section depicts verification steps at Node D.
Use the show bgp l2vpn evpn command to display BGP prefix information for EVPN-VPWS EVI 101 (rd 10.1.1.4:101). The output includes an EVPN route-type
1 route with color 10000 originated at Node B (10.1.1.6).
RP/0/RSP0/CPU0:Node-D# show bgp l2vpn evpn rd 10.1.1.4:101
BGP router identifier 10.1.1.4, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 570
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.1.1.4:101 (default for vrf VPWS:101)
*>i[1][0000.0000.0000.0000.0000][12]/12010.1.1.6 C:10000 100 0 i
*> [1][0000.0000.0000.0000.0000][22]/120
0.0.0.0 0 i
Processed 2 prefixes, 2 paths
The following output displays the details for the incoming EVPN RT1. Note the presence of BGP extended color community 10000,
and that the prefix is associated with an SR policy with color 10000 and BSID value of 80047.
RP/0/RSP0/CPU0:Node-D# show bgp l2vpn evpn rd 10.1.1.4:101 [1][0000.0000.0000.0000.0000][12]/120
BGP routing table entry for [1][0000.0000.0000.0000.0000][12]/120, Route Distinguisher: 10.1.1.4:101
Versions:
Process bRIB/RIB SendTblVer
Speaker 569 569
Last Modified: Jul 10 18:42:12.455 for 00:45:38
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.1.1.6 C:10000 (bsid:80047) (metric 40) from 10.1.1.253 (10.1.1.6)
Received Label 80060
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install
Received Path ID 0, Local Path ID 1, version 568
Extended community: Color:10000 RT:65000:101
Originator: 10.1.1.6, Cluster list: 10.1.1.253
SR policy color 10000, up, registered, bsid 80047, if-handle 0x00001720
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 10.1.1.6:101
Use the show l2vpn xconnect command to display the state associated with EVPN-VPWS EVI 101 service.
RP/0/RSP0/CPU0:Node-D# show l2vpn xconnect group evpn_vpws_group
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ----------------------------- -----------------------------
evpn_vpws_group
evpn_vpws_101UP Gi0/0/0/1.2500 UP EVPN 101,12,10.1.1.6 UP
----------------------------------------------------------------------------------------
The following output shows the details for the service. Note that the service is associated with the on-demand SR policy with
color 10000 and end-point 10.1.1.6 (node B).
RP/0/RSP0/CPU0:Node-D# show l2vpn xconnect group evpn_vpws_group xc-name evpn_vpws_101
Group evpn_vpws_group, XC evpn_vpws_101, state is up; Interworking none
AC: GigabitEthernet0/0/0/1.2500, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2500, 2500]
MTU 1500; XC ID 0x120000c; interworking none
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
drops: illegal VLAN 0, illegal length 0
EVPN: neighbor 10.1.1.6, PW ID: evi 101, ac-id 12, state is up ( established )
XC ID 0xa000000d
Encapsulation MPLS
Source address 10.1.1.4
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_10000_ep_10.1.1.6, On-Demand, fallback enabled
Tunnel : Up
Load Balance Hashing: src-dst-mac
EVPN Local Remote
------------ ------------------------------ -----------------------------
Label 80045 80060
MTU 1500 1500
Control word enabled enabled
AC ID 22 12
EVPN type Ethernet Ethernet
------------ ------------------------------ -----------------------------
Create time: 10/07/2019 18:42:07 (00:45:49 ago)
Last time status changed: 10/07/2019 18:42:09 (00:45:47 ago)
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
Use the show segment-routing traffic-eng policy command with tabular option to display SR policy summary information.
The following output shows the on-demand SR policy with BSID 80047 that was triggered by EVPN RT1 prefix with color 10000
advertised by node B (10.1.1.6).
RP/0/RSP0/CPU0:Node-D# show segment-routing traffic-eng policy color 10000 tabular
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
1000010.1.1.6upup80047
The following output shows the details for the on-demand SR policy. Note that the SR policy's active candidate path (preference
100) is computed by SR-PCE (10.1.1.207).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE
services between site 1 and site 2. Specifically, from site 2 to site 1, LSP at Node D (srte_c_10000_ep_10.1.1.6) is link-disjoint
from LSP at Node C (srte_c_10000_ep_10.1.1.5).
Manually provisioned SR policies are configured on the head-end router. These policies can use dynamic paths or explicit paths.
See the SR-TE Policy Path Types section for information on manually provisioning an SR policy using dynamic or explicit paths.
PCE-Initiated SR Policy
An SR-TE policy can be configured on the path computation element (PCE) to reduce link congestion or to minimize the number
of network touch points.
The PCE collects network information, such as traffic demand and link utilization. When the PCE determines that a link is
congested, it identifies one or more flows that are causing the congestion. The PCE finds a suitable path and deploys an SR-TE
policy to divert those flows, without moving the congestion to another part of the network. When there is no more link congestion,
the policy is removed.
To minimize the number of network touch points, an application, such as a Network Services Orchestrator (NSO), can request
the PCE to create an SR-TE policy. PCE deploys the SR-TE policy using PCC-PCE communication protocol (PCEP).
A dynamic path is based on an optimization objective and a set of constraints. The head-end computes a solution, resulting in a SID-list
or a set of SID-lists. When the topology changes, a new path is computed. If the head-end does not have enough information
about the topology, the head-end might delegate the computation to a Segment Routing Path Computation Element (SR-PCE). For
information on configuring SR-PCE, see Configure Segment Routing Path Computation Element chapter.
An explicit path is a specified SID-list or set of SID-lists.
An SR-TE policy initiates a single (selected) path in RIB/FIB. This is the preferred valid candidate path. A path is selected
when the path is valid and its preference is the best among all candidate paths for that policy.
Note
The protocol of the source is not relevant in the path selection logic.
A candidate path has the following characteristics:
It has a preference – If two policies have the same {color, endpoint} but different preferences, the policy with the highest
preference is selected.
It is associated with a single binding SID (BSID) – A BSID conflict occurs when there are different SR policies with the same
BSID. In this case, the policy that is installed first gets the BSID and is selected.
It is valid if it is usable.
Dynamic Paths
Optimization Objectives
Optimization objectives allow the head-end router to compute a SID-list that expresses the shortest dynamic path according
to the selected metric type:
IGP metric — Refer to the "Implementing IS-IS" and "Implementing OSPF" chapters in the Routing Configuration Guide for Series Routers.
Constraints allow the head-end router to compute a dynamic path according to the selected metric type:
Affinity — You can apply a color or name to links or interfaces by assigning affinity bit-maps to them. You can then specify
an affinity (or relationship) between an SR policy path and link colors. SR-TE computes a path that includes or excludes links
that have specific colors,or combinations of colors. See the Named Interface Link Admin Groups and SR-TE Affinity Maps section for information on named interface link admin groups and SR-TE Affinity Maps.
Disjoint — SR-TE computes a path that is disjoint from another path in the same disjoint-group. Disjoint paths do not share
network resources. Path disjointness may be required for paths between the same pair of nodes, between different pairs of
nodes, or a combination (only same head-end or only same end-point).
Flexible Algorithm — Flexible Algorithm allows for user-defined algorithms where the IGP computes paths based on a user-defined
combination of metric type and constraint.
Named Interface Link Admin Groups and SR-TE Affinity Maps
Named Interface Link Admin Groups and SR-TE Affinity Maps provide a simplified and more flexible means of configuring link
attributes and path affinities to compute paths for SR-TE policies.
In the traditional TE scheme, links are configured with attribute-flags that are flooded with TE link-state parameters using
Interior Gateway Protocols (IGPs), such as Open Shortest Path First (OSPF).
Named Interface Link Admin Groups and SR-TE Affinity Maps let you assign, or map, up to color names for affinity and attribute-flag
attributes instead of 32-bit
hexadecimal numbers. After mappings are defined, the attributes can be referred to by
the corresponding color name in the CLI. Furthermore, you can define constraints using
include-any, include-all, and exclude-any arguments, where each
statement can contain up to 10 colors.
Note
You can configure affinity constraints using attribute flags or the Flexible Name Based Policy Constraints scheme; however,
when configurations for both schemes exist, only the configuration pertaining to the new scheme is applied.
Configure Named Interface Link Admin Groups and SR-TE Affinity Maps
Use the affinity nameNAME command in SR-TE interface submode to assign affinity to interfaces. Configure this on routers with interfaces that have
an associated admin group attribute.
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# interface TenGigE0/0/1/2
Router(config-sr-if)# affinity
Router(config-sr-if-affinity)# name RED
Use the affinity-map nameNAMEbit-positionbit-position command in SR-TE sub-mode to define affinity maps. The bit-position range is from 0 to 255.
Configure affinity maps on the following routers:
Routers with interfaces that have an associated admin group attribute.
Routers that act as SR-TE head-ends for SR policies that include affinity constraints.
The following example shows how to assign affinity to interfaces and to define affinity maps. This configuration is applicable
to any router (SR-TE head-end or transit node) with colored interfaces.
segment-routing
traffic-eng
interface TenGigE0/0/1/1
affinity
name CROSS
name RED
!
!
interface TenGigE0/0/1/2
affinity
name RED
!
!
interface TenGigE0/0/2/0
affinity
name BLUE
!
!
affinity-map
name RED bit-position 23
name BLUE bit-position 24
name CROSS bit-position 25
!
end
Configure SR Policy with Dynamic Path
To configure a SR-TE policy with a dynamic path, optimization objectives, and affinity constraints, complete the following
configurations:
Define the constraints. See the Constraints section.
Create the policy.
Behaviors and Limitations
Examples
The following example shows a configuration of an SR policy at an SR-TE head-end router. The policy has a dynamic path with
optimization objectives and affinity constraints computed by the head-end router.
segment-routing
traffic-eng
policy foo
color 100 end-point ipv4 10.1.1.2
candidate-paths
preference 100
dynamicmetrictype te
!
!
constraintsaffinityexclude-anyname RED
!
!
!
!
!
!
The following example shows a configuration of an SR policy at an SR-TE head-end router. The policy has a dynamic path with
optimization objectives and affinity constraints computed by the SR-PCE.
segment-routing
traffic-eng
policy baa
color 101 end-point ipv4 10.1.1.2
candidate-paths
preference 100
dynamicpcep
!
metrictype te
!
!
constraintsaffinityexclude-anyname BLUE
!
!
!
!
!
!
Explicit Paths
SR-TE Policy with Explicit Path
An explicit segment list is defined as a sequence of one or more segments. A segment can be configured as an IP address or
an MPLS label representing a node or a link.
An explicit segment list can be configured with the following:
IP-defined segments
MPLS label-defined segments
A combination of IP-defined segments and MPLS label-defined segments
Usage Guidelines and Limitations
An IP-defined segment can be associated with an IPv4 address (for example, a link or a Loopback address).
When a segment of the segment list is defined as an MPLS label, subsequent segments can only be configured as MPLS labels.
When configuring an explicit path using IP addresses of links along the path, the SR-TE process selects either the protected
or the unprotected Adj-SID of the link, depending on the order in which the Adj-SIDs were received.
Configure Local SR-TE Policy Using Explicit Paths
To configure an SR-TE policy with an explicit path, complete the following configurations:
Create the segment list.
Create the SR-TE policy.
Create a segment list with IPv4 addresses:
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# segment-list name SIDLIST1
Router(config-sr-te-sl)# index 10 address ipv4 10.1.1.2
Router(config-sr-te-sl)# index 20 address ipv4 10.1.1.3
Router(config-sr-te-sl)# index 30 address ipv4 10.1.1.4
Router(config-sr-te-sl)# exit
Create a segment list with MPLS labels:
Router(config-sr-te)# segment-list name SIDLIST2
Router(config-sr-te-sl)# index 10 mpls label 16002
Router(config-sr-te-sl)# index 20 mpls label 16003
Router(config-sr-te-sl)# index 30 mpls label 16004
Router(config-sr-te-sl)# exit
Create a segment list with IPv4 addresses and MPLS labels:
Router(config-sr-te)# segment-list name SIDLIST3
Router(config-sr-te-sl)# index 10 address ipv4 10.1.1.2
Router(config-sr-te-sl)# index 20 mpls label 16003
Router(config-sr-te-sl)# index 30 mpls label 16004
Router(config-sr-te-sl)# exit
Router# show running-configuration
segment-routing
traffic-eng
segment-list SIDLIST1
index 10 address ipv4 10.1.1.2
index 20 address ipv4 10.1.1.3
index 30 address ipv4 10.1.1.4
!
segment-list SIDLIST2
index 10 mpls label 16002
index 20 mpls label 16003
index 30 mpls label 16004
!
segment-list SIDLIST3
index 10 address ipv4 10.1.1.2
index 20 mpls label 16003
index 30 mpls label 16004
!
segment-list SIDLIST4
index 10 mpls label 16009
index 20 mpls label 16003
index 30 mpls label 16004
!
policy POLICY1
color 10 end-point ipv4 10.1.1.4
candidate-paths
preference 100
explicit segment-list SIDLIST1
!
!
!
!
policy POLICY2
color 20 end-point ipv4 10.1.1.4
candidate-paths
preference 100
explicit segment-list SIDLIST1
!
!
preference 200
explicit segment-list SIDLIST2
!
!
!
policy POLICY3
color 30 end-point ipv4 10.1.1.4
candidate-paths
preference 100
explicit segment-list SIDLIST3
!
!
!
!
!
!
Verification
Verify the SR-TE policy configuration using:
Router# show segment-routing traffic-eng policy name srte_c_20_ep_10.1.1.4
SR-TE policy database
---------------------
Color: 20, End-point: 10.1.1.4
Name: srte_c_20_ep_10.1.1.4
Status:
Admin: up Operational: up for 00:00:15 (since Jul 14 00:53:10.615)
Candidate-paths:
Preference: 200 (configuration) (active)
Name: POLICY2
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 8
Explicit: segment-list SIDLIST2 (active)
Weight: 1, Metric Type: TE
16002
16003
16004
Preference: 100 (configuration) (inactive)
Name: POLICY2
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 8
Explicit: segment-list SIDLIST1 (inactive)
Weight: 1, Metric Type: TE
[Adjacency-SID, 10.1.1.2 - <None>]
[Adjacency-SID, 10.1.1.3 - <None>]
[Adjacency-SID, 10.1.1.4 - <None>]
Attributes:
Binding SID: 51301
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
Configuring Explicit Path with Affinity Constraint Validation
To fully configure SR-TE flexible name-based policy constraints, you must complete these high-level tasks in order:
Assign Color Names to Numeric Values
Associate Affinity-Names with SR-TE Links
Associate Affinity Constraints for SR-TE Policies
/* Enter the global configuration mode and assign color names to numeric values
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# affinity-map
Router(config-sr-te-affinity-map)# blue bit-position 0
Router(config-sr-te-affinity-map)# green bit-position 1
Router(config-sr-te-affinity-map)# red bit-position 2
Router(config-sr-te-affinity-map)# exit
/* Associate affinity-names with SR-TE links
Router(config-sr-te)# interface Gi0/0/0/0
Router(config-sr-te-if)# affinity
Router(config-sr-te-if-affinity)# blue
Router(config-sr-te-if-affinity)# exit
Router(config-sr-te-if)# exit
Router(config-sr-te)# interface Gi0/0/0/1
Router(config-sr-te-if)# affinity
Router(config-sr-te-if-affinity)# blue
Router(config-sr-te-if-affinity)# green
Router(config-sr-te-if-affinity)# exit
Router(config-sr-te-if)# exit
Router(config-sr-te)#
/* Associate affinity constraints for SR-TE policies
Router(config-sr-te)# segment-list name SIDLIST1
Router(config-sr-te-sl)# index 10 address ipv4 10.1.1.2
Router(config-sr-te-sl)# index 20 address ipv4 2.2.2.23
Router(config-sr-te-sl)# index 30 address ipv4 10.1.1.4
Router(config-sr-te-sl)# exit
Router(config-sr-te)# segment-list name SIDLIST2
Router(config-sr-te-sl)# index 10 address ipv4 10.1.1.2
Router(config-sr-te-sl)# index 30 address ipv4 10.1.1.4
Router(config-sr-te-sl)# exit
Router(config-sr-te)# segment-list name SIDLIST3
Router(config-sr-te-sl)# index 10 address ipv4 10.1.1.5
Router(config-sr-te-sl)# index 30 address ipv4 10.1.1.4
Router(config-sr-te-sl)# exit
Router# show running-configuration
segment-routing
traffic-eng
interface GigabitEthernet0/0/0/0
affinity
blue
!
!
interface GigabitEthernet0/0/0/1
affinity
blue
green
!
!
segment-list name SIDLIST1
index 10 address ipv4 10.1.1.2
index 20 address ipv4 2.2.2.23
index 30 address ipv4 10.1.1.4
!
segment-list name SIDLIST2
index 10 address ipv4 10.1.1.2
index 30 address ipv4 10.1.1.4
!
segment-list name SIDLIST3
index 10 address ipv4 10.1.1.5
index 30 address ipv4 10.1.1.4
!
policy POLICY1
binding-sid mpls 1000
color 20 end-point ipv4 10.1.1.4
candidate-paths
preference 100
explicit segment-list SIDLIST3
!
!
preference 200
explicit segment-list SIDLIST1
!
explicit segment-list SIDLIST2
!
constraints
affinity
exclude-any
red
!
!
!
!
!
!
affinity-map
blue bit-position 0
green bit-position 1
red bit-position 2
!
!
!
Protocols
Path Computation Element Protocol
The path computation element protocol (PCEP) describes a set of procedures by which a path computation client (PCC) can report
and delegate control of head-end label switched paths (LSPs) sourced from the PCC to a PCE peer. The PCE can request the PCC
to update and modify parameters of LSPs it controls. The stateful model also enables a PCC to allow the PCE to initiate computations
allowing the PCE to perform network-wide orchestration.
Configure the Head-End Router as PCEP PCC
Configure the head-end router as PCEP Path Computation Client (PCC) to establish a connection to the PCE. The PCC and PCE
addresses must be routable so that TCP connection (to exchange PCEP messages) can be established between PCC and PCE.
Configure the PCC to Establish a Connection to the PCE
Use the segment-routing traffic-eng pcc command to configure the PCC source address, the SR-PCE address, and SR-PCE options.
A PCE can be given an optional precedence. If a PCC is connected to multiple PCEs, the PCC selects a PCE with the lowest precedence
value. If there is a tie, a PCE with the highest IP address is chosen for computing path. The precedence value range is from 0 to 255.
Use the timers keepalive command to specify how often keepalive messages are sent from PCC to its peers. The range is from 0 to 255 seconds; the default
value is 30.
Router(config-sr-te-pcc)# timers keepaliveseconds
Use the timers deadtimer command to specify how long the remote peers wait before bringing down the PCEP session if no PCEP messages are received
from this PCC. The range is from 1 to 255 seconds; the default value is 120.
Router(config-sr-te-pcc)# timers deadtimerseconds
Use the timers delegation-timeout command to specify how long a delegated SR policy can remain up without an active connection to a PCE. The range is from
0 to 3600 seconds; the default value is 60.
Use the timers initiated orphans command to specify the amount of time that a PCE-initiated SR policy will remain delegated to a PCE peer that is no longer
reachable by the PCC. The range is from 10 to 180 seconds; the default value is 180.
Use the timers initiated state command to specify the amount of time that a PCE-initiated SR policy will remain programmed while not being delegated to
any PCE. The range is from 15 to 14440 seconds (24 hours); the default value is 600.
To better understand how the PCE-initiated SR policy timers operate, consider the following example:
PCE A instantiates SR policy P at head-end N.
Head-end N delegates SR policy P to PCE A and programs it in forwarding.
If head-end N detects that PCE A is no longer reachable, then head-end N starts the PCE-initiated orphan and state timers for SR policy P.
If PCE A reconnects before the orphan timer expires, then SR policy P is automatically delegated back to its original PCE (PCE A).
After the orphan timer expires, SR policy P will be eligible for delegation to any other surviving PCE(s).
If SR policy P is not delegated to another PCE before the state timer expires, then head-end N will remove SR policy P from its forwarding.
Enable SR-TE SYSLOG Alarms
Use the logging policy status command to enable SR-TE related SYSLOG alarms.
Router(config-sr-te)# logging policy status
Enable PCEP Reports to SR-PCE
Use the report-all command to enable the PCC to report all SR policies in its database to the PCE.
Router(config-sr-te-pcc)# report-all
Customize MSD Value at PCC
Use the maximum-sid-depthvalue command to customize the Maximum SID Depth (MSD) signaled by PCC during PCEP session establishment.
The default MSD value is equal to the maximum MSD supported by the platform ().
Router(config-sr-te)# maximum-sid-depthvalue
For cases with path computation at PCE, a PCC can signal its MSD to the PCE in the following ways:
During PCEP session establishment – The signaled MSD is treated as a node-wide property.
MSD is configured under segment-routing traffic-eng maximum-sid-depthvalue command
During PCEP LSP path request – The signaled MSD is treated as an LSP property.
On-demand (ODN) SR Policy: MSD is configured using the segment-routing traffic-eng on-demand colorcolormaximum-sid-depthvalue command
Local SR Policy: MSD is configured using the segment-routing traffic-eng policyWORDcandidate-paths preferencepreferencedynamic metric sid-limitvalue command.
Note
If the configured MSD values are different, the per-LSP MSD takes precedence over the per-node MSD.
After path computation, the resulting label stack size is verified against the MSD requirement.
If the label stack size is larger than the MSD and path computation is performed by PCE, then the PCE returns a "no path"
response to the PCC.
If the label stack size is larger than the MSD and path computation is performed by PCC, then the PCC will not install the
path.
Note
A sub-optimal path (if one exists) that satisfies the MSD constraint could be computed in the following cases:
For a dynamic path with TE metric, when the PCE is configured with the pce segment-routing te-latency command or the PCC is configured with the segment-routing traffic-eng te-latency command.
For a dynamic path with LATENCY metric
For a dynamic path with affinity constraints
For example, if the PCC MSD is 4 and the optimal path (with an accumulated metric of 100) requires 5 labels, but a sub-optimal
path exists (with accumulated metric of 110) requiring 4 labels, then the sub-optimal path is installed.
Customize the SR-TE Path Calculation
Use the te-latency command to enable ECMP-aware path computation for TE metric.
Router(config-sr-te)# te-latency
Note
ECMP-aware path computation is enabled by default for IGP and LATENCY metrics.
Configure PCEP Redundancy Type
Use the redundancy pcc-centric command to enable PCC-centric high-availability model. The PCC-centric model changes the default PCC delegation behavior
to the following:
After LSP creation, LSP is automatically delegated to the PCE that computed it.
If this PCE is disconnected, then the LSP is redelegated to another PCE.
If the original PCE is reconnected, then the delegation fallback timer is started. When the timer expires, the LSP is redelegated
back to the original PCE, even if it has worse preference than the current PCE.
Router(config-sr-te-pcc)# redundancy pcc-centric
Configuring Head-End Router as PCEP PCC and Customizing SR-TE Related Options: Example
The following example shows how to configure an SR-TE head-end router with the following functionality:
Enable the SR-TE head-end router as a PCEP client (PCC) with 3 PCEP servers (PCE) with different precedence values. The PCE
with IP address 10.1.1.57 is selected as BEST.
Enable SR-TE related syslogs.
Set the Maximum SID Depth (MSD) signaled during PCEP session establishment to 5.
Enable PCEP reporting for all policies in the node.
RP/0/RSP0/CPU0:Router# show segment-routing traffic-eng pcc ipv4 peer
PCC's peer database:
--------------------
Peer address: 10.1.1.57, Precedence: 150, (best PCE)
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 10.1.1.58, Precedence: 200
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 10.1.1.59, Precedence: 250
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
BGP SR-TE
BGP may be used to distribute SR Policy candidate paths to an SR-TE head-end. Dedicated BGP SAFI and NLRI have been defined
to advertise a candidate path of an SR Policy. The advertisement of Segment Routing policies in BGP is documented in the IETF
drafthttps://datatracker.ietf.org/doc/draft-ietf-idr-segment-routing-te-policy/
SR policies with IPv4 and IPv6 end-points can be advertised over BGPv4 or BGPv6 sessions between the SR-TE controller and
the SR-TE headend.
The Cisco IOS-XR implementation supports the following combinations:
IPv4 SR policy advertised over BGPv4 session
IPv6 SR policy advertised over BGPv4 session
IPv6 SR policy advertised over BGPv6 session
Configure BGP SR Policy Address Family at SR-TE Head-End
Perform this task to configure BGP SR policy address family at SR-TE head-end:
SUMMARY STEPS
configure
router bgpas-number
bgp router-idip-address
address-family { ipv4 | ipv6} sr-policy
exit
neighborip-address
remote-asas-number
address-family { ipv4 | ipv6} sr-policy
route-policyroute-policy-name { in | out}
DETAILED STEPS
Command or Action
Purpose
Step 1
configure
Step 2
router bgpas-number
Example:
RP/0/RSP0/CPU0:router(config)# router bgp 65000
Specifies the BGP AS number and enters the BGP configuration mode, allowing you to configure the BGP routing process.
Specifies either the IPv4 or IPv6 address family and enters address family configuration submode.
Step 9
route-policyroute-policy-name { in | out}
Example:
RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# route-policy pass out
Applies the specified policy to IPv4 or IPv6 unicast routes.
Example: BGP SR-TE with BGPv4 Neighbor to BGP SR-TE Controller
The following configuration shows the an SR-TE head-end with a BGPv4 session towards a BGP SR-TE controller. This BGP session
is used to signal both IPv4 and IPv6 SR policies.
router bgp 65000
bgp router-id 10.1.1.1
!
address-family ipv4 sr-policy
!
address-family ipv6 sr-policy
!
neighbor 10.1.3.1
remote-as 10
description *** eBGP session to BGP SRTE controller ***
address-family ipv4 sr-policy
route-policy pass in
route-policy pass out
!
address-family ipv6 sr-policy
route-policy pass in
route-policy pass out
!
!
!
Example: BGP SR-TE with BGPv6 Neighbor to BGP SR-TE Controller
The following configuration shows an SR-TE head-end with a BGPv6 session towards a
BGP SR-TE controller. This BGP session is used to signal IPv6 SR policies.
Automated steering (AS) allows service traffic to be automatically steered onto the required transport SLA path programmed
by an SR policy.
With AS, BGP automatically steers traffic onto an SR Policy based on the next-hop and color of a BGP service route. The color
of a BGP service route is specified by a color extended community attribute. This color is used as a transport SLA indicator,
such as min-delay or min-cost.
When the next-hop and color of a BGP service route matches the end-point and color of an SR Policy, BGP automatically installs
the route resolving onto the BSID of the matching SR Policy. Recall that an SR Policy on a head-end is uniquely identified
by an end-point and color.
When a BGP route has multiple extended-color communities, each with a valid SR Policy, the BGP process installs the route
on the SR Policy giving preference to the color with the highest numerical value.
The granularity of AS behaviors can be applied at multiple levels, for example:
At a service level—When traffic destined to all prefixes in a given service is associated to the same transport path type.
All prefixes share the same color.
At a destination/prefix level—When traffic destined to a prefix in a given service is associated to a specific transport path
type. Each prefix could be assigned a different color.
At a flow level—When flows destined to the same prefix are associated with different transport path types
AS behaviors apply regardless of the instantiation method of the SR policy, including:
On-demand SR policy
Manually provisioned SR policy
PCE-initiated SR policy
Per-Flow Automated Steering
The steering of traffic through a Segment Routing (SR) policy is based on the candidate paths of that policy. For a given
policy, a candidate path specifies the path to be used to steer traffic to the policy’s destination. The policy determines
which candidate path to use based on the candidate path’s preference and state. The candidate path that is valid and has the
highest preference is used to steer all traffic using the given policy. This type of policy is called a Per-Destination Policy
(PDP).
Per-Flow Automated Traffic Steering using SR-TE Policies introduces a way to steer traffic on an SR policy based on the attributes
of the incoming packets, called a Per-Flow Policy (PFP).
A PFP provides up to 8 "ways" or options to the endpoint. With a PFP, packets are classified by a classification policy and
marked using internal tags called forward classes (FCs). The FC setting of the packet selects the “way”. For example, this
“way” can be a traffic-engineered SR path, using a low-delay path to the endpoint. The FC is represented as a numeral with
a value of 0 to 7.
A PFP defines an array of FC-to-PDP mappings. A PFP can then be used to steer traffic into a given PDP based on the FC assigned
to a packet.
As with PDPs, PFPs are identified by a {headend, color, endpoint} tuple. The color associated with a given FC corresponds
to a valid PDP policy of that color and same endpoint as the parent PFP. So PFP policies contain mappings of different FCs
to valid PDP policies of different colors. Every PFP has an FC designated as its default FC. The default FC is associated
to packets with a FC undefined under the PFP or for packets with a FC with no valid PDP policy.
The following example shows a per-flow policy from Node1 to Node4:
Figure 2. PFP Example
FC=0 -> shortest path to Node4
IGP shortest path = 16004
FC=1 -> Min-delay path to Node4
SID list = {16002,16004}
The same on-demand instantiation behaviors of PDPs apply to PFPs. For example, an edge node automatically (on demand) instantiates
Per-Flow SR Policy paths to an endpoint by service route signaling. Automated Steering steers the service route in the matching
SR Policy.
Figure 3. PFP with ODN Example
Like PDPs, PFPs have a binding SID (BSID). Existing SR-TE automated steering (AS) mechanisms for labeled traffic (via BSID)
and unlabeled traffic (via BGP) onto a PFP is similar to that of a PDP. For example, a packet having the BSID of a PFP as
the top label is steered onto that PFP. The classification policy on the ingress interface marks the packet with an FC based
on the configured class-map. The packet is then steered to the PDP that corresponds to that FC.
Usage Guidelines and Limitations
The following guidelines and limitations apply to the platform when acting as a head-end of a PFP policy:
BGP IPv4 unicast over PFP (steered via ODN/AS) is supported
BGP IPv6 unicast (with IPv4 next-hop [6PE]) over PFP (steered via ODN/AS) is supported
BGP IPv6 unicast (with IPv6 next-hop) over PFP (steered via ODN/AS) is supported
BGP EVPN over PFP is not supported
Pseudowire and VPLS over PFP are not supported
BGP PIC is not supported
When not explicitly configured, FC 0 is the default FC.
A PFP is considered valid as long as its default FC has a valid PDP.
The following counters are supported:
PFP’s BSID counter (packet, bytes)
Per-FC counters (packet, byte)
Collected from the PDP’s segment-list-per-path egress counters
If an SR policy is used for more than one purpose (as a regular policy as well as a PDP under one or more PFPs), then the
collected counters will represent the aggregate of all contributions. To preserve independent counters, it is recommended
that an SR policy be used only for one purpose.
Inbound packet classification, based on the following fields, is supported:
A color associated with a PFP SR policy cannot be used by a non-PFP SR policy. For example, if a per-flow ODN template for
color 100 is configured, then the system will reject the configuration of any non-PFP SR policy using the same color. You
must assign different color value ranges for PFP and non-PFP SR policies.
Configuring ODN Template for PFP Policies: Example
The following example depicts an ODN template for PFP policies that includes three FCs.
The example also includes the corresponding ODN templates for PDPs as follows:
FC0 (default FC) mapped to color 10 = Min IGP path
FC1 mapped to color 20 = Flex Algo 128 path
FC2 mapped to color 30 = Flex Algo 129 path
segment-routing
traffic-eng
on-demand color 10
dynamic
metric
type igp
!
!
!
on-demand color 20
dynamic
sid-algorithm 128
!
!
on-demand color 30
dynamic
sid-algorithm 129
!
!
on-demand color 1000per-flowforward-class 0 color 10forward-class 1 color 20forward-class 2 color 30
Manually Configuring a PFP and PDPs: Example
The following example depicts a manually defined PFP that includes three FCs and corresponding manually defined PDPs.
The example also includes the corresponding PDPs as follows:
FC0 (default FC) mapped to color 10 = Min IGP path
FC1 mapped to color 20 = Min TE path
FC2 mapped to color 30 = Min delay path
segment-routing
traffic-eng
policy MyPerFlow
color 1000 end-point ipv4 10.1.1.4
candidate-paths
preference 100
per-flowforward-class 0 color 10forward-class 1 color 20forward-class 2 color 30
!
policy MyLowIGP
color 10 end-point ipv4 10.1.1.4
candidate-paths
preference 100
dynamic
metric type igp
!
policy MyLowTE
color 20 end-point ipv4 10.1.1.4
candidate-paths
preference 100
dynamic
metric type te
!
policy MyLowDelay
color 30 end-point ipv4 10.1.1.4
candidate-paths
preference 100
dynamic
metric type delay
Determining Per-Flow Policy State
A PFP is brought down for the following reasons:
The PDP associated with the default FC is in a down state.
All FCs are associated with PDPs in a down state.
The FC assigned as the default FC is missing in the forward class mapping.
Scenario 1—FC 0 (default FC) is not configured in the FC mappings below:
policy foo
color 1 end-point ipv4 10.1.1.1
per-flow
forward-class 1 color 10
forward-class 2 color 20
Scenario 2—FC 1 is configured as the default FC, however it is not present in the FC mappings:
policy foo
color 1 end-point ipv4 10.1.1.1
per-flow
forward-class 0 color 10
forward-class 2 color 20
forward-class default 1
Using Binding Segments
The binding segment is a local segment identifying an SR-TE policy. Each SR-TE policy is associated with a binding segment
ID (BSID). The BSID is a local label that is automatically allocated for each SR-TE policy when the SR-TE policy is instantiated.
BSID can be used to steer traffic into the SR-TE policy and across domain borders, creating seamless end-to-end inter-domain
SR-TE policies. Each domain controls its local SR-TE policies; local SR-TE policies can be validated and rerouted if needed,
independent from the remote domain’s head-end. Using binding segments isolates the head-end from topology changes in the remote
domain.
Packets received with a BSID as top label are steered into the SR-TE policy associated with the BSID. When the BSID label
is popped, the SR-TE policy’s SID list is pushed.
BSID can be used in the following cases:
Multi-Domain (inter-domain, inter-autonomous system)—BSIDs can be used to steer traffic across domain borders, creating seamless
end-to-end inter-domain SR-TE policies.
Large-Scale within a single domain—The head-end can use hierarchical SR-TE policies by nesting the end-to-end (edge-to-edge)
SR-TE policy within another layer of SR-TE policies (aggregation-to-aggregation). The SR-TE policies are nested within another
layer of policies using the BSIDs, resulting in seamless end-to-end SR-TE policies.
Label stack compression—If the label-stack size required for an SR-TE policy exceeds the platform capability, the SR-TE policy
can be seamlessly stitched to, or nested within, other SR-TE policies using a binding segment.
BGP SR-TE Dynamic—The head-end steers the packet into a BGP-based FIB entry whose next hop is a binding-SID.
Explicit Binding SID
Use the binding-sid mplslabel command in SR-TE policy configuration mode to specify the explicit BSID. Explicit BSIDs are allocated from the segment routing
local block (SRLB) or the dynamic range of labels. A best-effort is made to request and obtain the BSID for the SR-TE policy.
If requested BSID is not available (if it does not fall within the available SRLB or is already used by another application
or SR-TE policy), the policy stays down.
Use the binding-sid explicit {fallback-dynamic | enforce-srlb} command to specify how the BSID allocation behaves if the BSID value is not available.
Fallback to dynamic allocation – If the BSID is not available, the BSID is allocated dynamically and the policy comes up:
This example shows how to configure an SR policy to use an explicit BSID of 1000. If the BSID is not available, the BSID is
allocated dynamically and the policy comes up.
Stitching SR-TE Polices Using Binding SID: Example
In this example, three SR-TE policies are stitched together to form a seamless end-to-end path from node 1 to node 10. The
path is a chain of SR-TE policies stitched together using the binding-SIDs of intermediate policies, providing a seamless
end-to-end path.
Figure 4. Stitching SR-TE Polices Using Binding SID
Procedure
Step 1
On node 5, do the following:
Define an SR-TE policy with an explicit path configured using the loopback interface IP addresses of node 9 and node 10.
Define an explicit binding-SID (mpls label 15888) allocated from SRLB for the SR-TE policy.
Define an SR-TE policy with an explicit path configured using the following:
Loopback interface IP address of node 4
Interface IP address of link between node 4 and node 6
Loopback interface IP address of node 5
Binding-SID of the SR-TE policy defined in Step 1 (mpls label 15888)
Note
This last segment allows the stitching of these policies.
Define an explicit binding-SID (mpls label 15900) allocated from SRLB for the SR-TE policy.
Example:
Node 3
segment-routing
traffic-eng
segment-list PATH-4_4-6_5_BSID
index 10 address ipv4 10.1.1.4
index 20 address ipv4 10.4.6.6
index 30 address ipv4 10.1.1.5
index 40 mpls label 15888
!
policy baa
binding-sid mpls 15900
color 777 end-point ipv4 10.1.1.5
candidate-paths
preference 100
explicit segment-list PATH-4_4-6_5_BSID
!
!
!
!
!
!
RP/0/RSP0/CPU0:Node-3# show segment-routing traffic-eng policy color 777
SR-TE policy database
---------------------
Color: 777, End-point: 10.1.1.5
Name: srte_c_777_ep_10.1.1.5
Status:
Admin: up Operational: up for 00:00:32 (since Aug 19 07:40:32.662)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: baa
Requested BSID: 15900
PCC info:
Symbolic name: cfg_baa_discr_100
PLSP-ID: 70
Explicit: segment-list PATH-4_4-6_5_BSID (valid)
Weight: 1, Metric Type: TE
16004 [Prefix-SID, 10.1.1.4]
80005 [Adjacency-SID, 10.4.6.4 - 10.4.6.6]
16005 [Prefix-SID, 10.1.1.5]
15888
Attributes:
Binding SID: 15900 (SRLB)
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Step 3
On node 1, define an SR-TE policy with an explicit path configured using the loopback interface IP address of node 3 and the
binding-SID of the SR-TE policy defined in step 2 (mpls label 15900). This last segment allows the stitching of these policies.
Example:
Node 1
segment-routing
traffic-eng
segment-list PATH-3_BSID
index 10 address ipv4 10.1.1.3
index 20 mpls label 15900
!
policy bar
color 777 end-point ipv4 10.1.1.3
candidate-paths
preference 100
explicit segment-list PATH-3_BSID
!
!
!
!
!
!
RP/0/RSP0/CPU0:Node-1# show segment-routing traffic-eng policy color 777
SR-TE policy database
---------------------
Color: 777, End-point: 10.1.1.3
Name: srte_c_777_ep_10.1.1.3
Status:
Admin: up Operational: up for 00:00:12 (since Aug 19 07:40:52.662)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: bar
Requested BSID: dynamic
PCC info:
Symbolic name: cfg_bar_discr_100
PLSP-ID: 70
Explicit: segment-list PATH-3_BSID (valid)
Weight: 1, Metric Type: TE
16003 [Prefix-SID, 10.1.1.3]
15900
Attributes:
Binding SID: 80021
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
L2VPN Preferred Path
EVPN VPWS Preferred Path over SR-TE Policy feature allows you to set the preferred path between the two end-points for EVPN
VPWS pseudowire (PW) using SR-TE policy.
L2VPN VPLS or VPWS Preferred Path over SR-TE Policy feature allows you to set the preferred path between the two end-points
for L2VPN Virtual Private LAN Service (VPLS) or Virtual Private Wire Service (VPWS) using SR-TE policy.
Policy-Based Tunnel Selection (PBTS) is a mechanism that lets you direct traffic into specific SR-TE policies based on different
classification criteria. PBTS benefits Internet service providers (ISPs) that carry voice and data traffic through their networks,
who want to route this traffic to provide optimized voice service.
PBTS works by selecting SR-TE policies based on the classification criteria of the incoming packets, which are based on the
IP precedence, experimental (EXP), differentiated services code point (DSCP), or type of service (ToS) field in the packet.
Default-class configured for paths is always zero (0). If there is no TE for a given forward-class, then the default-class
(0) will be tried. If there is no default-class, then the packet is dropped. PBTS supports up to seven (exp 1 - 7) EXP values
associated with a single SR-TE policy.
For more information about PBTS, refer to the "Policy-Based Tunnel Selection" section in the
MPLS Configuration Guide for Cisco NCS 6000 Series RoutersMPLS Configuration Guide.
Configure Policy-Based Tunnel Selection for SR-TE Policies
The following section lists the steps to configure PBTS for an SR-TE policy.
Note
Steps 1 through 4 are detailed in the "Implementing MPLS Traffic Engineering" chapter of the
MPLS Configuration Guide for Cisco NCS 6000 Series RoutersMPLS Configuration Guide.
Define a class-map based on a classification criteria.
Define a policy-map by creating rules for the classified traffic.
Associate a forward-class to each type of ingress traffic.
Enable PBTS on the ingress interface, by applying this service-policy.
Create one or more egress SR-TE policies (to carry packets based on priority) to the destination and associate the egress
SR-TE policy to a forward-class.
Configuration Example
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# policy POLICY-PBTS
Router(config-sr-te-policy)# color 1001 end-point ipv4 10.1.1.20
Router(config-sr-te-policy)# autoroute
Router(config-sr-te-policy-autoroute)# include all
Router(config-sr-te-policy-autoroute)# forward-class 1
Router(config-sr-te-policy-autoroute)# exit
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 1
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST1
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-policy-path)# preference 2
Router(config-sr-te-policy-path-pref)# dynamic
Router(config-sr-te-pp-info)# metric
Router(config-sr-te-path-metric)# type te
Router(config-sr-te-path-metric)# commit
Running Configuration
segment-routing
traffic-eng
policy POLICY-PBTS
color 1001 end-point ipv4 10.1.1.20
autoroute
include all
forward-class 1
!
candidate-paths
preference 1
explicit segment-list SIDLIST1
!
!
preference 2
dynamic
metric
type te
Miscellaneous
LDP over Segment Routing Policy
The LDP over Segment Routing Policy feature enables an LDP-targeted adjacency over a Segment Routing (SR) policy between two
routers. This feature extends the existing MPLS LDP address family neighbor configuration to specify an SR policy as the targeted
end-point.
LDP over SR policy is supported for locally configured SR policies with IPv4 end-points.
For more information about MPLS LDP, see the "Implementing MPLS Label Distribution Protocol" chapter in the MPLS Configuration Guide.
For more information about Autoroute, see the Autoroute Announce for SR-TE
section.
Note
Before you configure an LDP targeted adjacency over SR policy name, you need to create the SR policy under Segment Routing
configuration. The SR policy interface names are created internally based on the color and endpoint of the policy. LDP is
non-operational if SR policy name is unknown.
The following functionality applies:
Configure the SR policy – LDP receives the associated end-point address from the interface manager (IM) and stores it in the
LDP interface database (IDB) for the configured SR policy.
Configure the SR policy name under LDP – LDP retrieves the stored end-point address from the IDB and uses it. Use the auto-generated
SR policy name assigned by the router when creating an LDP targeted adjacency over an SR policy. Auto-generated SR policy
names use the following naming convention: srte_c_color_val_ep_endpoint-address. For example, srte_c_1000_ep_10.1.1.2
Configuration Example
/* Enter the SR-TE configuration mode and create the SR policy. This example corresponds to a local SR policy with an explicit path. */
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# segment-list sample-sid-list
Router(config-sr-te-sl)# index 10 address ipv4 10.1.1.7
Router(config-sr-te-sl)# index 20 address ipv4 10.1.1.2
Router(config-sr-te-sl)# exit
Router(config-sr-te)# policy sample_policy
Router(config-sr-te-policy)# color 1000 end-point ipv4 10.1.1.2
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# explicit segment-list sample-sid-list
Router(config-sr-te-pp-info)# end
/* Configure LDP over an SR policy */
Router(config)# mpls ldp
Router(config-ldp)# address-family ipv4
Router(config-ldp-af)# neighbor sr-policy srte_c_1000_ep_10.1.1.2 targeted
Router(config-ldp-af)#
Note
Do one of the following to configure LDP discovery for targeted hellos:
Bidirectional forwarding detection (BFD) provides low-overhead, short-duration detection of failures in the path between adjacent
forwarding engines. BFD allows a single mechanism to be used for failure detection over any media and at any protocol layer,
with a wide range of detection times and overhead. The fast detection of failures provides immediate reaction to failure in
the event of a failed link or neighbor.
In BFD, each end of the connection maintains a BFD state and transmits packets periodically over a forwarding path. Seamless
BFD (SBFD) is unidirectional, resulting in faster session activation than BFD. The BFD state and client context is maintained
on the head-end (initiator) only. The tail-end (reflector) validates the BFD packet and responds, so there is no need to maintain
the BFD state on the tail-end.
Initiators and Reflectors
SBFD runs in an asymmetric behavior, using initiators and reflectors.
The following figure represents the roles of the SBFD initiator and reflector.
Figure 5. SBFD Initiator and Reflector
The initiator is an SBFD session on a network node that performs a continuity test to a remote entity by sending SBFD packets.
The initiator injects the SBFD packets into the segment-routing traffic-engineering (SRTE) policy. The initiator triggers
the SBFD session and maintains the BFD state and client context.
The reflector is an SBFD session on a network node that listens for incoming SBFD control packets to local entities and generates
response SBFD control packets. The reflector is stateless and only reflects the SBFD packets back to the initiator.
A node can be both an initiator and a reflector, if you want to configure different SBFD sessions.
For SR-TE, SBFD control packets are label switched in forward and reverse direction. For SBFD, the tail-end node is the reflector
node; other nodes cannot be a reflector. When using SBFD with SR-TE, if the forward and return directions are label-switched
paths, SBFD need not be configured on the reflector node.
Discriminators
The BFD control packet carries 32-bit discriminators (local and remote) to demultiplex BFD sessions. SBFD requires globally
unique SBFD discriminators that are known by the initiator.
The SBFD control packets contain the discriminator of the initiator, which is created dynamically, and the discriminator of
the reflector, which is configured as a local discriminator on the reflector.
Configure the SBFD Reflector
To ensure the SBFD packet arrives on the intended reflector, each reflector has at least one globally unique discriminator.
Globally unique discriminators of the reflector are known by the initiator before the session starts. An SBFD reflector only
accepts BFD control packets where "Your Discriminator" is the reflector discriminator.
This task explains how to configure local discriminators on the reflector.
Before you begin
Enable mpls oam on the reflector to install a routing information base (RIB) entry for 127.0.0.0/8.
Configures the local discriminator. You can configure multiple local discriminators.
Step 4
commit
Verify the local discriminator configuration.
Example
Router_5# show bfd target-identifier local
Local Target Identifier Table
-----------------------------
Discr Discr Src VRF Status Flags
Name
----- --------- ------- -------- --------
16843013 Local default enable -----ia-
987654321 Local default enable ----v---
2147483649 Local default enable -------d
Legend: TID - Target Identifier
a - IP Address mode
d - Dynamic mode
i - Interface mode
v - Explicit Value mode
What to do next
Configure the SBFD initiator.
Configure the SBFD Initiator
Perform the following configurations on the SBFD initiator.
Enable Line Cards to Host BFD Sessions
The SBFD initiator sessions are hosted by the line card CPU.
This task explains how to enable line cards to host BFD sessions.
SUMMARY STEPS
configure
bfd
multipath include locationnode-id
DETAILED STEPS
Command or Action
Purpose
Step 1
configure
Example:
RP/0/RP0/CPU0:router# configure
Enters
XR Config mode.
Step 2
bfd
Example:
Router_1(config)# bfd
Enters BFD configuration mode.
Step 3
multipath include locationnode-id
Example:
Router_1(config-bfd)# multipath include location 0/1/CPU0
Router_1(config-bfd)# multipath include location 0/2/CPU0
Router_1(config-bfd)# multipath include location 0/3/CPU0
Configures BFD multiple path on specific line card. Any of the configured line cards can be instructed to host a BFD session.
What to do next
Map a destination address to a remote discriminator.
Map a Destination Address to a Remote Discriminator
The SBFD initiator uses a Remote Target Identifier (RTI) table to map a destination address (Target ID) to a remote discriminator.
This task explains how to map a destination address to a remote discriminator.
Maps the destination address (Target ID) to a remote discriminator.
Verify the remote discriminator configuration.
Example
Router_1# show bfd target-identifier remote
Remote Target Identifier Table
------------------------------
Discr Discr Src VRF TID Type Status
Target ID Name
------ --------- ------- -------- ------
16843013 Remote default ipv4 enable
10.1.1.5
Legend: TID - Target Identifier
What to do next
Enable SBFD on an SR-TE policy.
Enable Seamless BFD Under an SR-TE Policy or SR-ODN Color Template
This example shows how to enable SBFD on an SR-TE policy or an SR on-demand (SR-ODN) color template.
Note
Do not use BFD with disjoint paths. The reverse path might not be disjoint, causing a single link failure to bring down BFD
sessions on both the disjoint paths.
Enable BFD
Use the bfd command in SR-TE policy configuration mode to enable BFD and enters BFD configuration mode.
Use the bfd command in SR-ODN configuration mode to enable BFD and enters BFD configuration mode.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# on-demand color 10
Router(config-sr-te-color)# bfd
Router(config-sr-te-color-bfd)#
Configure BFD Options
Use the minimum-intervalmilliseconds command to set the interval between sending BFD hello packets to the neighbor. The range is from 15 to 200. The default is
15.
Use the multipliermultiplier command to set the number of times a packet is missed before BFD declares the neighbor down. The range is from 2 to 10. The
default is 3.
Router(config-sr-te-policy-bfd)# multiplier 2
Use the invalidation-action {down | none} command to set the action to be taken when BFD session is invalidated.
down: LSP can only be operationally up if the BFD session is up
none: BFD session state does not affect LSP state, use for diagnostic purposes
Router(config-sr-te-policy-bfd)# invalidation-action down
(SR-TE policy only) Use the reverse-path binding-labellabel command to specify BFD packets return to head-end by using a binding label.
By default, the S-BFD return path (from tail-end to head-end) is via IPv4. You can use a reverse binding label so that the
packet arrives at the tail-end with the reverse binding label as the top label. This label is meant to point to a policy that
will take the BFD packets back to the head-end. The reverse binding label is configured per-policy.
Note that when MPLS return path is used, BFD uses echo mode packets, which means the tail-end’s BFD reflector does not process
BFD packets at all.
The MPLS label value at the tail-end and the head-end must be synchronized by the operator or controller. Because the tail-end
binding label should remain constant, configure it as an explicit BSID, rather than dynamically allocated.
This example shows how to enable SBFD on an SR-ODN color.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# on-demand color 10
Router(config-sr-te-color)# bfd
Router(config-sr-te-color-bfd)# minimum-interval 50
Router(config-sr-te-color-bfd)# multiplier 2
Router(config-sr-te-color-bfd)# logging session-state-change
Router(config-sr-te-color-bfd)# invalidation-action down
segment-routing
traffic-eng
on-demand color 10
bfd
minimum-interval 50
multiplier 2
invalidation-action down
logging
session-state-change
!
!
!
!
!
SR-TE Reoptimization Timers
SR-TE path re-optimization occurs when the head-end determines that there is a more optimal path available than the one currently
used. For example, in case of a failure along the SR-TE LSP path, the head-end could detect and revert to a more optimal path
by triggering re-optimization.
Re-optimization can occur due to the following events:
The explicit path hops used by the primary SR-TE LSP explicit path are modified
The head-end determines the currently used path-option are invalid due to either a topology path disconnect, or a missing
SID in the SID database that is specified in the explicit-path
A more favorable path-option (lower index) becomes available
For event-based re-optimization, you can specify various delay timers for path re-optimization. For example, you can specify
how long to wait before switching to a reoptimized path
Additionally, you can configure a timer to specify how often to perform reoptimization of policies. You can also trigger an
immediate reoptimization for a specific policy or for all policies.
SR-TE Reoptimization
To trigger an immediate SR-TE reoptimization, use the segment-routing traffic-eng reoptimization command in Exec mode:
Use the all option to trigger an immediate reoptimization for all policies. Use the namepolicy option to trigger an immediate reoptimization for a specific policy.
Configuring SR-TE Reoptimization Timers
Use these commands in SR-TE configuration mode to configure SR-TE reoptimization timers:
timers candidate-path cleanup-delayseconds—Specifies the delay before cleaning up candidate paths, in seconds. The range is from 0 (immediate clean-up) to 86400; the
default value is 120
timers cleanup-delayseconds—Specifies the delay before cleaning up previous path, in seconds. The range is from 0 (immediate clean-up) to 300; the default
value is 10.
timers init-verify-restartseconds—Specifies the delay for topology convergence after the topology starts populating due to a restart, in seconds. The range
is from 10 to 10000; the default is 40.
timers init-verify-startupseconds—Specifies the delay for topology convergence after topology starts populating for due to startup, in seconds. The range is
from 10 to 10000; the default is 300
timers init-verify-switchoverseconds—Specifies the delay for topology convergence after topology starts populating due to a switchover, in seconds. The range
is from 10 to 10000; the default is 60.
timers install-delayseconds—Specifies the delay before switching to a reoptimized path, in seconds. The range is from 0 (immediate installation of new
path) to 300; the default is 10.
timers periodic-reoptimizationseconds—Specifies how often to perform periodic reoptimization of policies, in seconds. The range is from 0 to 86400; the default
is 600.
Feedback