SR-TE Explicit Paths

Load basic.isis.sr.vpnv4.enabled.cfg

configure
load bootflash:basic.isis.sr.vpnv4.enabled.cfg
commit replace
y

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

#All routers
router isis 1
 address-family ipv4 unicast
  mpls traffic-eng level-2-only
  mpls traffic-eng router-id Loopback1
 !
!
mpls traffic-eng

#R1
router isis 1
 distribute link-state
!
segment-routing
 traffic-eng
  segment-list R7_IGP_BASED
   index 1 address ipv4 7.7.7.1
  !
  segment-list R6_R7_ADDRESSES
   index 1 address ipv4 6.6.6.1
   index 2 address ipv4 10.6.7.7
  !
  segment-list R6_R9_R7_LABELS
   index 1 mpls label 16006
   index 2 mpls label 16009
   index 3 mpls label 16007
  !
  segment-list R9_R7_ADDRESSES
   index 1 address ipv4 9.9.9.1
   index 2 address ipv4 7.7.7.1
  !
  segment-list R6_R9_R7_ADDRESSES
   index 1 address ipv4 6.6.6.1
   index 2 address ipv4 9.9.9.1
   index 3 address ipv4 7.7.7.1
  !
  policy R7_COLOR_10
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R6_R9_R7_ADDRESSES
  !
  policy R7_COLOR_20
   color 20 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R6_R9_R7_LABELS
  !
  policy R7_COLOR_30
   color 30 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R6_R7_ADDRESSES
  !
  policy R7_COLOR_40
   color 40 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R7_IGP_BASED
      weight 3
     !
     explicit segment-list R9_R7_ADDRESSES

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”).

segment-routing
 traffic-eng
  segment-list TEST
   index 1 address ipv4 4.4.4.1
   index 2 mpls label 16006
   index 3 address ipv4 9.9.9.1
   index 4 mpls label 16008

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.

segment-routing
 traffic-eng
  policy EXAMPLE
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R6_R9_R7_ADDRESSES
     !
     constraints
      segments
       sid-algorithm <128-255>

First we’ll explore an explicit path that uses IP addresses.

#R1
segment-routing
 traffic-eng
  segment-list R6_R9_R7_ADDRESSES
   index 1 address ipv4 6.6.6.1
   index 2 address ipv4 9.9.9.1
   index 3 address ipv4 7.7.7.1
  !
  policy R7_COLOR_10
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R6_R9_R7_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:

#R7
extcommunity-set opaque TEST
  10
end-set
!
route-policy SET_COLOR
  set extcommunity color TEST
end-policy
!
router bgp 100
 vrf BLUE
  neighbor 192.168.107.107
   address-family ipv4 unicast
    route-policy SET_COLOR in

Let’s now achieve this same path but use labels instead.

#R1
segment-routing
 traffic-eng
  segment-list R6_R9_R7_LABELS
   index 1 mpls label 16006
   index 2 mpls label 16009
   index 3 mpls label 16007
  !
  policy R7_COLOR_20
   color 20 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R6_R9_R7_LABELS

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.

#R1
segment-routing
 traffic-eng
  segment-list R6_R9_R7_LABELS
   index 4 mpls label 16077

#R7
extcommunity-set opaque TEST
  20
end-set

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.

#R1
segment-routing
 traffic-eng
  segment-list R6_R7_ADDRESSES
   index 1 address ipv4 6.6.6.1
   index 2 address ipv4 10.6.7.7
  !
  policy R7_COLOR_30
   color 30 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R6_R7_ADDRESSES

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.”

#R1
segment-routing
 traffic-eng
  segment-list R9_R7_ADDRESSES
   index 1 address ipv4 9.9.9.1
   index 2 address ipv4 7.7.7.1
  !
  segment-list R7_IGP_BASED
   index 1 address ipv4 7.7.7.1
  !
  policy R7_COLOR_40
   color 40 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list R9_R7_ADDRESSES
     explicit segment-list R7_IGP_BASED weight 3

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?

#R1
segment-routing
 traffic-eng
  segment-list VERY_LONG
   index 1 address ipv4 3.3.3.1
   index 2 address ipv4 9.9.9.1
   index 3 address ipv4 5.5.5.1
   index 4 address ipv4 7.7.7.1
  policy R7_COLOR_100
   color 100 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     explicit segment-list VERY_LONG

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.

#R1
segment-routing
 traffic-eng
  segment-list VERY_LONG
   no index 4 address ipv4 7.7.7.1

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.