Have you checked my previous blogs on segment routing ? You can find them here :

GNS3 LAB: Segment Routing Configuration on Cisco IOS-XE and IOS-XR routers.

GNS3 LAB Cisco : Segment Routing traffic engineering configuration on IOS-XE routers.

In this blog, I will discuss about the explicit path SRTE policy. You must remember MPLS TE tunnels where we needed to configure tunnel endpoints manually. SRTE gives and alternative method and you no longer need to maintain tunnels. Each SR policy is identified as a tuple of three values [ head-end, color and end point]. Inside the SR TE policy you can configure Explicit and dynamic paths, give different preferences to different candidate paths, configure metrics, load sharing criteria and so many other things. In this example I will configure SRTE policy with explicit and dynamic option.

Since you came looking for SRTE so I can assume that you already know that in order to prepare the network for segment routing configuration you need to have several basic things configured like IGP with segment routing enabled, mpls traffic engineering which needs to be enabled on all routers and head-end tail-end routers etc. If you have any doubt, I highly recommend you go through my first two blogs on segment routing(check links at the beginning of this blog).

Lets get started with the configuration.

In the given network diagram I will configure traffic engineering between R1-XE and R4-XR. lets see the quick configuration to do that.

NOTE : You can configure SRTE policies on IOS-XE routers as well. Here I have used static tunnels on XE routers and SRTE policies are configured only on XR router. I wanted to show that we can do traffic engineering in either ways.

Configurations :

STEP-1 : Bring up Tunnels

R1-XE Router:

!
interface Tunnel2
 ip unnumbered Loopback1
 tunnel mode mpls traffic-eng
 tunnel destination 4.4.4.4
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng priority 6 6
 tunnel mpls traffic-eng path-option 20 explicit name SR-PATH-R4 segment-routing
!
ip explicit-path name SR-PATH-R4 enable
 index 1 next-label 16002
 index 2 next-label 16004
!

R4-XR Router:

segment-routing
 traffic-eng
  segment-list SR-PATH-R1
   index 1 mpls label 16002
   index 2 mpls label 16001
  !
  policy POL1
   color 20 end-point ipv4 1.1.1.1
   candidate-paths
    !
    preference 100
     explicit segment-list SR-PATH-R1
     !
    !
   

Above is the only configuration needed and your TE path will come up between the routers bidirectionally.You can check it with below command.

RP/0/0/CPU0:R4-XR#sh segment-routing traffic-eng policy
Mon Aug  2 06:55:54.065 UTC

SR-TE policy database
---------------------

Name: POL1 (Color: 20, End-point: 1.1.1.1)
  Status:
    Admin: up  Operational: up for 00:00:23 (since Aug  2 06:55:30.966)
  Candidate-paths:
    Preference 100:
      Explicit: segment-list SR-PATH-R1 (active)
        Weight: 1, Metric Type: TE
          16002 [Prefix-SID, 2.2.2.2]
          16001
  Attributes:
    Binding SID: 24006
      Allocation mode: dynamic
      State: Programmed
      Policy selected: yes
    Forward Class: 0
    Steering BGP disabled: no
    IPv6 caps enable: no

RP/0/0/CPU0:R4-XR#

STEP-2 : Putting Traffic on Tunnels

In my previous examples, I used the simplest method to put traffic on the MPLS TE tunnel which is static route. Here as well I wanted to see if this method works or not, and interestingly this is available. I have 192.168.10.2/32 loopback on R1-XE router which is not advertised anywhere. On R4-XR I have a loopback 192.168.20.2/32. These two loopbacks are using static route over SRTE tunnels to reach to each other.

RP/0/0/CPU0:R4-XR#sh run  router static
router static
 address-family ipv4 unicast
  192.168.10.2/32 sr-policy POL1 ------> Here as a destination interface we need to put the segment routing policy
 !
!
RP/0/0/CPU0:R4-XR#sh route 192.168.10.2
Mon Aug  2 07:18:26.232 UTC
Routing entry for 192.168.10.2/32
  Known via "static", distance 1, metric 0 (connected)
  Installed Aug  2 06:55:30.976 for 00:22:55
  Routing Descriptor Blocks
    directly connected, via POL1
      Route metric is 0, Wt is 1
  No advertising protos.

RP/0/0/CPU0:R4-XR#ping 192.168.10.2
Mon Aug  2 07:18:42.811 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

RP/0/0/CPU0:R4-XR#traceroute 192.168.10.2
Mon Aug  2 07:18:49.190 UTC
Type escape sequence to abort.
Tracing the route to 192.168.10.2

 1  10.10.10.9 [MPLS: Label 16001 Exp 0] 0 msec  0 msec  69 msec------> segment-routing path
 2  10.10.10.1 9 msec  *  0 msec
RP/0/0/CPU0:R4-XR#

Dynamic SR-TE tunnel

In this section we are going to achieve the same thing what we have achieved in previous section but with the help of dynamic TE tunnels. I will demonstrate the XR configuration for the same. Lets see the configuration.

RP/0/0/CPU0:R4-XR#sh run router isis
router isis LAB
 is-type level-1
 net 49.0000.0000.0000.0004.00
 distribute link-state
!
RP/0/0/CPU0:R4-XR#sh run segment-routing
!
segment-routing
 traffic-eng
!
  policy POL1
   color 20 end-point ipv4 1.1.1.1
   candidate-paths
    !
    preference 101
     dynamic
      metric
       type te
      !
     !
    !
   !
  !
 !
!

You can check the policy status with below command.

RP/0/0/CPU0:R4-XR#sh segment-routing traffic-eng policy
Mon Aug  2 07:40:29.331 UTC

SR-TE policy database
---------------------

Name: POL1 (Color: 20, End-point: 1.1.1.1)
  Status:
    Admin: up  Operational: up for 00:44:58 (since Aug  2 06:55:30.966)
  Candidate-paths:
    Preference 101:
      Path Metrics:
        Margin Absolute: 0
        Margin Relative: 0%
        Maximum SID Depth: 10
      Dynamic (active)
        Metric Type: TE,   Path Accumulated Metric: 20
          16001 [Prefix-SID, 1.1.1.1]
  Attributes:
    Binding SID: 24006
      Allocation mode: dynamic
      State: Programmed
      Policy selected: yes
    Forward Class: 0
    Steering BGP disabled: no
    IPv6 caps enable: no

RP/0/0/CPU0:R4-XR#

I still have the static route, refer previous section(STEP-2 : Putting Traffic on Tunnels). Lets check if we have the reach over the dynamic SRTE tunnel or not.

RP/0/0/CPU0:R4-XR#ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

RP/0/0/CPU0:R4-XR#traceroute  192.168.10.2
Type escape sequence to abort.
Tracing the route to 192.168.10.2

 1  10.10.10.9 [MPLS: Label 16001 Exp 0] 0 msec  49 msec  9 msec
 2  10.10.10.1 0 msec  *  0 msec
RP/0/0/CPU0:R4-XR#

Conclusion :

So far, I have covered Basic segment routing, SRTE with static tunnels, SRTE Policies etc. Now I will move to load-sharing in SRTE policies and FRR in my next blogs. SRTE policies seems to provide a better approach to achieve the same thing we did in MPLS RSVP based traffic engineering. Also, the configuration and troubleshooting is better and manageable. Stay tuned and I will discuss more on traffic forwarding in SRTE scenario. Thanks for visiting.

Check my youtube channel for a quick video on SRTE!!