SR-TE Pt. 2 (Creating an SR-TE Policy)
If you are familiar with RSVP-TE, you will find that there are some similarities to SR-TE. Both technologies are used to steer traffic along a path that may differ from the IGP best path. This process is traffic-engineering. However, there are also quite a few differences. RSVP-TE uses a tunnel interface to create the LSP. The path is signaled hop-by-hop and periodically refreshed. Path-options are specified under this tunnel interface, and in order to route traffic through the LSP you must statically route or autoroute through the tunnel.
In contrast, SR-TE does not use a tunnel. SR-TE instead uses a policy to define the constraints or explicit path for the LSP. Traffic is not steered along an SR-TE policy using autoroute, but instead is steered using On-Demand Policy (ODN) and Automated Steering (AS). More on this later, but just realize that SR-TE is quite different from RSVP-TE.
An SR-TE policy is defined by three items:
Headend. This is the router where the policy is implemented. The policy will be defined on the headend in our lab, but the policy could also be defined off-box and signaled to the headend via PCEP or NETCONF for example.
Endpoint. This is the destination of the policy (typically the egress PE of an LSP).
Color. This is an arbitrary 32-bit value that is used to differentiate between multiple SR policies that share the same headend and endpoint node.
Make sure not to confuse the color of a policy with link-affinity “color.” Unfortunately the term “color” is used in both of these instances and refers to two separate things. In both cases however, the color is actually a numerical value.
An SR-TE policy uses candidate paths similar to path-options in RSVP-TE. A candidate path can be explicit or dynamic. A dynamic path is similar to a dynamic path in RSVP-TE. You may want to minimize a metric such as TE metric, or have a set of constraints such as avoiding nodes, avoiding TE affinity values, etc. The difference in RSVP-TE is that it finds a single path, even if multiple equal-cost routes exist. SR-TE can use all available ECMP paths for a policy.
An explict path uses either MPLS labels or SID descriptors (node prefixes or link addresses) to define the path. If you use only MPLS labels for the explicit path, the headend only verifies that the first label is valid. (You usually don’t want to use MPLS labels to refer to dynamically allocated adjacency SIDs, because if that router reloads, the MPLS label could change and your explicit path would no longer function correctly). If you use SID descriptors in the explicit path, the headend must verify each entry and resolve it to a label.
Just like RSVP-TE, a policy can have multiple candidate paths. This allows the router to fallback to another less-prefered path if the most prefered path becomes invalid due to a change in the topology. The default candidate path preference value is 100, and the higher the preference, the more preferred the path. The active candidate path is the highest preference path that is a valid path.
Lab
We will use the following topology. All routers are XRv9k due to a limitation in SR-TE configuration commands in XRv. If you cannot run this many XRv9k nodes, then at minimum you must use R1 as an XRv9k and you can run XRv everywhere else, but you won’t be able to use link coloring for dynamic paths.
Here are the startup configs:
We will configure three policies on R1. The “green” path (top), “red” path (bottom), and “blue” path (middle).
Green policy
Let’s configure the first policy for the green path on R1.
This policy uses an explicit path. First the traffic is steered towards R5 with label 16005. Next the heanded router will resolve 10.5.6.5 to an adjacency SID. You can use either IP address on the link, 10.5.6.5 or 10.5.6.6 and it will resolve to the same adjacency SID label.
We check the policy and see that it cannot resolve 10.5.6.5. What is the problem?
The issue is that R1 has an empty SR-TE database.
The TE database is often populated by BGP-LS on a PCE. However we are just calculating policies locally on the router. The router needs to populate its SR-TE database with the IGP LSDB. We accomplish this by using the command distribute link-state.
The SR-TE database is now populated with information from the IGP. The database contains TE and SR information that is present in LSAs. It is essentially just distributing the LSDB into the SR-TE DB. You can distribute multiple, separate, IGP domains’ LSDBs into the SR-TE database, allowing for multi-domain traffic engineering.
The policy is now up and operational:
Notice that there is a binding SID with label 24005. Because we did not manually specify a binding SID on the policy, the policy automatically generated a dynamic label for the binding SID. If R1 receives traffic with this label, it will pop the label and steer the traffic along this policy.
Also notice that the policy has an auto-generated name of srte_c_<color value>_ep_<endpoint>. The color value and endpoint uniquely identify a policy on a headend router, so these are the only two values needed to create a unique policy name.
Blue and Red policy
We could define two more explicit paths for the blue and red policies, but let’s experiment with link-affinity to dynamically determine these paths. We will color each link in the topology: red, blue, both, or neither.
On R1 we create two policies with dynamic paths, in which every link in the path must include the link-affinity of RED or BLUE.
All three policies are currently up:
Explore the paths and SID list that R1 created for the two dynamic policies:
Last updated