# Basic SR-TE with AS

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 R7 using TE as the metric. Configure the R1-R4 link to have a TE metric of 1.



On R7, signal routes learned from CE107 so that R1 steers traffic towards CE107 via the SR-TE policy.













































## Answer <a href="#a83e1fbf-c7b6-4d2d-8def-12296f278154" id="a83e1fbf-c7b6-4d2d-8def-12296f278154"></a>

```
#R1
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/4
   metric 1
  !
  policy R7
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 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
```



## Explanation <a href="#id-7684c26d-1052-489b-8393-8c56fb6dbd6a" id="id-7684c26d-1052-489b-8393-8c56fb6dbd6a"></a>

SR-TE and RSVP-TE both allow the operator to steer traffic along non-IGP paths based on criteria such as link affinity, bandwidth, TE metric, and SRLG disjointness. But SR-TE and RSVP-TE have several differences:

* SR-TE uses the concept of policies for forwarding, while RSVP-TE uses tunnels for forwarding.
* RSVP-TE requires state in the network and explicit signaling. SR-TE policies only require state at the headend itself. The headend statelessly pushes a SID list to steer traffic along the policy.
* SR-TE policies are identified by the tuple (headend, color, endpoint). Color is a numerical value which represents some intent, such as “min delay.” The color differentiates between multiple policies between the same headend and endpoint.
* SR-TE steers traffic by using a BGP color (extcommunity). All VPN services generally use BGP, so this is used instead of any sort of static routing or autoroute announce, as you would use with RSVP-TE. The BGP color is matched against the SR-TE color for that given endpoint.
* A PCE can be used with SR-TE to facilitate inter-area/domain TE paths and constraints that require centralized knowledge such as bandwidth availability or disjointness.
* SR-TE allocates a binding SID for each instantiated policy. This is used as an internal mechanism to forward traffic out the policy, and also allows other routers to steer traffic into another router’s SR-TE policy. This can be used to reduce the MPLS label stack for complex SR-TE LSPs.



First, R1 must have a SR-TED to be able to calculate an SR-TE policy. The SR-TED is fed by the IGP. You simply add the command **distribute link-state** to the IGP. Note that by default, the instance-ID is zero. This is fine for a single-IGP deployment with no PCE. But when you have multiple IGPs you must differentiate them using **distribute link-state instance-id&#x20;**_**num**._

```
#R1
router isis 1
 distribute link-state
```



Next, we’re asked to set the Gi0/0/0/4 link to have a TE metric of 1. With RSVP-TE we would do this under **mpls traffic-eng**, but with SR-TE we can do this under the **segment-routing traffic-eng** process. (Note that you can also configure this under **mpls traffic-eng** and enable MPLS-TE on the IGP instead. The SR-TED will inherit the MPLS-TE link attributes).

```
#R1
segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/4
   metric 1
```



Finally, R1 creates the AS policy. A color (number) and endpoint are explicitly defined. The candidate-paths are similar to RSVP-TE path-options. We’ll simply use a dynamic path which will by default use the TE metric (as with an RSVP-TE dynamic path-option).

```
#R1
segment-routing
 traffic-eng
  policy R7
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     dynamic
```



Above is all that is required for R1 to be able to calculate SR-TE policies. However, R1 does not have the policy up yet. Why is that? The most detail we can see is “No path found.”

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Frxh1ZvfqIZeSgE7CL3er%2Fimage.png?alt=media&#x26;token=f3160231-4c76-4296-9bb2-93064edb33c2" alt=""><figcaption></figcaption></figure></div>



But if we check the SR-TED on R1, we see an entry for R7. So you might think this should be working:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F2cgVnHFdJ5krO5A2sSum%2Fimage.png?alt=media&#x26;token=f8bbfbe2-7aac-4acf-a682-183187e88b96" alt=""><figcaption></figcaption></figure></div>



However, if you look specifically for TE RID 7.7.7.1, no node is shown. R1 cannot calculate the policy because the end-point cannot be found in the SR-TED.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fn0E8NNKj9auGrNowzgoY%2Fimage.png?alt=media&#x26;token=3edb220f-9611-439c-b2fd-4170bc2e3778" alt=""><figcaption></figcaption></figure></div>



To solve this, R7 must advertise an MPLS-TE RID. We must activate MPLS-TE globally and under the IGP in order for R7 to advertise the TE RID. (Another way to do this is simply use **router-id lo1** under ISIS. This is a way to give the router a SR-TE RID without enabling MPLS-TE).

```
#R7
router isis 1
 add ipv4 uni
  mpls traffic-eng router-id lo1
  mpls traffic-eng level-2
!
mpls traffic-eng
```



We now see a TE RID for R7 in the SR-TED:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F2HDejnjb5KppM8wrAFCy%2Fimage.png?alt=media&#x26;token=9dd9e936-7624-46a1-bb01-9e7a8c14ec0b" alt=""><figcaption></figcaption></figure></div>



This allows R1 to bring the policy up. Remember, this is not actually signalled as with RSVP-TE. R1 brings up the policy even though no BGP routes are matching the color yet, because the policy strictly defines the nexthop. (As opposed to ODN policies, which we will look at in the next lab).

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F5fbCggjda9cnxgh9TzCR%2Fimage.png?alt=media&#x26;token=9312b45a-47b8-471f-bbb7-035d6c3efc4a" alt=""><figcaption></figcaption></figure></div>



Now we need to signal the color in a BGP route for R1 to steer traffic into this SR-TE policy. To do so, R7 uses an RPL that sets the color upon routes received from the CE:

```
#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
```



You should see the color attached as an extcommunity on the VPNv4 route received at R1. R1 finds a matching SR-TE policy for this color, and the endpoint (using the BGP nexthop as the matching address for the SR-TE policy endpoint). It finds the BSID assigned to the SR-TE policy (24009) so that traffic can be steered into the policy.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FgdJvR9SpJs8RY4hcOd0f%2Fimage.png?alt=media&#x26;token=0365ba4b-9188-447c-a5f3-5a3fb4481c6d" alt=""><figcaption></figcaption></figure></div>



The details of the route in the VRF RIB show a binding label. This appears to be the only hint that this is steered along an SR-TE policy and not the IGP path.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FB0AdK6XAu48do6fT85Ry%2Fimage.png?alt=media&#x26;token=0802451f-a8fc-4007-824e-8df6b5525e11" alt=""><figcaption></figcaption></figure></div>



The CEF entry uses the BSID to recurse to the SR-TE policy. The nexthop is via “24009” which is the BSID. (I’m not exactly sure what X/0/21 is referring to. This appears to be always attached to the entry). The labels imposed is impnull/24005. 24005 is the service label, and the top label will be found using the SR-TE policy. Usually impnull means to do PHP, but in this case it means “no operation” and instead the SR-TE policy is used for the top label(s).

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FeiKhwZLty1LfU9nMDAM0%2Fimage.png?alt=media&#x26;token=3de54a54-da99-4750-8afe-f493798eb6f0" alt=""><figcaption></figcaption></figure></div>



This is much more powerful than RSVP-TE, where to achieve similar behavior, we needed a per-VRF TE tunnel and a per-VRF source loopback. Not to mention all the additional state that was required as well. SR-TE works elegantly by simply using a BGP extcommunity to determine the SR-TE policy to take.



Traffic from CE101 to CE107 is taking the path via R4:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F0ndl0VM1JL350uhrYzj8%2Fimage.png?alt=media&#x26;token=0fce2903-62d4-4cf3-8b0e-76bc347bcbdc" alt=""><figcaption></figcaption></figure></div>



### SR-TE policy reoptimization <a href="#c3e6eea1-d9ff-4932-87eb-682e26390d3c" id="c3e6eea1-d9ff-4932-87eb-682e26390d3c"></a>

Remove the TE metric on Gi0/0/0/4.

```
#R1
segment-routing
 traffic-eng
  no interface GigabitEthernet0/0/0/4
```



Traffic should now take the path via R3 (the IGP path). But traffic is still going via R4. Why is that?



The reason is that SR-TE reoptimization works similarly to RSVP-TE reoptimization. To trigger reoptimization we actually use the same command **mpls traffic-eng reoptimize** in enable mode. Now traffic flows via R3 again.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FGFHM4mHSDdc6fBJzADa2%2Fimage.png?alt=media&#x26;token=0c8b989e-f28f-46f9-b962-96cce25fd60a" alt=""><figcaption></figcaption></figure></div>



### Other notes <a href="#id-9d938988-824b-498a-850d-40944063be3b" id="id-9d938988-824b-498a-850d-40944063be3b"></a>

If you want to configure an SR-TE policy but don’t want BGP colored routes to use it for AS, you can configure “steering bgp disable” as follows:

```
segment-routing
 traffic-eng
  policy R7
   steering
    bgp disable
```



Also, if there is no valid policy for the color/endpoint on a BGP colored route, the router simply uses the IGP path to the nexthop as usual.
