Basic SR-TE with AS and ODN
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 any nexthop using TE as the metric. Use color 10 for this policy. Configure the R1-R4 link to have a TE metric of 1.
On R7 and R8, signal routes learned from the locally-connected CE so that R1 steers traffic towards CE107 and CE108 via this SR-TE policy.
Answer
Explanation
ODN (On-Demand Steering) solves the scalability problem that is present with regular AS (automated steering), in which every possible endpoint needs to be specified on each headend. With ODN, we instead have a single policy that only identifies a color. Any BGP route with the matching color will automatically generate an SR-TE policy with the BGP nexthop as the policy endpoint.
Where AS automates the steering of traffic into a service route, ODN automates the instantiation of the SR-TE policy itself.
An ODN policy cannot use multiple candidate paths. This is because the ODN policy itself is essentially a candidate path. If you had the ability to configure multiple candidate paths, then the policy could unpredictably mean different things on different routers. You don’t lose any “fallback” features due to this, because if the policy cannot be calculated, the router will just fallback to IGP forwarding.
The ODN policy is configured on R1 as follows:
R1 must also distribute the LSDB into the SR-TED, and set the Gi0/0/0/4 link to have a TE metric of 1.
Notice that R1 has not brought up any SR-TE policies. This is because no BGP routes match the color value of 10 yet.
Next, we configure R7 and R8 to set the BGP color to 10 on routes received from the CE. This is no different than the previous lab. R7 and R8 must advertise a TE RID into the IGP so that they can be used as endpoints in the SR-TED on R1. (R1 does not need to advertise a TE RID in this lab because it is only a headend. In the real world you would do this on all routers).
R1 now sees two VPNv4 routes with color 10. We’ll look at the route from R8. Interestingly, we see the phrase “registered” now. Before without ODN, we saw “not registered.” So “registered” appears to be refering to registering the ODN policy and instantiating it.
We can see that R1 has created two SR-TE policies automatically:
Just as before, the BSID is used internally to steer traffic along the SR-TE policy. This is the same as we saw in the last lab. The only difference now is that the SR-TE policies were created on-demand instead of explicitly defined for each individual endpoint. This makes SR-TE with ODN extremely scalable.
Traffic from CE101 to CE107 and CE108 takes the path via R4. Traffic to CE102 still takes the IGP path via R3:
What happens if there is both an explicit SR-TE policy and ODN policy?
I’ve created the following policies on R1:
R1 automatically brings up the policy with the explicit end-point. But the ODN policy is not up yet. No matching BGP routes are injected yet.
I now set the BGP color on the routes received at R7. The router appears to use the BSID that was created for the explicit (non-ODN) policy. However, we see the “registered” flag which is only see when the color matches an ODN policy.
If we look at the details of the SR-TE policy, we see that the ODN policy is actually just another candidate-path on the explicit policy (screenshot below). In fact it is two candidate-paths, one with preference 200 for local computation, and one with preference 100 for PCE computation. If the router fails to compute the path, it will try to compute it using a PCE. Note that you can disable the local computation candidate path with preference 200 using the following command. When you do this, you will see the preference 200 path as “shutdown” in the show output.
The explicit policy’s candidate path preference is 10. The BGP ODN preference is higher (200) and is used instead. When a policy already exists for the color/endpoint pair, any new policies that are learned, such as via ODN or a PCE, are added as candidate paths to the existing policy.
If we were to make the explicit policy have a higher preference (such as 300), we can prefer the explicit policy over the ODN policy.
It does not appear that you can control the ODN preference numbers, so playing with the explicit policy’s candidate-preferences can be used to influence the SR-TE policy path choice.
Last updated
