SR-TE Pt. 4 (Automated Steering)
Last updated
Last updated
The main method for steering traffic into an SR-TE policy is by using Automated Steering. With Automated Steering, the color of a BGP route determines the SR-TE policy that is used for traffic matching the given route. The color is an extcommunity attribute, which is extcommunity type 11. Remember that the color is just a numerical value.
Upon receiving a BGP route with a color value, the router checks whether it has a matching SR-TE policy. The color of the policy must match the color value on the route, and the policy’s endpoint must match the BGP route’s nexthop. If there is a match, the router installs a route towards that BGP destination via the SR-TE policy, not via the nexthop.
The idea behind this is that a modern service provider network will use BGP for all services. It will use EVPN for L2VPN and of course vpnv4 for L3VPN. Therefore, any traffic that you’d like to steer into an SR-TE policy should have a BGP route in which you can set the color value.
With Automated Steering, the ingress PE does not need any extra configuration besides the SR-TE policies themselves. The egress PE is the router which sets the color extcommunity value on a route. The route may be received from a CE or be an L2VPN route. The PE advertises this to the RR which reflects it to all other PEs. You can think of this as the egress PE saying “I want this traffic to reach me via this SR-TE policy.”
The beauty in this method is that a full mesh of TE tunnels is no longer needed, as with RSVP-TE. A single router can signal to all other PEs in the network to use a particular policy. In fact, the customer themselves could set SLA preference on their routes by setting the color value on routes advertised to the PE. Similar to the SP giving the customer a set of communities for BGP TE purposes (set localpref, etc), the SP could give the customer a set of color values (10=low delay, etc) which the customer could use. The more likely scenario would actually be to give the customer a list of communities and the PE would match these communities and set color accordingly.
Let’s explore this in the lab to fully understand how this works.
In order to demonstrate Automated Steering, we need BGP service routes. Using the topology from the previous article, we will add a customer VRF called CUSTOMER_A and two CEs, CE1 and CE2. R2 will be the RR.
Here is the additional config:
The route received from R6 is currently not valid on R1, because R1 does not have a route to 6.6.6.6 in its global table. Same for the route received from R1 on R6.
To work around this, R1 and R6 will each advertise their own Lo0 with the label-index value set to their prefix SID index. This is essentially Unified MPLS but using SR instead of dynamically allocated label values. Remember that the SRGB must be set globally in order to allow BGP to reserve a label in the SRGB based on the received index value of the route.
With inter-domain SR, we technically do not need labeled reachability between the PEs in other domains if we have a PCE. We could get away with a null0 route for each /32 on R1 and R6 in order to make the BGP routes valid. Each PE would ask the PCE to calculate the policy and reachability would be achieved using SR-TE. Better than using a null0 route would be to use the BGP knob nexthop validation color-extcomm sr-policy (but this does not appear to be available in XRv9k). However, doing Unified MPLS with SR is good practice.
The route is now accepted at each PE. The CEs have reachability to each other.
Let’s create an inbound policy on R6 that sets routes from CE2 to have the color red (which is a value of 20). The LSP from R1 to R6 should then take the path R1-R2-R3-R4-R6 for routes received from R6.
On R1, no configuration is needed in order for traffic matching the 10.1.2.0/24 route to be steered into the RED policy. We can see that the route has the “color 20” extcommunity value. R1 finds that BSID 24005 corresponds to this policy.
Pcap of the route reflected from R6 to R1 with the color value set. (0x14 in hex is 20).
If we examine CEF on R1 we can see the details of how the BGP route was translated to the CEF entry:
Here is the process that took place on R1:
R1 receives route 10.1.2.0/24 from R6 with color = 20
R1 finds that it has a policy for color = 20, endpoint = R6 with BSID 24005
R1 installs this into CEF with a request to do recursion via the label 24005
CEF finds that the policy srte_c_20_ep_6.6.6.6 corresponds to this BSID. There is no nexthop, so the top label is ImplNull. The nexthop is really the policy, which pushes {16002, 16003, 16006}. The service label learned from R6 for 10.1.2.0/24 is 24002, which is the bottom label.
Remember that all of this took place on R1 with no intervention from the operator. As long as R1 has a matching SR-TE policy (color matches the BGP extcommunity value, and endpoint matches the BGP nexthop), this happens automatically. This is thanks to interworking between BGP, SR-TE, and the FIB. Now you can appreciate the meaning of the term “Automated Steering.”
We can see that traffic from CE1 destined for 10.1.2.0/24 is steered along the RED path:
The power of Automated Steering is scale. Imagine that this customer had many different locations, with the VRF defined on 30 different PEs. As long as the associated policy with the color and endpoint exists on each PE, all PEs will steer traffic using the corresponding SR-TE policy upon receiving the route with color=20. This eliminates the need for a full-mesh of TE tunnels as you would need in RSVP-TE.
But does this mean that each of the 30 PEs would need 29 different policies, one for each endpoint? Right now, the answer would be yes. But with On-Demand Nexthop (ODN), we can create a template that uses a “wildcard” endpoint. As long as the PE receiving the BGP route has an ODN SR-TE policy with a matching color value, the router will dynamically calculate a path using the BGP nexthop as the endpoint. We’ll explore ODN in the next article.
