SR-TE Explicit Paths
Load basic.isis.sr.vpnv4.enabled.cfg
Configure the following policies on R1 with R7 as the endpoint:
Color
Explicit Path
Specified As…
10
via R6, then via R9
IP addresses
20
via R6, then via R9
Labels
30
via R6, then directly to R7
IP addresses
40
via R9, but using UCMP with the dynamic IGP-based path in a 3:1 ratio, where the dynamic path is used 3 times as often
IP addresses
You can test these policies by setting the color from R7 and tracerouting from CE101 to CE107.
Answer
Explanation
SR-TE policies can use explicit paths, which gives you full control over the LSP. Using addresses or labels in the segment-list affects the behavior of the router, though. When using addresses, every single address must resolve to a valid SID (typically a prefix SID or Adj-SID). When using labels, only the very first label is resolved, and any subsequent labels are not. The policy will be up as long as the very first label is valid. This can allow for inter-domain explicit paths that simply use label values, since the router won’t try to resolve MPLS labels for prefix SIDs that aren’t in its own IGP domain.
One thing to be aware of with SR-TE explicit paths is that there is no way to exclude a node or link like you can with RSVP-TE. You can only include addresses/labels. Excluding links can most easily be done by configuring affinities and creating a constraint for the path which excludes those colors.
If desired, you can mix IP addresses and labels in the same explicit path. In the following example, index 2 and index 4 will not be resolved/validated because while they are mpls labels, they are not the first index, so they do not need to be resolved to get the outgoing interface for the SR-TE policy. (Note that this syntax is updated in later 7.x versions - I believe the syntax is “index 1 mpls adjacency|label”).
It’s possible that a given address, for example 4.4.4.1, has multiple prefix SIDs, each with a different algorithm. By deafult, algo 1 is preferred, and then algo 0 is used if algo 1 is not available. You can also specify the algo used with a constraint on the candidate path.
First we’ll explore an explicit path that uses IP addresses.
The router resolves every address to a prefix SID, as seen below. Note that the endpoint of the policy must be present in the explicit segment-list.
If we set the color from R7, we can see that traffic from CE101 to CE107 takes this convoluted path:
Let’s now achieve this same path but use labels instead.
Notice that only the first label is resolved to a prefix SID. The reason for this is that the first MPLS label must be resolved into a nexthop so that the outgoing interface and nexthop L2 adjacency information can be gleaned.
This can be dangerous, because if the path is not actually valid, the router will still report it as up. For example, if we add another label to the stack by accident, and set the color on routes at R7, traffic will be broken.
The router reports this broken policy as up and operational:
However, traffic is not actually working. In most cases, you would never explicitly use labels on the headend itself. Instead a centralized controller, perhaps a PCE, would dynamically calculate the path and then signal it to the headend as an explicit path consisting of labels. The headend does not need to be concerned with validating the entire list, only resolving the first label.
We’ll now look at using Adj-SIDs with an explicit path. You can manually specify the Adj-SID label but this is highly discouraged, as this label is dynamic by default and therefore is subject to change. Instead, we should use link IP addresses which the router will automatically resolve to an Adj-SID label. When both the protected and unprotected Adj-SID are available for use, the router will choose the protected Adj-SID.
After setting the color to 30 on R7, traffic works as expected:
Finally, we can use UCMP with explicit paths. Of course, by default, SR-TE policies are ECMP in nature, as prefix SIDs are used as often as possible to take natural ECMP paths within the network. But we can also manually assign weights to paths within a candidate-path to produce “weighted ECMP” or “UCMP” behavior.
We cannot assign a weight to a dynamic path, so instead we create a second explicit SID which simply uses the destination 7.7.7.1 as the only entry. This should produce IGP-based behavior since the prefix SID that 7.7.7.1 resolves to has the instruction “forward along the IGP lowest-cost path.”
By checking the details of the local label, we can see that the two paths have a ratio of 192:64, or 3:1.
“Loose path” nature of SR-TE segment-lists
You may have noticed that segment-lists seem to have a “loose path” nature by default. In RSVP-TE, the loose keyword (I believe) specifies that the node should preform CSPF itself, which is how inter-domain RSVP-TE works. But with SR-TE segment-lists, you can intuitively define a loose path and the router will resolve it.
What happens if we manually specify more nodes than necessary? For example, if we specify every node in a path that can be more optimally solved with two SIDs?
The router resolves the entire SID list that was specified. There is no label reduction optimization.
Also note that the destination itself must be present in the segment-list. If we remove the last index, the policy is still up but it is no longer a valid path to R7.
Like we saw with the broken MPLS label path, traffic will be broken even though the policy appears to be up. It appears that the router simply resolves each entry one by one, instead of actually running CSPF, trying to find a path through the specified indexes. This explains why there is no SID list reduction optimization too.
Last updated
