SR-TE BSIDs
Load basic.isis.sr.vpnv4.enabled.cfg
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
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.
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:
To allow the router to fallback to a dynamic label when the explicit BSID label cannot be created, we can use the following command:
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.
If we try to create a third policy that does not specify an explicit BSID, it will fail to come up.
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
