If you are familiar with RSVP-TE, you will find that there are some similarities to SR-TE. Both technologies are used to steer traffic along a path that may differ from the IGP best path. This process is traffic-engineering. However, there are also quite a few differences. RSVP-TE uses a tunnel interface to create the LSP. The path is signaled hop-by-hop and periodically refreshed. Path-options are specified under this tunnel interface, and in order to route traffic through the LSP you must statically route or autoroute through the tunnel.
In contrast, SR-TE does not use a tunnel. SR-TE instead uses a policy to define the constraints or explicit path for the LSP. Traffic is not steered along an SR-TE policy using autoroute, but instead is steered using On-Demand Policy (ODN) and Automated Steering (AS). More on this later, but just realize that SR-TE is quite different from RSVP-TE.
An SR-TE policy is defined by three items:
Headend. This is the router where the policy is implemented. The policy will be defined on the headend in our lab, but the policy could also be defined off-box and signaled to the headend via PCEP or NETCONF for example.
Endpoint. This is the destination of the policy (typically the egress PE of an LSP).
Color. This is an arbitrary 32-bit value that is used to differentiate between multiple SR policies that share the same headend and endpoint node.
Make sure not to confuse the color of a policy with link-affinity “color.” Unfortunately the term “color” is used in both of these instances and refers to two separate things. In both cases however, the color is actually a numerical value.
An SR-TE policy uses candidate paths similar to path-options in RSVP-TE. A candidate path can be explicit or dynamic. A dynamic path is similar to a dynamic path in RSVP-TE. You may want to minimize a metric such as TE metric, or have a set of constraints such as avoiding nodes, avoiding TE affinity values, etc. The difference in RSVP-TE is that it finds a single path, even if multiple equal-cost routes exist. SR-TE can use all available ECMP paths for a policy.
An explict path uses either MPLS labels or SID descriptors (node prefixes or link addresses) to define the path. If you use only MPLS labels for the explicit path, the headend only verifies that the first label is valid. (You usually don’t want to use MPLS labels to refer to dynamically allocated adjacency SIDs, because if that router reloads, the MPLS label could change and your explicit path would no longer function correctly). If you use SID descriptors in the explicit path, the headend must verify each entry and resolve it to a label.
Just like RSVP-TE, a policy can have multiple candidate paths. This allows the router to fallback to another less-prefered path if the most prefered path becomes invalid due to a change in the topology. The default candidate path preference value is 100, and the higher the preference, the more preferred the path. The active candidate path is the highest preference path that is a valid path.
Lab
We will use the following topology. All routers are XRv9k due to a limitation in SR-TE configuration commands in XRv. If you cannot run this many XRv9k nodes, then at minimum you must use R1 as an XRv9k and you can run XRv everywhere else, but you won’t be able to use link coloring for dynamic paths.
Here are the startup configs:
#R1
hostname R1
!
int Gi0/0/0/0
ip address 10.1.2.1/24
no shut
!
int lo0
ip address 1.1.1.1/32
!
router ospf 1
segment-routing mpls
area 0
int Gi0/0/0/0
network point-to-point
int Lo0
prefix-sid index 1
#R2
hostname R2
!
int Gi0/0/0/0
ip address 10.1.2.2/24
no shut
!
int Gi0/0/0/1
ip address 10.2.4.2/24
no shut
!
int Gi0/0/0/2
ip address 10.2.3.2/24
no shut
!
int Gi0/0/0/3
ip address 10.2.5.2/24
no shut
!
int lo0
ip address 2.2.2.2/32
!
router ospf 1
segment-routing mpls
area 0
int Gi0/0/0/0
network point-to-point
int Gi0/0/0/1
network point-to-point
int Gi0/0/0/2
network point-to-point
int Gi0/0/0/3
network point-to-point
int Lo0
prefix-sid index 2
#R3
hostname R3
!
int Gi0/0/0/0
ip address 10.2.3.3/24
no shut
!
int Gi0/0/0/1
ip address 10.3.4.3/24
no shut
!
int lo0
ip address 3.3.3.3/32
!
router ospf 1
segment-routing mpls
area 0
int Gi0/0/0/0
network point-to-point
int Gi0/0/0/1
network point-to-point
int Lo0
prefix-sid index 3
#R4
hostname R4
!
int Gi0/0/0/0
ip address 10.3.4.4/24
no shut
!
int Gi0/0/0/1
ip address 10.2.4.4/24
no shut
!
int Gi0/0/0/2
ip address 10.4.6.4/24
no shut
!
int lo0
ip address 4.4.4.4/32
!
router ospf 1
segment-routing mpls
area 0
int Gi0/0/0/0
network point-to-point
int Gi0/0/0/1
network point-to-point
int Gi0/0/0/2
network point-to-point
int Lo0
prefix-sid index 4
#R5
hostname R5
!
int Gi0/0/0/0
ip address 10.2.5.5/24
no shut
!
int Gi0/0/0/1
ip address 10.5.6.5/24
no shut
!
int lo0
ip address 5.5.5.5/32
!
router ospf 1
segment-routing mpls
area 0
int Gi0/0/0/0
network point-to-point
int Gi0/0/0/1
network point-to-point
int Lo0
prefix-sid index 5
#R6
hostname R6
!
int Gi0/0/0/0
ip address 10.4.6.6/24
no shut
!
int Gi0/0/0/1
ip address 10.5.6.6/24
no shut
!
int lo0
ip address 6.6.6.6/32
!
router ospf 1
segment-routing mpls
area 0
int Gi0/0/0/0
network point-to-point
int Gi0/0/0/1
network point-to-point
int Lo0
prefix-sid index 6
We will configure three policies on R1. The “green” path (top), “red” path (bottom), and “blue” path (middle).
Green policy
Let’s configure the first policy for the green path on R1.
segment-routing
traffic-eng
segment-list GREEN_PATH
index 10 mpls label 16005
index 20 mpls adjacency 10.5.6.5
!
policy GREEN
color 10 end-point ipv4 6.6.6.6
candidate-paths
preference 100
explicit segment-list GREEN_PATH
This policy uses an explicit path. First the traffic is steered towards R5 with label 16005. Next the heanded router will resolve 10.5.6.5 to an adjacency SID. You can use either IP address on the link, 10.5.6.5 or 10.5.6.6 and it will resolve to the same adjacency SID label.
We check the policy and see that it cannot resolve 10.5.6.5. What is the problem?
RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy
Mon Sep 5 14:05:21.311 UTC
SR-TE policy database
---------------------
Color: 10, End-point: 6.6.6.6
Name: srte_c_10_ep_6.6.6.6
Status:
Admin: up Operational: down for 00:00:14 (since Sep 5 14:05:06.433)
Candidate-paths:
Preference: 100 (configuration)
Name: GREEN
Requested BSID: dynamic
Explicit: segment-list GREEN_PATH (invalid)
Last error: IPv4 address follows an unresolved label: 10.5.6.5
Weight: 1, Metric Type: TE
Attributes:
Forward Class: 0
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: no
The TE database is often populated by BGP-LS on a PCE. However we are just calculating policies locally on the router. The router needs to populate its SR-TE database with the IGP LSDB. We accomplish this by using the command distribute link-state.
router ospf 1
distribute link-state
The SR-TE database is now populated with information from the IGP. The database contains TE and SR information that is present in LSAs. It is essentially just distributing the LSDB into the SR-TE DB. You can distribute multiple, separate, IGP domains’ LSDBs into the SR-TE database, allowing for multi-domain traffic engineering.
RP/0/RP0/CPU0:R1#show segment-routing traffic-eng ipv4 topology sum
Mon Sep 5 14:08:56.338 UTC
XTC Agent's topology database summary:
--------------------------------
Topology nodes: 6
Prefixes: 6
Prefix SIDs: 6
Links: 14
Adjacency SIDs: 14
Topology Ready Summary:
Ready: yes
Last HA case: startup
Timer value (sec): 300
Timer:
Running: no
The policy is now up and operational:
RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy
Mon Sep 5 14:09:42.524 UTC
SR-TE policy database
---------------------
Color: 10, End-point: 6.6.6.6
Name: srte_c_10_ep_6.6.6.6
Status:
Admin: up Operational: up for 00:01:51 (since Sep 5 14:07:51.303)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: GREEN
Requested BSID: dynamic
Explicit: segment-list GREEN_PATH (valid)
Weight: 1, Metric Type: TE
16005 [Prefix-SID, 5.5.5.5]
24001 [Adjacency-SID, 10.5.6.5 - 10.5.6.6]
Attributes:
Binding SID: 24005
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Notice that there is a binding SID with label 24005. Because we did not manually specify a binding SID on the policy, the policy automatically generated a dynamic label for the binding SID. If R1 receives traffic with this label, it will pop the label and steer the traffic along this policy.
RP/0/RP0/CPU0:R1#show mpls forwarding labels 24005
Mon Sep 5 14:10:48.608 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24005 Pop No ID srte_c_10_ep point2point 0
Also notice that the policy has an auto-generated name of srte_c_<color value>_ep_<endpoint>. The color value and endpoint uniquely identify a policy on a headend router, so these are the only two values needed to create a unique policy name.
Blue and Red policy
We could define two more explicit paths for the blue and red policies, but let’s experiment with link-affinity to dynamically determine these paths. We will color each link in the topology: red, blue, both, or neither.
#R1
router ospf 1
mpls traffic-eng router-id Lo0
area 0
mpls traffic-eng
!
segment-routing
affinity-map
name RED bit-position 20
name BLUE bit-position 21
int Gi0/0/0/0
affinity
name RED
name BLUE
#R2
router ospf 1
mpls traffic-eng router-id Lo0
area 0
mpls traffic-eng
exit
exit
!
segment-routing traffic-eng
affinity-map
name RED bit-position 20
name BLUE bit-position 21
int Gi0/0/0/0
affinity
name RED
name BLUE
int Gi0/0/0/1
affinity
name BLUE
int Gi0/0/0/2
affinity
name RED
#R3
router ospf 1
mpls traffic-eng router-id Lo0
area 0
mpls traffic-eng
exit
exit
!
segment-routing traffic-eng
affinity-map
name RED bit-position 20
name BLUE bit-position 21
int Gi0/0/0/0
affinity
name RED
int Gi0/0/0/1
affinity
name RED
#R4
router ospf 1
mpls traffic-eng router-id Lo0
area 0
mpls traffic-eng
exit
exit
!
segment-routing traffic-eng
affinity-map
name RED bit-position 20
name BLUE bit-position 21
int Gi0/0/0/0
affinity
name RED
int Gi0/0/0/1
affinity
name BLUE
int Gi0/0/0/2
affinity
name RED
name BLUE
#R6
router ospf 1
mpls traffic-eng router-id Lo0
area 0
mpls traffic-eng
exit
exit
!
segment-routing traffic-eng
affinity-map
name RED bit-position 20
name BLUE bit-position 21
int Gi0/0/0/0
affinity
name RED
name BLUE
On R1 we create two policies with dynamic paths, in which every link in the path must include the link-affinity of RED or BLUE.
segment-routing
traffic-eng
policy RED
color 20 end-point ipv4 6.6.6.6
candidate-paths
preference 100
dynamic
constraints
affinity
include-all name RED
policy BLUE
color 30 end-point ipv4 6.6.6.6
candidate-paths
preference 100
dynamic
constraints
affinity
include-all name BLUE
All three policies are currently up:
RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy tabular
Mon Sep 5 15:20:04.656 UTC
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
10 6.6.6.6 up up 24003
20 6.6.6.6 up up 24006
30 6.6.6.6 up up 24008
Explore the paths and SID list that R1 created for the two dynamic policies:
RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy
Mon Sep 5 15:20:43.098 UTC
SR-TE policy database
---------------------
Color: 10, End-point: 6.6.6.6
Name: srte_c_10_ep_6.6.6.6
Status:
Admin: up Operational: up for 00:06:45 (since Sep 5 15:13:57.530)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: GREEN
Requested BSID: dynamic
Explicit: segment-list GREEN_PATH (valid)
Weight: 1, Metric Type: TE
16005 [Prefix-SID, 5.5.5.5]
24001 [Adjacency-SID, 10.5.6.5 - 10.5.6.6]
Attributes:
Binding SID: 24003
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Color: 20, End-point: 6.6.6.6
Name: srte_c_20_ep_6.6.6.6
Status:
Admin: up Operational: up for 00:01:42 (since Sep 5 15:19:00.610)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: RED
Requested BSID: dynamic
Constraints:
Affinity:
include-all:
RED
Maximum SID Depth: 10
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 4
16003 [Prefix-SID, 3.3.3.3]
16006 [Prefix-SID, 6.6.6.6]
Attributes:
Binding SID: 24006
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Color: 30, End-point: 6.6.6.6
Name: srte_c_30_ep_6.6.6.6
Status:
Admin: up Operational: up for 00:00:46 (since Sep 5 15:19:56.797)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: BLUE
Requested BSID: dynamic
Constraints:
Affinity:
include-all:
BLUE
Maximum SID Depth: 10
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 3
16004 [Prefix-SID, 4.4.4.4]
16006 [Prefix-SID, 6.6.6.6]
Attributes:
Binding SID: 24008
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
