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.
Auto-Route Announce for SR-TE
Auto-route announce for SR-TE cannot handle LDP-over-SR-TE if the SR-TE terminates at an LDP mid-node.
Let us consider the following topology:
R1---R2---R3---R4---R5---R6
If there is an SR-TE route from R1 to R4, and an LDP prefix is learnt from R6, then auto-route announce will fail.
Autoroute Include
|
Feature Name |
Release |
Description |
|---|---|---|
|
Autoroute Include |
Release 7.3.2 |
This feature allows you to steer specific IGP (IS-IS, OSPF) prefixes, or all prefixes, over non-shortest paths and to divert the traffic for those prefixes on to an SR-TE policy. |
You can configure SR-TE policies with Autoroute Include to steer specific IGP (IS-IS, OSPF) prefixes, or all prefixes, over non-shortest paths and to divert the traffic for those prefixes on to the SR-TE policy.
The autoroute include all option applies Autoroute Announce functionality for all destinations or prefixes.
The autoroute include ipv4 address option applies Autoroute Destination functionality for the specified destinations or prefixes. This option is supported for IS-IS only; it is not supported for OSPF.
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.
Usage Guidelines and Limitations
-
Autoroute Include supports three metric types:
-
Default (no metric): The path over the SR-TE policy inherits the shortest path metric.
-
Absolute (constant) 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. Use the autoroute metric constant constant-metric command, where constant-metric is from 1 to 2147483647.
-
Relative metric: The shortest path metric to the policy endpoint is modified with the relative value configured (plus or minus). Use the autoroute metric relative relative-metric command, where relative-metric is from -10 to +10.
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 ).
-
-
LDP over SR-TE not supported.
-
LDP to SR-TE interworking is not supported.
-
Static route over SR-TE is not supported.
Configuration Examples
The following example shows how to configure autoroute include for all prefixes:
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-point ipv4 10.1.1.2
Router(config-sr-te-policy)# autoroute include all
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
The following example shows how to configure autoroute include for the specified IPv4 prefixes:
Note |
This option is supported for IS-IS only; it is not supported for OSPF. |
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-point ipv4 10.1.1.2
Router(config-sr-te-policy)# autoroute include ipv4 10.1.1.21/32
Router(config-sr-te-policy)# autoroute include ipv4 10.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 Automated Steering
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.
Configure Color-Only Steering
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 Automated Steering
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.
Disable IPv6 Encapsulation
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
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:
|
Running Configuration
segment-routing
traffic-eng
segment-list sample-sid-list
index 10 address ipv4 10.1.1.7
index 20 address ipv4 10.1.1.2
!
policy sample_policy
color 1000 end-point ipv4 10.1.1.2
candidate-paths
preference 100
explicit segment-list sample-sid-list
!
!
!
!
!
!
mpls ldp
address-family ipv4
neighbor sr-policy srte_c_1000_ep_10.1.1.2 targeted
discovery targeted-hello accept
!
!
Verification
Router# show mpls ldp interface brief
Interface VRF Name Config Enabled IGP-Auto-Cfg TE-Mesh-Grp cfg
--------------- ------------------- ------ ------- ------------ ---------------
Te0/3/0/0/3 default Y Y 0 N/A
Te0/3/0/0/6 default Y Y 0 N/A
Te0/3/0/0/7 default Y Y 0 N/A
Te0/3/0/0/8 default N N 0 N/A
Te0/3/0/0/9 default N N 0 N/A
srte_c_1000_ default Y Y 0 N/A
Router# show mpls ldp interface
Interface TenGigE0/3/0/0/3 (0xa000340)
VRF: 'default' (0x60000000)
Enabled via config: LDP interface
Interface TenGigE0/3/0/0/6 (0xa000400)
VRF: 'default' (0x60000000)
Enabled via config: LDP interface
Interface TenGigE0/3/0/0/7 (0xa000440)
VRF: 'default' (0x60000000)
Enabled via config: LDP interface
Interface TenGigE0/3/0/0/8 (0xa000480)
VRF: 'default' (0x60000000)
Disabled:
Interface TenGigE0/3/0/0/9 (0xa0004c0)
VRF: 'default' (0x60000000)
Disabled:
Interface srte_c_1000_ep_10.1.1.2 (0x520)
VRF: 'default' (0x60000000)
Enabled via config: LDP interface
Router# show segment-routing traffic-eng policy color 1000
SR-TE policy database
---------------------
Color: 1000, End-point: 10.1.1.2
Name: srte_c_1000_ep_10.1.1.2
Status:
Admin: up Operational: up for 00:02:00 (since Jul 2 22:39:06.663)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: sample_policy
Requested BSID: dynamic
PCC info:
Symbolic name: cfg_sample_policy_discr_100
PLSP-ID: 17
Explicit: segment-list sample-sid-list (valid)
Weight: 1, Metric Type: TE
16007 [Prefix-SID, 10.1.1.7]
16002 [Prefix-SID, 10.1.1.2]
Attributes:
Binding SID: 80011
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Router# show mpls ldp neighbor 10.1.1.2 detail
Peer LDP Identifier: 10.1.1.2:0
TCP connection: 10.1.1.2:646 - 10.1.1.6:57473
Graceful Restart: No
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 421/423; Downstream-Unsolicited
Up time: 05:22:02
LDP Discovery Sources:
IPv4: (1)
Targeted Hello (10.1.1.6 -> 10.1.1.2, active/passive)
IPv6: (0)
Addresses bound to this peer:
IPv4: (9)
10.1.1.2 2.2.2.99 10.1.2.2 10.2.3.2
10.2.4.2 10.2.22.2 10.2.222.2 10.30.110.132
11.2.9.2
IPv6: (0)
Peer holdtime: 180 sec; KA interval: 60 sec; Peer state: Estab
NSR: Disabled
Clients: LDP over SR Policy
Capabilities:
Sent:
0x508 (MP: Point-to-Multipoint (P2MP))
0x509 (MP: Multipoint-to-Multipoint (MP2MP))
0x50a (MP: Make-Before-Break (MBB))
0x50b (Typed Wildcard FEC)
Received:
0x508 (MP: Point-to-Multipoint (P2MP))
0x509 (MP: Multipoint-to-Multipoint (MP2MP))
0x50a (MP: Make-Before-Break (MBB))
0x50b (Typed Wildcard FEC)
Static Route over Segment Routing Policy
This feature allows you to specify a Segment Routing (SR) policy as an interface type when configuring static routes for MPLS data planes.
For information on configuring static routes, see the "Implementing Static Routes" chapter in the Routing Configuration Guide.
Configuration Example
The following example depicts a configuration of a static route for an IPv4 destination over an SR policy.
Router(config)# router static
Router(config-static)# address-family ipv4 unicast
Router(config-static-afi)# 10.1.100.100/32 sr-policy sample-policy
Running Configuration
Router# show run segment-routing traffic-eng
segment-routing
traffic-eng
segment-list sample-SL
index 10 mpls adjacency 10.1.1.102
index 20 mpls adjacency 10.1.1.103
!
policy sample-policy
color 777 end-point ipv4 10.1.1.103
candidate-paths
preference 100
explicit segment-list sample-SL
Router# show run segment-routing traffic-eng
router static
address-family ipv4 unicast
10.1.1.4/32 sr-policy srte_c_200_ep_10.1.1.4
!
!
Verification
Router# show segment-routing traffic-eng policy candidate-path name sample-policy
SR-TE policy database
---------------------
Color: 777, End-point: 10.1.1.103
Name: srte_c_777_ep_10.1.1.103
Status:
Admin: up Operational: up for 00:06:35 (since Jan 17 14:34:35.120)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: sample-policy
Requested BSID: dynamic
PCC info:
Symbolic name: cfg_sample-policy_discr_100
PLSP-ID: 5
Constraints:
Protection Type: protected-preferred
Maximum SID Depth: 9
Explicit: segment-list sample-SL (valid)
Weight: 1, Metric Type: TE
SID[0]: 100102 [Prefix-SID, 10.1.1.102]
SID[1]: 100103 [Prefix-SID, 10.1.1.103]
Attributes:
Binding SID: 24006
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
Max Install Standby Candidate Paths: 0
Router# show static sr-policy sample-policy
SR-Policy-Name State Binding-label Interface ifhandle VRF Paths
sample-policy Up 24006 srte_c_777_ep_10.1.1.103 0x2000803c default 10.1.100.100/32
Reference count=1, Internal flags=0x0
Last Policy notification was Up at Jan 17 13:39:46.478
Router# show route 10.1.100.100/32
Routing entry for 10.1.100.100/32
Known via "static", distance 1, metric 0
Installed Jan 17 14:35:40.969 for 00:06:38
Routing Descriptor Blocks
directly connected, via srte_c_777_ep_10.1.1.103
Route metric is 0
No advertising protos.
Router# show route 10.1.100.100/32 detail
Routing entry for 10.1.100.100/32
Known via "static", distance 1, metric 0
Installed Jan 17 14:35:40.969 for 00:06:44
Routing Descriptor Blocks
directly connected, via srte_c_777_ep_10.1.1.103
Route metric is 0
Label: None
Tunnel ID: None
Binding Label: 0x5dc6 (24006)
Extended communities count: 0
NHID: 0x0 (Ref: 0)
Route version is 0x1 (1)
No local label
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_STATIC (9) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 3, Download Version 3169
No advertising protos.
Router# show cef 10.1.100.100/32
10.1.100.100/32, version 3169, internal 0x1000001 0x30 (ptr 0x8b1b95d8) [1], 0x0 (0x0), 0x0 (0x0)
Updated Jan 17 14:35:40.971
Prefix Len 32, traffic index 0, precedence n/a, priority 3
gateway array (0x8a92f228) reference count 1, flags 0x2010, source rib (7), 0 backups
[1 type 3 flags 0x48441 (0x8a9d1b68) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Jan 17 14:35:40.971
LDI Update time Jan 17 14:35:40.972
via local-label 24006, 3 dependencies, recursive [flags 0x0]
path-idx 0 NHID 0x0 [0x8ac59f30 0x0]
recursion-via-label
next hop via 24006/1/21
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y recursive 24006/1
Feedback