Basic SR-TE with AS and ODN

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

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

VPNv4 is fully setup and working with CEs 101, 102, 107, 108.

Configure an SR-TE policy on R1 that steers traffic towards any nexthop using TE as the metric. Use color 10 for this policy. Configure the R1-R4 link to have a TE metric of 1.

On R7 and R8, signal routes learned from the locally-connected CE so that R1 steers traffic towards CE107 and CE108 via this SR-TE policy.

Answer

#R1
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/4
   metric 1
  !
  on-demand color 10
   dynamic
!
router isis 1
 distribute link-state

#R7
extcommunity-set opaque COLOR10
  10
end-set
!
route-policy CE107_IN
  set extcommunity color COLOR10
end-policy
!
router bgp 100
 vrf BLUE
  neighbor 192.168.107.107
   address-family ipv4 unicast
    route-policy CE107_IN in
!
router isis 1
 add ipv4 uni
  mpls traffic-eng router-id lo1
  mpls traffic-eng level-2
!
mpls traffic-eng

#R8
extcommunity-set opaque COLOR10
  10
end-set
!
route-policy CE108_IN
  set extcommunity color COLOR10
end-policy
!
router bgp 100
 vrf BLUE
  neighbor 192.168.108.108
   address-family ipv4 unicast
    route-policy CE108_IN in
!
router isis 1
 add ipv4 uni
  mpls traffic-eng router-id lo1
  mpls traffic-eng level-2
!
mpls traffic-eng

Explanation

ODN (On-Demand Steering) solves the scalability problem that is present with regular AS (automated steering), in which every possible endpoint needs to be specified on each headend. With ODN, we instead have a single policy that only identifies a color. Any BGP route with the matching color will automatically generate an SR-TE policy with the BGP nexthop as the policy endpoint.

Where AS automates the steering of traffic into a service route, ODN automates the instantiation of the SR-TE policy itself.

An ODN policy cannot use multiple candidate paths. This is because the ODN policy itself is essentially a candidate path. If you had the ability to configure multiple candidate paths, then the policy could unpredictably mean different things on different routers. You don’t lose any “fallback” features due to this, because if the policy cannot be calculated, the router will just fallback to IGP forwarding.

The ODN policy is configured on R1 as follows:

#R1
segment-routing
 traffic-eng
  on-demand color 10
   dynamic

R1 must also distribute the LSDB into the SR-TED, and set the Gi0/0/0/4 link to have a TE metric of 1.

#R1
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/4
   metric 1
!
router isis 1
 distribute link-state

Notice that R1 has not brought up any SR-TE policies. This is because no BGP routes match the color value of 10 yet.

Next, we configure R7 and R8 to set the BGP color to 10 on routes received from the CE. This is no different than the previous lab. R7 and R8 must advertise a TE RID into the IGP so that they can be used as endpoints in the SR-TED on R1. (R1 does not need to advertise a TE RID in this lab because it is only a headend. In the real world you would do this on all routers).

#R7
extcommunity-set opaque COLOR10
  10
end-set
!
route-policy CE107_IN
  set extcommunity color COLOR10
end-policy
!
router bgp 100
 vrf BLUE
  neighbor 192.168.107.107
   address-family ipv4 unicast
    route-policy CE107_IN in
!
router isis 1
 add ipv4 uni
  mpls traffic-eng router-id lo1
  mpls traffic-eng level-2
!
mpls traffic-eng

#R8
extcommunity-set opaque COLOR10
  10
end-set
!
route-policy CE108_IN
  set extcommunity color COLOR10
end-policy
!
router bgp 100
 vrf BLUE
  neighbor 192.168.108.108
   address-family ipv4 unicast
    route-policy CE108_IN in
!
router isis 1
 add ipv4 uni
  mpls traffic-eng router-id lo1
  mpls traffic-eng level-2
!
mpls traffic-eng

R1 now sees two VPNv4 routes with color 10. We’ll look at the route from R8. Interestingly, we see the phrase “registered” now. Before without ODN, we saw “not registered.” So “registered” appears to be refering to registering the ODN policy and instantiating it.

We can see that R1 has created two SR-TE policies automatically:

Just as before, the BSID is used internally to steer traffic along the SR-TE policy. This is the same as we saw in the last lab. The only difference now is that the SR-TE policies were created on-demand instead of explicitly defined for each individual endpoint. This makes SR-TE with ODN extremely scalable.

Traffic from CE101 to CE107 and CE108 takes the path via R4. Traffic to CE102 still takes the IGP path via R3:

What happens if there is both an explicit SR-TE policy and ODN policy?

I’ve created the following policies on R1:

#R1
segment-routing
 traffic-eng
  on-demand color 10
   dynamic
   !
  !
  policy R7
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     dynamic
      metric
       type igp

R1 automatically brings up the policy with the explicit end-point. But the ODN policy is not up yet. No matching BGP routes are injected yet.

I now set the BGP color on the routes received at R7. The router appears to use the BSID that was created for the explicit (non-ODN) policy. However, we see the “registered” flag which is only see when the color matches an ODN policy.

If we look at the details of the SR-TE policy, we see that the ODN policy is actually just another candidate-path on the explicit policy (screenshot below). In fact it is two candidate-paths, one with preference 200 for local computation, and one with preference 100 for PCE computation. If the router fails to compute the path, it will try to compute it using a PCE. Note that you can disable the local computation candidate path with preference 200 using the following command. When you do this, you will see the preference 200 path as “shutdown” in the show output.

#R1
segment-routing
 traffic-eng
  on-demand color 10
   dynamic
    pcep

The explicit policy’s candidate path preference is 10. The BGP ODN preference is higher (200) and is used instead. When a policy already exists for the color/endpoint pair, any new policies that are learned, such as via ODN or a PCE, are added as candidate paths to the existing policy.

If we were to make the explicit policy have a higher preference (such as 300), we can prefer the explicit policy over the ODN policy.

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

It does not appear that you can control the ODN preference numbers, so playing with the explicit policy’s candidate-preferences can be used to influence the SR-TE policy path choice.