SR-TE Dynamic Policies
Last updated
Last updated
Load basic.isis.sr.vpnv4.enabled.cfg
Configure the link affinities as shown in the diagram above. The colors should be BLUE, YELLOW and GREEN.
Configure the R1-R4 link with IGP metric 10
Configure the following policies on R1 with R7 as the endpoint:
Color
Constraint
10
IGP metric
20
TE metric
30
hopcount
40
Use YELLOW and GREEN links
50
Use only BLUE links
60
Use YELLOW or BLUE links
You can test these policies by setting the color from R7 and tracerouting from CE101 to CE107.
SR-TE dynamic policies use candidate paths. Each candidate path has a preference - the higher the number, the better the candidate path. If the candidate path cannot be satisfied, the next-preferred path is tried. Note that this is the opposite of RSVP-TE, in which a lower path-option (ex. 1) is better than a higher numbered path-option (ex. 2).
SR-TE policies allow for four dynamic metric types:
IGP
TE (default)
hopcount
latency
Only the IGP metric type allows for ECMP. We can test this by examining our color 10 (IGP) and color 20 (TE) policies. The color 10 policy simply uses the prefix SID for R7. There are two ECMP routes, via R3 and via R4.
By examining the local label, 24016, we see that there are two outgoing interfaces.
We can also see this information using the command show segment-routing traffic-eng forwarding. Note that this was done after the initial lab writeup, so the BSID and local label is now different. But you can still see the two paths that are used and the outgoing label stack.
SR-TE uses the “SR-native” algorithm which tries to optimize ECMP as much as possible, and tries to reduce the SID list (label stack) as much as possible.
In contrast, we can see that the TE policy (color 20) only uses the path via R4. The router uses R4’s prefix SID and then R7’s prefix SID:
I believe the reason for this is that the prefix SIDs have an algo of 0, meaning IGP best path. Therefore only an IGP dynamic policy can use prefix SIDs for ECMP. When using TE, since 16007 doesn’t mean “use the TE-based shortest path to R7”, one path must be explicitly used.
We can also see this with the hop count policy. Because the metric to optimize is hop count, not IGP cost, the router doesn’t do ECMP. Instead it picks a single path.
The last dynamic metric option is latency, which we will explore in a separate lab.
We’ll now explore the constraints we can use on a policy. This includes:
Link affinity (color)
SRLG
Does not work on XRv
Disjointness (requires PCE)
Explored in a separate lab
Flex-algo
Expored in a separate lab
To assign colors to a link, we first must define a bit position for a color. This is traditionally a number between 0-31, however using extensions it can be a number up to 255. Each router then assigns affinity names to links. This is advertised into the IGP, just like in RSVP-TE. Alternatively, you could configure this under MPLS-TE instead, and the functionality would be the same.
By examining R1’s LSP, we can see the affinity value. All three bit positions are turned on, resulting in a value of 0x7.
Notice there are 8 extended admin groups, each with a length of 32. This gives us 256 possible bit positions (0-255).
If we configure a new value with bit position 32, we should see the next admin group is used. The legacy affinity value stays the same, but the extended admin group TLV advertises 0x1 on the second set of values.
We can use these affinity values in policies in three ways:
Include all values (logical AND)
Every link must belong to every affinity group specified
Include any value (logical OR)
Every link must belong to any one of the affinity groups specified
Exclude any values (logical OR)
Every link in the path must not have any of the affinity groups specified
Let’s explore color 40. This must use links that are both YELLOW and GREEN.
Color 50 must use only BLUE links. However, the policy cannot be setup. This is because there is no path to R7 in which every link is BLUE.
Color 60 uses either YELLOW or BLUE links. A path can be found since a link can be either color to meet the constraint.
We can confirm these policies are working by setting the appropriate color value on routes from R7.
The most interesting policy is color 40, because two labels are pushed: 16009 and 16007.
Previously we saw that color 50 is failing. Lets add a fallback candidate path and see if that brings color 50 up.
We can see that preference 100 is tried first, but fails as expected. Next preference 90 is tried, and a path is found:
Note that each candidate path is only tried if the previous fails - not if there is a tie. For example, if we add a candidate path to a currently working policy with a preference worse than the existing candidate path, it will not be used.
I believe that preference 90 is invalid because it isn’t even tried, as preference 100 already succeeded.
Also, even though each candidate path technically has its own requested BSID, in practice the same BSID will be used between all candidate paths for a policy. For example, let’s configure a policy that uses two candidate paths:
The policy is satisfied using preference 100, and a BSID of 24030 is used.
Let’s now remove the GREEN affinity color from the local link on R1. This change in the SR-TED will cause R1 to reoptimize its policies and find that the first candidate path with preference 100 is no longer valid. The TE policy will need to fallback to the candidate path with preference 90. Any IGP topology change will cause a headend or PCE to recalculate paths or re-validate explicit paths. (We will see explicit paths in upcoming labs).
Now candidate path with preference 90 is active, and the BSID is retained:
