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

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

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

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

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

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.

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

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:

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.

Last updated