SR-TE Dynamic Policies

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

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

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.

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
!
segment-routing
 traffic-eng
  affinity-map
   name YELLOW bit-position 1
   name BLUE bit-position 0
   name GREEN bit-position 2

#R1
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/3
   affinity
    name YELLOW
    name BLUE
    name GREEN
!
segment-routing
 traffic-eng
  policy R7_TE
   color 20 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
  !
  policy R7_HOP
   color 30 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
      metric
       type hopcount
  !
  policy R7_IGP
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
      metric
       type igp
  !
  policy R7_USE_BLUE
   color 50 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
     !
     constraints
      affinity
       include-all
        name BLUE
  !
  policy R7_USE_YELLOW_OR_BLUE
   color 60 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
     !
     constraints
      affinity
       include-any
        name BLUE
        name YELLOW
  !
  policy R7_USE_YELLOW_AND_GREEN
   color 40 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
     !
     constraints
      affinity
       include-all
        name GREEN
        name YELLOW

router isis 1
 distribute link-state
 int gi0/0/0/4
  add ipv4 uni
   no metric

#R3
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/9
   affinity
    name YELLOW
    name GREEN
  interface Gi0/0/0/5
   affinity
    name BLUE
    name GREEN

#R9
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/5
   affinity
    name YELLOW
    name GREEN

#R5
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/7
   affinity
    name YELLOW
    name GREEN

Explanation

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.

#R1
segment-routing
 traffic-eng
  policy R7_IGP
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
      metric
       type igp

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:

#R1
segment-routing
 traffic-eng
  policy R7_TE
   color 20 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic

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.

#R1
segment-routing
 traffic-eng
  policy R7_HOP
   color 30 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
      metric
       type hopcount

The last dynamic metric option is latency, which we will explore in a separate lab.

Constraints

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.

#All routers
router isis 1
 address-family ipv4 unicast
  mpls traffic-eng level-2-only
  mpls traffic-eng router-id Loopback1
 !
!
mpls traffic-eng
!
segment-routing
 traffic-eng
  affinity-map
   name YELLOW bit-position 1
   name BLUE bit-position 0
   name GREEN bit-position 2

#R1
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/3
   affinity
    name YELLOW
    name BLUE
    name GREEN

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.

#R1
segment-routing
 traffic-eng
  affinity-map
   name BLACK bit-position 32
  !
  interface GigabitEthernet0/0/0/3
   affinity
    name BLACK

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.

#R1
segment-routing
 traffic-eng
  policy R7_USE_YELLOW_AND_GREEN
   color 40 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
     !
     constraints
      affinity
       include-all
        name GREEN
        name YELLOW

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.

#R1
segment-routing
 traffic-eng
  policy R7_USE_BLUE
   color 50 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
     !
     constraints
      affinity
       include-all
        name 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.

#R1
segment-routing
 traffic-eng
  policy R7_USE_YELLOW_OR_BLUE
   color 60 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
     !
     constraints
      affinity
       include-any
        name BLUE
        name YELLOW

Testing

We can confirm these policies are working by setting the appropriate color value on routes from R7.

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

The most interesting policy is color 40, because two labels are pushed: 16009 and 16007.

Multiple candidate paths

Previously we saw that color 50 is failing. Lets add a fallback candidate path and see if that brings color 50 up.

#R1
segment-routing
 traffic-eng
  policy R7_USE_BLUE
   color 50 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
     !
     constraints
      affinity
       include-all
        name BLUE
    preference 90
     dynamic

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.

#R1
segment-routing
 traffic-eng
  policy R7_HOP
   color 30 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
      metric
       type hopcount
    preference 90
     dynamic

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:

#R1
segment-routing
 traffic-eng
  policy R7_TEST
   color 100 end-point ipv4 7.7.7.1
   candidate-paths
    preference 90
     dynamic
     !
    !
    preference 100
     dynamic
     !
     constraints
      affinity
       include-all
        name GREEN

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

#R1
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/3
   affinity
    no name GREEN

Now candidate path with preference 90 is active, and the BSID is retained:

PreviousSR-TE with AS Primary/Secondary PathsNextSR-TE Dynamic Policy with Margin

Last updated