SR-TE RSVP-TE Stitching

Load sr-te.rsvp-te.stitching.init.cfg.

configure
load bootflash:sr-te.rsvp-te.stitching.init.cfg
commit replace
y

There is an RSVP-TE tunnel on R3 taking the path R3-R4-R6-R5. On R1, configure an SR-TE policy that uses R7 as an endpoint and is steered into the RSVP-TE tunnel on R3 without using autoroute announce on R3 or static routes.

Answer

#R3
int tunnel-te5
 binding-sid mpls label 4005

#R1
segment-routing
 traffic-eng
  segment-list R7_VIA_RSVP
   index 1 mpls label 16003
   index 2 mpls label 4005
   index 3 mpls label 16007
  !
  policy R7_VIA_RSVP
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     explicit segment-list R7_VIA_RSVP

Explanation

Allocating a BSID to an RSVP-TE tunnel allows it to be used by SR-TE policies. This can be a way to stitch an SR-TE path over a core which does not support SR-TE, and only supports RSVP-TE.

It is very straight forward to allocate a BSID to a TE tunnel, simply using the below command:

int tunnel-te5
 binding-sid mpls label <16-4015>

Alternatively, you can use the following command, which will allocate a BSID for the TE tunnel from the dynamic range.

int tunnel-te5
 binding-sid mpls

On R3, we can see that an LFIB entry was created for lab 4005, with outgoing instruction “pop and forward out TE tunnel.”

This allows R1 to use the BSID label 4005 in a local SR-TE policy. As with any local SID, we first specify the target node, and then specify the local SID. Finally, we use R7’s prefix SID to get to the final destination.

#R1
segment-routing
 traffic-eng
  segment-list R7_VIA_RSVP
   index 1 mpls label 16003
   index 2 mpls label 4005
   index 3 mpls label 16007
  !
  policy R7_VIA_RSVP
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     explicit segment-list R7_VIA_RSVP

R1 only validates the first label in the explicit path, so it doesn’t matter that R1 does not learn of label 4005 from some other means.

To test this out, R7 sets routes received from CE107 to have the color 10:

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

A traceroute from CE101 to CE107 shows that traffic is indeed being steered along the RSVP-TE path:

We can also test by examining the output counters on the TE tunnel on R3.

#CE101
ping 107.107.107.1 so lo1 repeat 100