Limitations
Observe the following limitations for the platform.
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.
![]() Note |
Configuring SR-TE policies with 3 or more labels and an L2 Transport Interface on the same network processing unit (NPU) can cause traffic loss. |
Observe the following limitations for the platform.
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.
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 candidate path has the following characteristics:
It has a preference – If two policies have 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.
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. |
To configure a local SR-TE policy, you must complete the following configurations:
Create the segment lists.
Create the policy.
/* Enter the global configuration mode and create the SR-TE segment lists */
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# segment-list name Plist-1
Router(config-sr-te-sl)# index 1 mpls label 400102
Router(config-sr-te-sl)# index 2 mpls label 400106
Router(config-sr-te-sl)# exit
Router(config-sr-te)# segment-list name Plist-2
Router(config-sr-te-sl)# index 1 mpls label 400222
Router(config-sr-te-sl)# index 2 mpls label 400106
Router(config-sr-te-sl)# exit
/* Create the SR-TE policy */
Router(config-sr-te)# policy P1
Router(config-sr-te-policy)# binding-sid mpls 15001
Router(config-sr-te-policy)# color 1 end-point ipv4 6.6.6.6
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 10
Router(config-sr-te-pp-index)# explicit segment-list Plist-1
Router(config-sr-te-pp-info)# weight 2
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-pp-index)# explicit segment-list Plist-2
Router(config-sr-te-pp-info)# weight 2
Router(config-sr-te-pp-info)# commit
Router(config-sr-te-pp-info)# end
Router(config)#
Router# show running-configuration
segment-routing
traffic-eng
segment-list name Plist-1
index 1 mpls label 400102
index 2 mpls label 400106
!
segment-list name Plist-2
index 1 mpls label 400222
index 2 mpls label 400106
!
policy P1
binding-sid mpls 15001
color 1 end-point ipv4 6.6.6.6
candidate-paths
preference 10
explicit segment-list Plist-1
weight 2
!
explicit segment-list Plist-2
weight 2
!
!
!
!
!
!
Router# show segment-routing traffic-eng policy name srte_c_1_ep_6.6.6.6
Sat Jul 8 12:25:34.114 UTC
SR-TE policy database
---------------------
Name: P1 (Color: 1, End-point: 6.6.6.6)
Status:
Admin: up Operational: up for 00:06:21 (since Jul 8 12:19:13.198)
Candidate-paths:
Preference 10:
Explicit: segment-list Plist-1 (active)
Weight: 2
400102 [Prefix-SID, 2.1.1.1]
400106
Explicit: segment-list Plist-2 (active)
Weight: 2
400222 [Prefix-SID, 22.11.1.1]
400106
Attributes:
Binding SID: 15001
Allocation mode: explicit
State: programmed
Policy selected: yes
Forward Class: 0
You can configure SR-TE policies with Autoroute Include to steer specific IGP (IS-IS, OSPF) prefixes over non-shortest paths and to divert the traffic for those prefixes on to the SR-TE policy. Autoroute Include applies Autoroute Announce functionality to the specified destinations or prefixes.
The Autoroute SR-TE policy adds the prefixes into the IGP, which determines if the prefixes on the endpoint or downstream of the endpoint are eligible to use the SR-TE policy. If a prefix is eligible, then the IGP checks if the prefix is listed in the Autoroute Include configuration. If the prefix is included, then the IGP downloads the prefix route with the SR-TE policy as the outgoing path.
Autoroute Include supports three metric types:
Default (no metric): The path over the SR-TE policy inherits the shortest path metric.
Absolute metric: The shortest path metric to the policy endpoint is replaced with the configured absolute metric. The metric to any prefix that is Autoroute Included is modified to the absolute metric.
Relative metric: The shortest path metric to the policy endpoint is modified with the relative value configured (plus or minus).
![]() Note |
To prevent load-balancing over IGP paths, you can specify a metric that is lower than the value that IGP takes into account for autorouted destinations (for example, autoroute metric relative -1 ). |
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)#policy P1
Router(config-sr-te-policy)# color 20 end ipv4 1.1.1.2
Router(config-sr-te-policy)# autoroute include ipv4 1.1.1.21/32
Router(config-sr-te-policy)# autoroute include ipv4 1.1.1.23/32
Router(config-sr-te-policy)# autoroute metric constant 1
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-pp-index)# explicit segment-list Plist-1
Color-only steering is a traffic steering mechanism where a policy is created with given color, regardless of the endpoint.
You can create an SR-TE policy for a specific color that uses a NULL end-point (0.0.0.0 for IPv4 NULL, and ::0 for IPv6 NULL end-point). This means that you can have a single policy that can steer traffic that is based on that color and a NULL endpoint for routes with a particular color extended community, but different destinations (next-hop).
![]() Note |
Every SR-TE policy with a NULL end-point must have an explicit path-option. The policy cannot have a dynamic path-option (where the path is computed by the head-end or PCE) since there is no destination for the policy. |
You can also specify a color-only (CO) flag in the color extended community for overlay routes. The CO flag allows the selection of an SR-policy with a matching color, regardless of endpoint Sub-address Family Identifier (SAFI) (IPv4 or IPv6). See Setting CO Flag.
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# policy P1
Router(config-sr-te-policy)# color 1 end-point ipv4 0.0.0.0
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# policy P2
Router(config-sr-te-policy)# color 2 end-point ipv6 ::0
Router# show running-configuration
segment-routing
traffic-eng
policy P1
color 1 end-point ipv4 0.0.0.0
!
policy P2
color 2 end-point ipv6 ::
!
!
!
end
Address-family agnostic steering uses an SR-TE policy to steer both labeled and unlabeled IPv4 and IPv6 traffic. This feature requires support of IPv6 encapsulation (IPv6 caps) over IPV4 endpoint policy.
IPv6 caps for IPv4 NULL end-point is enabled automatically when the policy is created in Segment Routing Path Computation Element (SR-PCE). The binding SID (BSID) state notification for each policy contains an "ipv6_caps" flag that notifies SR-PCE clients (PCC) of the status of IPv6 caps (enabled or disabled).
An SR-TE policy with a given color and IPv4 NULL end-point could have more than one candidate path. If any of the candidate paths has IPv6 caps enabled, then all of the remaining candidate paths need IPv6 caps enabled. If IPv6 caps is not enabled on all candidate paths of same color and end-point, traffic drops can occur.
You can disable IPv6 caps for a particular color and IPv4 NULL end-point using the ipv6 disable command on the local policy. This command disables IPv6 caps on all candidate paths that share the same color and IPv4 NULL end-point.
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# policy P1
Router(config-sr-te-policy)# color 1 end-point ipv4 0.0.0.0
Router(config-sr-te-policy)# ipv6 disable
SR-TE can be used by data center (DC) operators to provide different levels of Service Level Assurance (SLA). Setting up SR-TE paths using BGP (BGP SR-TE) simplifies DC network operation without introducing a new protocol for this purpose.
Explicit BGP SR-TE uses an SR-TE policy (identified by a unique color ID) that contains a list of explicit paths with SIDs that correspond to each explicit path. A BGP speaker signals an explicit SR-TE policy to a remote peer, which triggers the setup of an SR-TE policy with specific characteristics and explicit paths. On the receiver side, an SR-TE policy that corresponds to the explicit path is setup by BGP. The packets for the destination mentioned in the BGP update follow the explicit path described by the policy. Each policy can include multiple explicit paths, and TE will create a policy for each path.
![]() Note |
For more information on routing policies and routing policy language (RPL), refer to the "Implementing Routing Policy" chapter in the Routing Configuration Guide for Cisco NCS 5500 Series Routers. |
Perform this task to configure explicit BGP SR-TE:
Command or Action | Purpose | |
---|---|---|
Step 1 |
configure |
|
Step 2 |
extcommunity-set opaque name Example:
|
Defines the color extended community-set. |
Step 3 |
name Example:
|
Defines the color extended community-set. |
Step 4 |
end-set Example:
|
Ends the definition of the extended community-set. |
Step 5 |
route-policy route-policy-name Example:
|
Creates a route policy and enters route policy configuration mode, where you can define the route policy to mark the prefixes with the color extended community value. |
Step 6 |
end-policy Example:
|
Ends the definition of a route policy and exits route policy configuration mode. |
Step 7 |
router bgp as-number Example:
|
Specifies the BGP AS number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
Step 8 |
bgp router-id ip-address Example:
|
Configures the local router with a specified router ID. |
Step 9 |
address-family { ipv4 | ipv6} sr-policy Example:
|
Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. |
Step 10 |
exit |
|
Step 11 |
neighbor ip-address Example:
|
Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
Step 12 |
remote-as as-number Example:
|
Creates a neighbor and assigns a remote autonomous system number to it. |
Step 13 |
address-family { ipv4 | ipv6} unicast Example:
|
Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. |
Step 14 |
route-policy route-policy-name { in | out} Example:
|
Applies the specified policy to IPv4 unicast routes. |
Step 15 |
send-extended-community-ebgp Example:
|
Sends extended community attributes to external Border Gateway Protocol (eBGP) neighbors. |
The BGP-based steering mechanism matches BGP color and next-hop with that of an SR-TE policy. If the policy does not exist, BGP requests SR-PCE to create an SR-TE policy with the associated color, end-point, and explicit paths. For color-only steering (NULL end-point), you can configure a color-only (CO) flag as part of the color extended community in BGP.
![]() Note |
See Color-Only Automated Steering for information about color-only steering (NULL end-point). |
The behavior of the steering mechanism is based on the following values of the CO flags:
co-flag 00 |
|
co-flag 01 |
|
Router(config)# extcommunity-set opaque overlay-color
Router(config-ext)# 1 co-flag 01
Router(config-ext)# end-set
Router(config)#
Router(config)# route-policy color
Router(config-rpl)# if destination in (5.5.5.1/32) then
Router(config-rpl-if)# set extcommunity color overlay-color
Router(config-rpl-if)# endif
Router(config-rpl)# pass
Router(config-rpl)# end-policy
Router(config)#
Use the metric value command in SR-TE interface submode to configure the TE metric for interfaces. The value range is from 0 to 2147483647.
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# interface type interface-path-id
Router(config-sr-te-if)# metric value
The following configuration example shows how to set the TE metric for various interfaces:
segment-routing
traffic-eng
interface TenGigE0/0/0/0
metric 100
!
interface TenGigE0/0/0/1
metric 1000
!
interface TenGigE0/0/2/0
metric 50
!
!
end
Use the affinity name NAME 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 type interface-path-id
Router(config-sr-if)# affinity
Router(config-sr-if-affinity)# name NAME
Use the affinity-map name NAME bit-position bit-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.
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# affinity-map
Router(config-sr-te-affinity-map)# name NAME bit-position bit-position
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
This example shows how to configure named affinity maps at the SR-TE head-end router with SR policies that include affinity constraints.
segment-routing
traffic-eng
affinity-map
name RED bit-position 23
name BLUE bit-position 24
!
!
!
The following example shows a configuration of an SR policy at an SR-TE head-end router. The policy has a dynamic path with affinity constraints computed by the head-end router.
segment-routing
traffic-eng
policy foo
color 100 end-point ipv4 1.1.1.2
candidate-paths
preference 100
dynamic
metric
type te
!
!
constraints
affinity
exclude-any
name 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 affinity constraints computed by the SR-PCE.
segment-routing
traffic-eng
policy baa
color 101 end-point ipv4 1.1.1.2
candidate-paths
preference 100
dynamic
pcep
!
metric
type te
!
!
constraints
affinity
exclude-any
name BLUE
!
!
!
!
!
!
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)
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.
Define BGP color extended communities. Refer to the "Implementing BGP" chapter in the BGP Configuration Guide for NCS 5500 Series Routers.
Define routing policies (using routing policy language [RPL]) to set BGP color extended communities. Refer to the "Implementing Routing Policy" chapter in the Routing Configuration Guide for NCS 5500 Series Routers.
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. |
Attach Point |
Set |
Match |
---|---|---|
VRF export |
X |
X |
VRF import |
– |
X |
Neighbor-in |
X |
X |
Neighbor-out |
X |
X |
Inter-AFI export |
– |
X |
Inter-AFI import |
– |
X |
Default-originate |
X |
– |
Apply routing policies to a service. Refer to the "Implementing Routing Policy" chapter in the Routing Configuration Guide for NCS 5500 Series Routers.
Use the on-demand color color 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 color
![]() 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 color color dynamic 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 color dynamic
Use the on-demand color color dynamic 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 color dynamic 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 {igp | te | latency}
Use the metric margin {absolute value| relative percent} command to configure the On-Demand dynamic path metric margin. The range for value and percent is from 0 to 2147483647.
Router(config-sr-te-color-dyn)# metric margin {absolute margin| relative margin}
Configure Dynamic Path Constraints
Use the disjoint-path group-id group-id type {link | node | srlg | srlg-node} [sub-id sub-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 group-id type {link | node | srlg | srlg-node} [sub-id sub-id]
Use the affinity {include-any | include-all | exclude-any} {name WORD} command to configure the affinity constraints.
Router(config-sr-te-color-dyn)# affinity {include-any | include-all | exclude-any} {name WORD}
Use the sid-algorithm algorithm-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 algorithm-number
Use the maximum-sid-depth value 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 (5).
Router(config-sr-te-color)# maximum-sid-depth value
![]() Note |
The platform's SR-TE label imposition capabilities are as follows:
|
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-depth value 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 color color maximum-sid-depth value command
Local SR Policy: MSD is configured using the segment-routing traffic-eng policy WORD candidate-paths preference preference dynamic metric sid-limit value 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 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. |
The following examples show end-to-end configurations used in implementing SR-ODN on the head-end router.
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
color 30: minimization objective = delay-metric
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
!
!
!
on-demand color 30
dynamic
metric
type latency
!
!
!
!
end
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. |
extcommunity-set opaque color10-te
10
end-set
!
extcommunity-set opaque color20-igp
20
end-set
!
extcommunity-set opaque color21-igp-excl-cross
21
end-set
!
extcommunity-set opaque color30-delay
30
end-set
!
The following example shows various representative RPL definitions that set BGP color community.
The first 4 RPL 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
!
route-policy SET_COLOR_LOW_LATENCY
set extcommunity color color30-delay
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
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.
vrf vrf_cust1
address-family ipv4 unicast
export route-policy SET_COLOR_LOW_LATENCY_TE
!
address-family ipv6 unicast
export route-policy SET_COLOR_LOW_LATENCY_TE
!
!
vrf vrf_cust2
address-family ipv4 unicast
export route-policy SET_COLOR_HI_BW
!
address-family ipv6 unicast
export route-policy SET_COLOR_HI_BW
!
!
vrf vrf_cust3
address-family ipv4 unicast
export route-policy SET_COLOR_LOW_LATENCY
!
address-family ipv6 unicast
export route-policy SET_COLOR_LOW_LATENCY
!
!
router bgp 100
neighbor-group BR-TO-RR
address-family ipv4 unicast
route-policy SET_COLOR_GLOBAL out
!
!
!
end
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 1.1.1.8.
RP/0/RP0/CPU0:R4# show bgp vrf vrf_cust1
BGP VRF vrf_cust1, state: Active
BGP Route Distinguisher: 1.1.1.4:101
VRF ID: 0x60000007
BGP router identifier 1.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: 1.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 1.1.1.5 100 0 500 {1} i
*>i88.1.1.0/24 1.1.1.8 C:10 100 0 800 {1} i
*>i99.1.1.0/24 1.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: 1.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}
1.1.1.8 C:10 (bsid:24036) (metric 20) from 1.1.1.55 (1.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: 1.1.1.8, Cluster list: 1.1.1.55
SR policy color 10, up, registered, bsid 24036, if-handle 0x08000024
Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 1.1.1.8:101
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.
RP/0/RP0/CPU0:R4# show cef vrf vrf_cust1
Prefix Next Hop Interface
------------------- ------------------- ------------------
0.0.0.0/0 drop default handler
0.0.0.0/32 broadcast
40.4.101.0/24 attached TenGigE0/0/0/0.101
40.4.101.0/32 broadcast TenGigE0/0/0/0.101
40.4.101.4/32 receive TenGigE0/0/0/0.101
40.4.101.11/32 40.4.101.11/32 TenGigE0/0/0/0.101
40.4.101.255/32 broadcast TenGigE0/0/0/0.101
44.1.1.0/24 40.4.101.11/32 <recursive>
55.1.1.0/24 1.1.1.5/32 <recursive>
88.1.1.0/24 24036 (via-label) <recursive>
99.1.1.0/24 1.1.1.9/32 <recursive>
224.0.0.0/4 0.0.0.0/32
224.0.0.0/24 receive
255.255.255.255/32 broadcast
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}
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 1.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
------ -------------------- ------ ------ --------------------
10 1.1.1.8 up up 24036
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. |
RP/0/RP0/CPU0:R4# show segment-routing traffic-eng policy binding-sid 24036
SR-TE policy database
---------------------
Color: 10, End-point: 1.1.1.8
Name: srte_c_10_ep_1.1.1.8
Status:
Admin: up Operational: up for 4d14h (since Jul 3 20:28:57.840)
Candidate-paths:
Preference: 200 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10_ep_1.1.1.8_discr_200
PLSP-ID: 12
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 30
16009 [Prefix-SID, 1.1.1.9]
16008 [Prefix-SID, 1.1.1.8]
Preference: 100 (BGP ODN)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10_ep_1.1.1.8_discr_100
PLSP-ID: 11
Dynamic (pce 1.1.1.57) (valid)
Metric Type: TE, Path Accumulated Metric: 30
16009 [Prefix-SID, 1.1.1.9]
16008 [Prefix-SID, 1.1.1.8]
Attributes:
Binding SID: 24036
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Use the show segment-routing traffic-eng forwarding policy command to display the SR policy forwarding information.
The following outputs show the forwarding details for an on-demand SR policy that was triggered by prefixes with color 10 advertised by node 1.1.1.8.
RP/0/RP0/CPU0:R4# show segment-routing traffic-eng forwarding policy binding-sid 24036 tabular
Color Endpoint Segment Outgoing Outgoing Next Hop Bytes Pure
List Label Interface Switched Backup
----- --------------- ------------ -------- ------------ ------------ ------------ ------
10 1.1.1.8 dynamic 16009 Gi0/0/0/4 10.4.5.5 0
16001 Gi0/0/0/5 11.4.8.8 0 Yes
RP/0/RP0/CPU0:R4# show segment-routing traffic-eng forwarding policy binding-sid 24036 detail
Mon Jul 8 11:56:46.887 PST
SR-TE Policy Forwarding database
--------------------------------
Color: 10, End-point: 1.1.1.8
Name: srte_c_10_ep_1.1.1.8
Binding SID: 24036
Segment Lists:
SL[0]:
Name: dynamic
Paths:
Path[0]:
Outgoing Label: 16009
Outgoing Interface: GigabitEthernet0/0/0/4
Next Hop: 10.4.5.5
Switched Packets/Bytes: 0/0
FRR Pure Backup: No
Label Stack (Top -> Bottom): { 16009, 16008 }
Path-id: 1 (Protected), Backup-path-id: 2, Weight: 64
Path[1]:
Outgoing Label: 16001
Outgoing Interface: GigabitEthernet0/0/0/5
Next Hop: 11.4.8.8
Switched Packets/Bytes: 0/0
FRR Pure Backup: Yes
Label Stack (Top -> Bottom): { 16001, 16009, 16008 }
Path-id: 2 (Pure-Backup), Weight: 64
Policy Packets/Bytes Switched: 0/0
Local label: 80013
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.
IP Addresses of Loopback0 (Lo0) Interfaces |
SR-PCE Lo0: 1.1.1.207 |
|||
Site 1:
|
Site 2:
|
|||
EVPN-VPWS Service Parameters |
ELINE-1:
|
ELINE-2:
|
||
ODN BGP Color Extended Communities |
Site 1 routers (Nodes A and B):
|
Site 2 routers (Nodes C and D):
|
||
|
||||
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):
|
Site 2 to Site 1 LSPs (from Node C to Node A/from Node D to Node B):
|
The use case provides configuration and verification outputs for all devices.
Configuration |
Verification |
---|---|
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. |
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-10000
10000
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 1.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
!
!
!
!
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-10000
10000
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 1.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
!
!
!
!
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-11000
11000
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 1.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
!
!
!
!
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-11000
11000
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 1.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
!
!
!
!
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: 1.1.1.2
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 1.1.1.4
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 1.1.1.5
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 1.1.1.6
State: 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 (1.1.1.5): LSP symbolic name = bgp_c_11000_ep_1.1.1.2_discr_100
At Node B (1.1.1.6): LSP symbolic name = bgp_c_11000_ep_1.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 1.1.1.6, tunnel name bgp_c_11000_ep_1.1.1.4_discr_100, PLSP ID 18, tunnel ID 17, LSP ID 3, Configured on PCC
LSP[1]:
PCC 1.1.1.5, tunnel name bgp_c_11000_ep_1.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 (1.1.1.5) that is used to carry traffic of EVPN VPWS EVI 100 towards node C (1.1.1.2).
RP/0/0/CPU0:SR-PCE# show pce lsp pcc ipv4 1.1.1.5 name bgp_c_11000_ep_1.1.1.2_discr_100
Thu Jul 11 03:58:45.903 UTC
PCE's tunnel database:
----------------------
PCC 1.1.1.5:
Tunnel Name: bgp_c_11000_ep_1.1.1.2_discr_100
Color: 11000
Interface Name: srte_c_11000_ep_1.1.1.2
LSPs:
LSP[0]:
source 1.1.1.5, destination 1.1.1.2, tunnel ID 18, LSP ID 3
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 80037
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Preference: 100
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x12, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Exclude LSP
State-sync PCE: None
PCC: 1.1.1.5
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 40
SID[0]: Adj, Label 80003, Address: local 11.5.8.5 remote 11.5.8.8
SID[1]: Node, Label 16007, Address 1.1.1.7
SID[2]: Node, Label 16002, Address 1.1.1.2
Computed path: (Local PCE)
Computed Time: Thu Jul 11 03:49:48 UTC 2019 (00:08:58 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Adj, Label 80003, Address: local 11.5.8.5 remote 11.5.8.8
SID[1]: Node, Label 16007, Address 1.1.1.7
SID[2]: Node, Label 16002, Address 1.1.1.2
Recorded path:
None
Disjoint Group Information:
Type Link-Disjoint, Group 775
This output shows details for the LSP at Node B (1.1.1.6) that is used to carry traffic of EVPN VPWS EVI 101 towards node D (1.1.1.4).
RP/0/0/CPU0:SR-PCE# show pce lsp pcc ipv4 1.1.1.6 name bgp_c_11000_ep_1.1.1.4_discr_100
Thu Jul 11 03:58:56.812 UTC
PCE's tunnel database:
----------------------
PCC 1.1.1.6:
Tunnel Name: bgp_c_11000_ep_1.1.1.4_discr_100
Color: 11000
Interface Name: srte_c_11000_ep_1.1.1.4
LSPs:
LSP[0]:
source 1.1.1.6, destination 1.1.1.4, tunnel ID 17, LSP ID 3
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 80061
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Preference: 100
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x12, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Disjoint LSP
State-sync PCE: None
PCC: 1.1.1.6
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16001, Address 1.1.1.1
SID[1]: Node, Label 16004, Address 1.1.1.4
Computed path: (Local PCE)
Computed Time: Thu Jul 11 03:49:48 UTC 2019 (00:09:08 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16001, Address 1.1.1.1
SID[1]: Node, Label 16004, Address 1.1.1.4
Recorded path:
None
Disjoint Group Information:
Type Link-Disjoint, Group 775
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 (1.1.1.2): LSP symbolic name = bgp_c_10000_ep_1.1.1.5_discr_100
At Node D (1.1.1.4): LSP symbolic name = bgp_c_10000_ep_1.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 1.1.1.4, tunnel name bgp_c_10000_ep_1.1.1.6_discr_100, PLSP ID 16, tunnel ID 14, LSP ID 1, Configured on PCC
LSP[1]:
PCC 1.1.1.2, tunnel name bgp_c_10000_ep_1.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 (1.1.1.2) that is used to carry traffic of EVPN VPWS EVI 100 towards node A (1.1.1.5).
RP/0/0/CPU0:SR-PCE# show pce lsp pcc ipv4 1.1.1.2 name bgp_c_10000_ep_1.1.1.5_discr_100
Thu Jul 11 03:55:21.706 UTC
PCE's tunnel database:
----------------------
PCC 1.1.1.2:
Tunnel Name: bgp_c_10000_ep_1.1.1.5_discr_100
Color: 10000
Interface Name: srte_c_10000_ep_1.1.1.5
LSPs:
LSP[0]:
source 1.1.1.2, destination 1.1.1.5, tunnel ID 21, LSP ID 3
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 80052
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Preference: 100
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x6, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Exclude LSP
State-sync PCE: None
PCC: 1.1.1.2
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16007, Address 1.1.1.7
SID[1]: Node, Label 16008, Address 1.1.1.8
SID[2]: Adj, Label 80005, Address: local 11.5.8.8 remote 11.5.8.5
Computed path: (Local PCE)
Computed Time: Thu Jul 11 03:50:03 UTC 2019 (00:05:18 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16007, Address 1.1.1.7
SID[1]: Node, Label 16008, Address 1.1.1.8
SID[2]: Adj, Label 80005, Address: local 11.5.8.8 remote 11.5.8.5
Recorded path:
None
Disjoint Group Information:
Type Link-Disjoint, Group 776
This output shows details for the LSP at Node D (1.1.1.4) used to carry traffic of EVPN VPWS EVI 101 towards node B (1.1.1.6).
RP/0/0/CPU0:SR-PCE# show pce lsp pcc ipv4 1.1.1.4 name bgp_c_10000_ep_1.1.1.6_discr_100
Thu Jul 11 03:55:23.296 UTC
PCE's tunnel database:
----------------------
PCC 1.1.1.4:
Tunnel Name: bgp_c_10000_ep_1.1.1.6_discr_100
Color: 10000
Interface Name: srte_c_10000_ep_1.1.1.6
LSPs:
LSP[0]:
source 1.1.1.4, destination 1.1.1.6, tunnel ID 14, LSP ID 1
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 80047
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Preference: 100
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x10, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Disjoint LSP
State-sync PCE: None
PCC: 1.1.1.4
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16001, Address 1.1.1.1
SID[1]: Node, Label 16006, Address 1.1.1.6
Computed path: (Local PCE)
Computed Time: Thu Jul 11 03:50:03 UTC 2019 (00:05:20 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16001, Address 1.1.1.1
SID[1]: Node, Label 16006, Address 1.1.1.6
Recorded path:
None
Disjoint Group Information:
Type Link-Disjoint, Group 776
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 1.1.1.5:100). The output includes an EVPN route-type 1 route with color 11000 originated at Node C (1.1.1.2).
RP/0/RSP0/CPU0:Node-A# show bgp l2vpn evpn rd 1.1.1.5:100
Wed Jul 10 18:57:57.704 PST
BGP router identifier 1.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: 1.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]/120
1.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 1.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: 1.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
1.1.1.2 C:11000 (bsid:80044) (metric 40) from 1.1.1.253 (1.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: 1.1.1.2, Cluster list: 1.1.1.253
SR policy color 11000, up, registered, bsid 80044, if-handle 0x00001b20
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 1.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_100
UP Gi0/0/0/3.2500 UP EVPN 100,21,1.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 1.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 1.1.1.2, PW ID: evi 100, ac-id 21, state is up ( established )
XC ID 0xa0000007
Encapsulation MPLS
Source address 1.1.1.5
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_11000_ep_1.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 (1.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
------ -------------------- ------ ------ --------------------
11000 1.1.1.2 up up 80044
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 (1.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_1.1.1.2) is link-disjoint from LSP at Node B (srte_c_11000_ep_1.1.1.4).
RP/0/RSP0/CPU0:Node-A# show segment-routing traffic-eng policy color 11000
Wed Jul 10 19:15:47.217 PST
SR-TE policy database
---------------------
Color: 11000, End-point: 1.1.1.2
Name: srte_c_11000_ep_1.1.1.2
Status:
Admin: up Operational: up for 00:39:31 (since Jul 10 18:36:00.471)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_11000_ep_1.1.1.2_discr_200
PLSP-ID: 19
Dynamic (invalid)
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_11000_ep_1.1.1.2_discr_100
PLSP-ID: 18
Dynamic (pce 1.1.1.207) (valid)
Metric Type: IGP, Path Accumulated Metric: 40
80003 [Adjacency-SID, 11.5.8.5 - 11.5.8.8]
16007 [Prefix-SID, 1.1.1.7]
16002 [Prefix-SID, 1.1.1.2]
Attributes:
Binding SID: 80044
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
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 1.1.1.6:101). The output includes an EVPN route-type 1 route with color 11000 originated at Node D (1.1.1.4).
RP/0/RSP0/CPU0:Node-B# show bgp l2vpn evpn rd 1.1.1.6:101
Wed Jul 10 19:08:54.964 PST
BGP router identifier 1.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: 1.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
1.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 1.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: 1.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
1.1.1.4 C:11000 (bsid:80061) (metric 40) from 1.1.1.253 (1.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: 1.1.1.4, Cluster list: 1.1.1.253
SR policy color 11000, up, registered, bsid 80061, if-handle 0x00000560
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 1.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_101
UP Te0/3/0/0/8.2500 UP EVPN 101,22,1.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 1.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 1.1.1.4, PW ID: evi 101, ac-id 22, state is up ( established )
XC ID 0xa0000009
Encapsulation MPLS
Source address 1.1.1.6
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_11000_ep_1.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 (1.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
------ -------------------- ------ ------ --------------------
11000 1.1.1.4 up up 80061
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 (1.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_1.1.1.4) is link-disjoint from LSP at Node A (srte_c_11000_ep_1.1.1.2).
RP/0/RSP0/CPU0:Node-B# show segment-routing traffic-eng policy color 11000
Wed Jul 10 19:08:56.207 PST
SR-TE policy database
---------------------
Color: 11000, End-point: 1.1.1.4
Name: srte_c_11000_ep_1.1.1.4
Status:
Admin: up Operational: up for 00:26:47 (since Jul 10 18:40:05.868)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_11000_ep_1.1.1.4_discr_200
PLSP-ID: 19
Dynamic (invalid)
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_11000_ep_1.1.1.4_discr_100
PLSP-ID: 18
Dynamic (pce 1.1.1.207) (valid)
Metric Type: IGP, Path Accumulated Metric: 40
16001 [Prefix-SID, 1.1.1.1]
16004 [Prefix-SID, 1.1.1.4]
Attributes:
Binding SID: 80061
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
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 1.1.1.2:100). The output includes an EVPN route-type 1 route with color 10000 originated at Node A (1.1.1.5).
RP/0/RSP0/CPU0:Node-C# show bgp l2vpn evpn rd 1.1.1.2:100
BGP router identifier 1.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: 1.1.1.2:100 (default for vrf VPWS:100)
*>i[1][0000.0000.0000.0000.0000][11]/120
1.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 1.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: 1.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
1.1.1.5 C:10000 (bsid:80058) (metric 40) from 1.1.1.253 (1.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: 1.1.1.5, Cluster list: 1.1.1.253
SR policy color 10000, up, registered, bsid 80058, if-handle 0x000006a0
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 1.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_100
UP Gi0/0/0/3.2500 UP EVPN 100,11,1.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 1.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 1.1.1.5, PW ID: evi 100, ac-id 11, state is up ( established )
XC ID 0xa0000003
Encapsulation MPLS
Source address 1.1.1.2
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_10000_ep_1.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 (1.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
------ -------------------- ------ ------ --------------------
10000 1.1.1.5 up up 80058
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 (1.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_1.1.1.5) is link-disjoint from LSP at Node D (srte_c_10000_ep_1.1.1.6).
RP/0/RSP0/CPU0:Node-C# show segment-routing traffic-eng policy color 10000
SR-TE policy database
---------------------
Color: 10000, End-point: 1.1.1.5
Name: srte_c_10000_ep_1.1.1.5
Status:
Admin: up Operational: up for 00:12:35 (since Jul 10 19:49:21.890)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10000_ep_1.1.1.5_discr_200
PLSP-ID: 7
Dynamic (invalid)
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10000_ep_1.1.1.5_discr_100
PLSP-ID: 6
Dynamic (pce 1.1.1.207) (valid)
Metric Type: IGP, Path Accumulated Metric: 40
16007 [Prefix-SID, 1.1.1.7]
16008 [Prefix-SID, 1.1.1.8]
80005 [Adjacency-SID, 11.5.8.8 - 11.5.8.5]
Attributes:
Binding SID: 80058
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
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 1.1.1.4:101). The output includes an EVPN route-type 1 route with color 10000 originated at Node B (1.1.1.6).
RP/0/RSP0/CPU0:Node-D# show bgp l2vpn evpn rd 1.1.1.4:101
BGP router identifier 1.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: 1.1.1.4:101 (default for vrf VPWS:101)
*>i[1][0000.0000.0000.0000.0000][12]/120
1.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 1.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: 1.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
1.1.1.6 C:10000 (bsid:80047) (metric 40) from 1.1.1.253 (1.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: 1.1.1.6, Cluster list: 1.1.1.253
SR policy color 10000, up, registered, bsid 80047, if-handle 0x00001720
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 1.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_101
UP Gi0/0/0/1.2500 UP EVPN 101,12,1.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 1.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 1.1.1.6, PW ID: evi 101, ac-id 12, state is up ( established )
XC ID 0xa000000d
Encapsulation MPLS
Source address 1.1.1.4
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_10000_ep_1.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 (1.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
------ -------------------- ------ ------ --------------------
10000 1.1.1.6 up up 80047
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 (1.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_1.1.1.6) is link-disjoint from LSP at Node C (srte_c_10000_ep_1.1.1.5).
RP/0/RSP0/CPU0:Node-D# show segment-routing traffic-eng policy color 10000
SR-TE policy database
---------------------
Color: 10000, End-point: 1.1.1.6
Name: srte_c_10000_ep_1.1.1.6
Status:
Admin: up Operational: up for 01:23:04 (since Jul 10 18:42:07.350)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10000_ep_1.1.1.6_discr_200
PLSP-ID: 17
Dynamic (invalid)
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10000_ep_1.1.1.6_discr_100
PLSP-ID: 16
Dynamic (pce 1.1.1.207) (valid)
Metric Type: IGP, Path Accumulated Metric: 40
16001 [Prefix-SID, 1.1.1.1]
16006 [Prefix-SID, 1.1.1.6]
Attributes:
Binding SID: 80047
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
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.
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.
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# pcc
Router(config-sr-te-pcc)# source-address ipv4 local-source-address
Router(config-sr-te-pcc)# pce address ipv4 PCE-address[precedence value]
Router(config-sr-te-pcc)# pce address ipv4 PCE-address[password {clear | encrypted} LINE]
Router(config-sr-te-pcc)# pce address ipv4 PCE-address[keychain WORD]
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 keepalive seconds
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 deadtimer seconds
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.
Router(config-sr-te-pcc)# timers delegation-timeout seconds
PCE-Initiated SR Policy Timers
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.
Router(config-sr-te-pcc)# timers initiated orphans seconds
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.
Router(config-sr-te-pcc)# timers initiated state seconds
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.
Use the logging policy status command to enable SR-TE related SYSLOG alarms.
Router(config-sr-te)# logging policy status
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
Use the maximum-sid-depth value 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 (5).
Router(config-sr-te)# maximum-sid-depth value
![]() Note |
The platform's SR-TE label imposition capabilities are as follows:
|
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-depth value 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 color color maximum-sid-depth value command
Local SR Policy: MSD is configured using the segment-routing traffic-eng policy WORD candidate-paths preference preference dynamic metric sid-limit value 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 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. |
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. |
Use the redundancy pcc-centric command to enable PCC-centric high-availability model, where the PCC allows only the PCE with the lowest precedence to initiate policies.
Router(config-sr-te-pcc)# redundancy pcc-centric
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 1.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.
segment-routing
traffic-eng
pcc
source-address ipv4 1.1.1.2
pce address ipv4 1.1.1.57
precedence 150
password clear <password>
!
pce address ipv4 1.1.1.58
precedence 200
password clear <password>
!
pce address ipv4 1.1.1.59
precedence 250
password clear <password>
!
!
logging
policy status
!
maximum-sid-depth 5
pcc
report-all
!
!
!
end
RP/0/RSP0/CPU0:Router# show segment-routing traffic-eng pcc ipv4 peer
PCC's peer database:
--------------------
Peer address: 1.1.1.57, Precedence: 150, (best PCE)
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 1.1.1.58, Precedence: 200
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 1.1.1.59, Precedence: 250
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
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.
![]() Note |
In Cisco IOS XR 6.3.2 and later releases, you can specify an explicit BSID for an SR-TE policy. See the following Explicit Binding SID section. |
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.
Use the binding-sid explicit {fallback-dynamic | enforce-srlb} command to request that the SR-TE policy uses a BSID value that you provide. 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 this 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.
You can 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:
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# binding-sid explicit fallback-dynamic
Strict SRLB enforcement – If the BSID is not within the SRLB, the policy stays down:
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# binding-sid explicit enforce-srlb
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.
Router |
Prefix Address |
Prefix SID/Adj-SID |
---|---|---|
3 |
Loopback0 - 1.1.1.3 |
Prefix SID - 16003 |
4 |
Loopback0 - 1.1.1.4 Link node 4 to node 6 - 10.4.6.4 |
Prefix SID - 16004 Adjacency SID - dynamic |
5 |
Loopback0 - 1.1.1.5 |
Prefix SID - 16005 |
6 |
Loopback0 - 1.1.1.6 Link node 4 to node 6 - 10.4.6.6 |
Prefix SID - 16006 Adjacency SID - dynamic |
9 |
Loopback0 - 1.1.1.9 |
Prefix SID - 16009 |
10 |
Loopback0 - 1.1.1.10 |
Prefix SID - 16010 |
Step 1 |
On node 5, do the following: |
Step 2 |
On node 3, do the following: |
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:
|