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
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 ).
-
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 according to following parameters:
-
Target SR policy:
-
Color = 200
-
End-point = 10.1.1.4
-
Auto-generated SR policy name = srte_c_200_ep_10.1.1.4
Note
Use the auto-generated SR-TE policy name to attach the SR policy to the static route. Auto-generated SR policy names use the following naming convention: srte_c_color_val_ep_endpoint-address.Use the show segment-routing traffic-eng policy color <color_val> endpoint ipv4 <ip_addr> command to display the auto-generated policy name.
-
-
Admin distance = 40
-
Load metric = 150
-
Install the route in RIB regardless of reachability
Router(config)# router static
Router(config-static)# address-family ipv4 unicast
Router(config-static-afi)# 10.1.1.4/32 sr-policy srte_c_200_ep_10.1.1.4 40 permanent metric 150
Running Configuration
router static
address-family ipv4 unicast
10.1.1.4/32 sr-policy srte_c_200_ep_10.1.1.4 40 permanent metric 150
!
!
Verification
RP/0/RP0/CPU0:RTR-1# show run segment-routing traffic-eng policy sample-policy-foo
Tue Feb 16 17:40:16.759 PST
segment-routing
traffic-eng
policy sample-policy-foo
color 200 end-point ipv4 10.1.1.4
candidate-paths
preference 100
dynamic
metric
type te
!
!
!
!
!
!
!
RP/0/RP0/CPU0:RTR-1# show segment-routing traffic-eng policy color 200 endpoint ipv4 10.1.1.4
Tue Feb 16 17:17:45.724 PST
SR-TE policy database
---------------------
Color: 200, End-point: 10.1.1.4
Name: srte_c_200_ep_10.1.1.4
Status:
Admin: up Operational: up for 5d04h (since Feb 11 12:22:59.054)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: sample-policy-foo
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 10
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 14
16005 [Prefix-SID, 10.1.1.5]
16004 [Prefix-SID, 10.1.1.4]
Attributes:
Binding SID: 24014
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
RP/0/RP0/CPU0:RTR-1# show static sr-policy srte_c_200_ep_10.1.1.4
Tue Feb 16 17:50:19.932 PST
Interface VRF State Paths
srte_c_200_ep_10.1.1.4 default Up 10.1.1.4/32
Reference Count(in path with both intf<-->NH):0
Last IM notification was Up at Feb 16 17:09:08.325
Global ifh : 0x0000007c
IM state : up
RSI registration : Yes
Table IDs : 0xe0000000
Address Info:
10.1.1.1/32
Route tag: 0x00000000 Flags: 0x00000000 Prefix SID: False [Active]
IP-STATIC-IDB-CLASS
Total entries : 1
Interface : sr-srte_c_200_ep_10.1.1.4
| Event Name | Time Stamp | S, M
| idb-create | Feb 16 17:09:08.352 | 0, 0
RP/0/RP0/CPU0:RTR-1# show route 10.1.1.4/32
Tue Feb 16 17:09:21.164 PST
Routing entry for 10.1.1.4/32
Known via "static", distance 40, metric 0 (connected)
Installed Feb 16 17:09:08.325 for 00:00:13
Routing Descriptor Blocks
directly connected, via srte_c_200_ep_10.1.1.4, permanent
Route metric is 0, Wt is 150
No advertising protos.
RP/0/RP0/CPU0:RTR-1# show route 10.1.1.4/32 detail
Tue Feb 16 17:09:36.718 PST
Routing entry for 10.1.1.4/32
Known via "static", distance 40, metric 0 (connected)
Installed Feb 16 17:09:08.325 for 00:00:28
Routing Descriptor Blocks
directly connected, via srte_c_200_ep_10.1.1.4, permanent
Route metric is 0, Wt is 150
Label: None
Tunnel ID: None
Binding Label: None
Extended communities count: 0
NHID:0x0(Ref:0)
Route version is 0x4a (74)
Local Label: 0x3e84 (16004)
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_RECURSIVE (9) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 3, Download Version 258
No advertising protos.
RP/0/RP0/CPU0:RTR-1# show cef 10.1.1.4/32 detail
Tue Feb 16 17:10:06.956 PST
10.1.1.4/32, version 258, attached, internal 0x1000441 0x30 (ptr 0xd3f0d30) [1], 0x0 (0xe46f960), 0xa20 (0xe9694e0)
Updated Feb 16 17:09:08.328
Prefix Len 32, traffic index 0, precedence n/a, priority 3
gateway array (0xe2d9a08) reference count 2, flags 0x8068, source rib (7), 0 backups
[3 type 4 flags 0x108401 (0xe9aeb98) ext 0x0 (0x0)]
LW-LDI[type=1, refc=1, ptr=0xe46f960, sh-ldi=0xe9aeb98]
gateway array update type-time 1 Feb 16 17:07:59.946
LDI Update time Feb 16 17:07:59.946
LW-LDI-TS Feb 16 17:07:59.946
via srte_c_200_ep_10.1.1.4, 5 dependencies, weight 0, class 0 [flags 0xc]
path-idx 0 NHID 0x0 [0xf3b1a30 0x0]
local adjacency
local label 16004 labels imposed {None}
Load distribution: 0 (refcount 3)
Hash OK Interface Address
0 Y srte_c_200_ep_10.1.1.4 point2point
RP/0/RP0/CPU0:RTR-1# show mpls forwarding labels 16004 detail
Tue Feb 16 17:27:59.831 PST
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16004 Unlabelled SR Pfx (idx 4) srte_c_200_e point2point 990
Updated: Feb 16 17:07:59.945
Path Flags: 0xc [ ]
Version: 258, Priority: 3
Label Stack (Top -> Bottom): { Unlabelled Unlabelled }
NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0
MAC/Encaps: 0/0, MTU: 0
Outgoing Interface: srte_c_200_ep_10.1.1.4 (ifhandle 0x0000007c)
Packets Switched: 20
Feedback