Basic SR-TE with AS
Load basic.isis.sr.vpnv4.enabled.cfg
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
Explanation
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 num.
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).
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).
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.”
But if we check the SR-TED on R1, we see an entry for R7. So you might think this should be working:
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.
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).
We now see a TE RID for R7 in the SR-TED:
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).
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:
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.
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.
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).
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:
SR-TE policy reoptimization
Remove the TE metric on Gi0/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.
Other notes
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:
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.
Last updated
