# SR-TE BSIDs

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

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

Configure three SR-TE policies on R1 that simply use a dynamic path to endpoint 7.7.7.1

* Policy 1 should use BSID 15000
* Policy 2 should also use BSID 15000
* Policy 3 should not specify any BSID

Ensure that policy 2 is not invalidated due to the BSID conflict. (Policy 2 should come up). Ensure that policy 3 does not come up since it does not specify an explicit BSID.

## Answer <a href="#ba816cd0-888e-44e2-93b9-8a618b0dfb06" id="ba816cd0-888e-44e2-93b9-8a618b0dfb06"></a>

```
#All routers
router isis 1
 distribute link-state
 address-family ipv4 unicast
  mpls traffic-eng level-2-only
  mpls traffic-eng router-id Loopback1
 !
!
mpls traffic-eng

#R1
segment-routing
 traffic-eng
  binding-sid dynamic disable
  binding-sid explicit fallback-dynamic
  !
  policy POL1
   binding-sid mpls 15000
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
  !
  policy POL2
   binding-sid mpls 15000
   color 20 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
  !
  policy POL3
   color 30 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
```

## Explanation <a href="#ad9c848c-d715-47af-bea2-49c108d08d8a" id="ad9c848c-d715-47af-bea2-49c108d08d8a"></a>

A Binding SID (BSID) is a local label that is bound to an SR-TE policy. This is used both internally and externally to steer traffic into an SR-TE policy. Internally, the router will recurse BGP service routes with the matching color/endpoint on the BSID label in order to steer traffic into the SR-TE policy. Externally, nodes can steer traffic into a remote router’s SR-TE policy by using its local BSID label, similar to using a remote node’s Adj-SID labels.

A BSID is by default dynamically allocated from the dynamic label range (24000+). If you want to make the BSID predictable, you should explicitly allocate the label. It is recommended to do this from the SRLB (by deafult 15000-15999). The router will allow you to explicitly allocate a dynamic label, but it is not guaranteed to be available for use at bootup.

To start, we’ll simply create one policy with an explicit BSID. First, notice that R1 does not have an SRLB set yet, because we have not configured **segment-routing** globally.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FVrl76yFCTn5Mhn0GP4lJ%2Fimage.png?alt=media&#x26;token=aa6de1a0-c57b-4316-97f0-29c82035e58e" alt=""><figcaption></figcaption></figure></div>

By configuring the first SR-TE policy, we will allocate the default SRLB.

```
#R1
segment-routing
 traffic-eng
  policy POL1
   binding-sid mpls 15000
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
```

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F3vztcS6wf8SPCXqTHeiK%2Fimage.png?alt=media&#x26;token=2a4df818-f0ef-4f5f-9d6a-0bc07bf438d8" alt=""><figcaption></figcaption></figure></div>

The SR-TE policy has the explicit BSID associated with it:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FNzR1yLDV66dnuASedlYB%2Fimage.png?alt=media&#x26;token=b83d969e-04af-417f-acf0-4fc40727118a" alt=""><figcaption></figcaption></figure></div>

This can be used for example, when you have Anycast nodes that have the same policy to a remote node. You can steer traffic to any one of these nodes using the Anycast SID, and then use the common BSID value next, which they all share.

We’ll now configure the next policy to use the same explicit BSID. This will fail, because the BSID label is already in use. Each BSID must be unique to each SR-TE policy. Notice the syslog message we receive:

```
#R1
segment-routing
 traffic-eng
  policy POL1
   binding-sid mpls 15000
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
  !
  policy POL2
   binding-sid mpls 15000
   color 20 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
```

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FmeLZbwmwgh2rVQlIY8kT%2Fimage.png?alt=media&#x26;token=46e4566f-8837-4e51-8e96-92eaf3066fee" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FQ6t0sfDK0oQSaFG5OBpi%2Fimage.png?alt=media&#x26;token=9a36deae-ec62-4fc8-b3aa-31f3124e5f12" alt=""><figcaption></figcaption></figure></div>

To allow the router to fallback to a dynamic label when the explicit BSID label cannot be created, we can use the following command:

```
#R1
segment-routing
 traffic-eng
  binding-sid explicit fallback-dynamic
```

Note that this is not compatible with the command **binding-sid explicit enforce-srlb**. You can only use one of these commands or the other. The **enforce-srlb** command requires that an explicit BSID be within the SRLB. Without this command, you are allowed to explicitly allocate a BSID label from the dynamic range.

With the **fallback-dynamic** command applied. POL2 falls back to a dynamic label allocation.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F04hC5YJLoVgICGITeOin%2Fimage.png?alt=media&#x26;token=91876203-4303-4f2b-9d7e-13fc9f9438b3" alt=""><figcaption></figcaption></figure></div>

Another knob we have is to require all policies to have an explicit BSID.

```
#R1
segment-routing
 traffic-eng
  binding-sid dynamic disable
```

If we try to create a third policy that does not specify an explicit BSID, it will fail to come up.

```
#R1
segment-routing
 traffic-eng
  policy POL3
   color 30 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
```

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FcloYkScbbFapr3n8HhKs%2Fimage.png?alt=media&#x26;token=1f267a77-b784-44bf-92e1-c9b8ba374886" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FCOPlpcnVrXmKHgCklQGX%2Fimage.png?alt=media&#x26;token=62db4572-e0c4-4d0a-a0de-93de65f7607b" alt=""><figcaption></figcaption></figure></div>

Interestingly, this does not affect POL2. Since that policy is explicitly requesting a BSID, it is allowed to fallback to a dynamic label, even with the command **binding-sid dynamic disable** enforced.

Note that a PCE can honor a headend’s SRLB and program BSIDs that are within the SRLB and do not conflict. First, the PCE can learn the SRLB through the IGP:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F7rUqoi2abPgwSj6MrJrx%2Fimage.png?alt=media&#x26;token=7c8d26da-d9ed-438d-b171-bb575ee13f16" alt=""><figcaption></figcaption></figure></div>

Second, the PCE can learn of any currently in-use static BSIDs through PCEP reports.

Also note that explicit BSIDs cannot be used on ODN templates, as multiple SR-TE policies can be spawned from these templates. Each SR-TE policy must have a unique BSID, making it impossible to manually allocate explicit BSIDs to ODN-generated policies.
