Summary
This chapter describes the configuration of SR-TE policies using BGP Labeled Unicast. This is less optimal than BGP SR-TE but might be necessary with routers that don’t support BGP SR-TE.
Why Labeled Unicast
One of the goals of Traffic Dictator is to lower the entry barrier for Traffic Engineering, so that network operators are not locked in with expensive routers from a handful of big vendors, but have a wider choice of various routers available to them, including whitebox routers and open source routing implementations.
Some of these devices don’t support BGP SR-TE or PCEP, but almost any router that supports basic MPLS, also supports BGP Labeled Unicast. This allows network operator to use BGP-LU to install Traffic Engineering policies. BGP-LU doesn’t have a concept of “color” like SR-TE, but Traffic Dictator offers an option of “service-loopback” to emulate the SR-TE color functionality with BGP-LU.
In this topology, R8 has a “service-loopback” 172.16.1.1. It is not advertised into IGP but advertised into BGP-LU with nexthop of 8.8.8.8 which is the main R8 loopback reachable via IGP. R8 advertises 172.16.1.1 to R1 with a lower local preference, as a backup route to preserve best effort path if the controller fails. When advertising the L3 VPN route for 10.0.0.0/24, R8 sets nexthop to 172.16.1.1.
Traffic Dictator sends a BGP-LU route to R1, with prefix 172.16.1.1, and nexthop of R3 interface address. This way, the same behaviour as automated steering can be achieved even if routers do not support BGP SR-TE.
Simple BGP-LU policy with dynamic path
Consider the following topology:
The network is running IS-IS L2. In order to create an IPv4 policy to steer traffic from R1 to R11 only using blue links, we can configure the following policy:
policy R1_R11_BLUE_ONLY_IPV4
headend 1.1.1.1 topology-id 101
endpoint 11.11.11.11 service-loopback 100.11.11.11
priority 7 7
install direct labeled-unicast 192.168.0.101
!
candidate-path preference 100
metric igp
affinity-set BLUE_ONLY
bandwidth 100 mbps
Affinity-set BLUE_ONLY and relevant affinity mapping is configured to match the links with affinity 0x1 as advertised by IGP.
traffic-eng affinities
affinity-map
name BLUE bit-position 0
!
affinity-set BLUE_ONLY
constraint include-all
name BLUE
Verifying BGP-LU policy
TD1#show traffic-eng policy R1_R11_BLUE_ONLY_IPV4 detail
Detailed traffic-eng policy information:
Traffic engineering policy "R1_R11_BLUE_ONLY_IPV4"
Valid config, Active
Headend 1.1.1.1, topology-id 101, Maximum SID depth: 6
Endpoint 11.11.11.11, service-loopback 100.11.11.11
Endpoint type: Node, Topology-id: 101, Protocol: isis, Router-id: 0011.0011.0011.00
Setup priority: 7, Hold priority: 7
Reserved bandwidth bps: 100000000
Install direct, protocol labeled-unicast, peer 192.168.0.101
Policy index: 6, SR-TE distinguisher: 16777222
Candidate paths:
Candidate-path preference 100
Path config valid
Metric: igp
Path-option: dynamic
Affinity-set: BLUE_ONLY
Constraint: include-all
List: ['BLUE']
Value: 0x1
This path is currently active
Calculation results:
Aggregate metric: 400
Topologies: ['101']
Segment lists:
[900010, 100003]
BGP-LU next-hop: 10.100.3.5
Policy statistics:
Last config update: 2024-09-06 10:40:56,270
Last recalculation: 2024-09-06 10:41:16.650
Policy calculation took 0 miliseconds
There is a lot of information. Key things are:
- Endpoint 11.11.11.11 has been resolved to IS-IS system-ID 0011.0011.0011.00 in topology-id 101 (same as headend)
- Constraint has been resolved to 0x1
- Candidate-path preference 100 is active
- Calculated segment list is [900010, 100003] which is R10 node SID and R10 adj SID towards R11 using blue link. Segment list is within the MSD limit of R1 so it’s allowed.
- 100 mbps of bandwidth has been reserved (can be verified with “show topology” outputs)
Note how the segment list doesn’t include R5 node SID, like it does in an SR-TE policy in the same topology. This is because R5 is directly connected to R1, so there is no need to push R5 node SID. Instead, Traffic Dictator sets BGP-LU next-hop to 10.100.3.5 which is the IP address of R5 interface connected to R1.
Advertising BGP-LU policy to headend
The only option for BGP-LU is to advertise the route directly to a BGP peer, which has Labeled Unicast configured and negotiated. Verify the peer 192.168.0.101 exists and IPv4-LU is negotiated:
TD1#show bgp su BGP summary information Router identifier 111.111.111.111, local AS number 65001 Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State Received NLRI Active AF 192.168.0.101 4 65002 142 133 0 0 1:07:07 Established 95 IPv4-LU, LS
Verify that the route has been created and send to peer:
TD1#show bgp ipv4 labeled-unicast [16777222][100.11.11.11/32]
BGP-LS routing table information
Router identifier 111.111.111.111, local AS number 65001
BGP routing table entry for [16777222][100.11.11.11/32]
Label stack: [900010, 100003]
Paths: 1 available, best #1
Last modified: September 06, 2024 10:41:16
Local, inserted
- from - (0.0.0.0)
Origin igp, metric 0, localpref -, weight 0, valid, -, best
NLRI for the BGP-LU policies is the configured service-loopback.
TD1#show bgp neighbors 192.168.0.101 ipv4 labeled-unicast advertised-routes | grep 100.11 *>+ [16777222][100.11.11.11/32] - 0 - 0 i
SR-TE distinguisher for BGP-LU policies
All Traffic Engineering policies have a distinguisher which for SR-TE is used for redundancy in a multi-controller setup. While this is not relevant to BGP-LU, Traffic Dictator still attaches distinguisher to BGP-LU policies, in order to separate NLRI from different policies that happen to use the same service loopback. There is no distinguisher field in BGP-LU messages, so the router will receive just the prefix.
Anycast SID, ECMP and multiple Segment Lists in BGP-LU policies
While BGP-LU policies can use anycast SID and ECMP after the first hop, the first hop will always be only one link. BGP-LU policies cannot use multiple Segment Lists.
Explicit path
In order to steer traffic via specific links or nodes, or to exclude links or nodes, you can use explicit path.
traffic-eng policies
!
policy R1_R9_EP_STRICT_IPV4
headend 1.1.1.1 topology-id 101
endpoint 9.9.9.9 service-loopback 100.9.9.9
priority 4 4
install direct labeled-unicast 192.168.0.101
!
candidate-path preference 100
explicit-path R2_R6_R9_STRICT
bandwidth 100 mbps
Explicit path config:
traffic-eng explicit-paths
!
explicit-path R2_R6_R9_STRICT
index 10 strict 10.100.1.2
index 20 strict 10.100.4.6
index 30 strict 10.100.10.9
This policy does not use affinities, but forces traffic via R2-R6-R9 as on the diagram below:
TD1#show traffic-eng policy R1_R9_EP_STRICT_IPV4 detail
Detailed traffic-eng policy information:
Traffic engineering policy "R1_R9_EP_STRICT_IPV4"
Valid config, Active
Headend 1.1.1.1, topology-id 101, Maximum SID depth: 6
Endpoint 9.9.9.9, color 8
Endpoint type: Node, Topology-id: 101, Protocol: isis, Router-id: 0009.0009.0009.00
Setup priority: 4, Hold priority: 4
Reserved bandwidth bps: 100000000
Install direct, protocol srte, peer 192.168.0.101
Policy index: 10, SR-TE distinguisher: 16777226
Binding-SID: 966008
Candidate paths:
Candidate-path preference 100
Path config valid
Metric: igp
Path-option: explicit
Explicit path name: R2_R6_R9_STRICT
This path is currently active
Calculation results:
Aggregate metric: 300
Topologies: ['101']
Segment lists:
[900002, 900009]
Policy statistics:
Last config update: 2024-09-05 17:28:56,025
Last recalculation: 2024-09-05 17:34:59.567
Policy calculation took 0 miliseconds
Note that explicit path is not the same as configuring explicit segment list as it’s possible on some routers. Traffic Dictator will still check the IGP topology and use only required segments. In this example, R6 SID is not used because it’s not required, as shortest path from R2 to R9 satisfies policy constraints.
It is possible to use various constraints in explicit path. For example:
traffic-eng policies
!
policy R1_R11_EXCLUDE_SOME_IPV4
headend 1.1.1.1 topology-id 101
endpoint 11.11.11.11 service-loopback 101.11.11.11
priority 4 4
install direct labeled-unicast 192.168.0.101
!
candidate-path preference 100
explicit-path EXCLUDE_SOME
bandwidth 100 mbps
traffic-eng explicit-paths
!
explicit-path EXCLUDE_SOME
index 10 exclude 4.4.4.4
index 20 loose 7.7.7.7
index 30 exclude 10.100.13.11
index 40 exclude 10.100.14.11
This instructs the policy to do the following:
1. Get to R7 (7.7.7.7) excluding R4 (4.4.4.4)
2. Get to R11 (11.11.11.111) excluding links R9-R11 (10.100.13.11) and one of the links R10-11 (10.100.14.11).
See the topology diagram:
Verify:
TD1#show traffic-eng policy R1_R11_EXCLUDE_SOME_IPV4 detail
Detailed traffic-eng policy information:
Traffic engineering policy "R1_R11_EXCLUDE_SOME_IPV4"
Valid config, Active
Headend 1.1.1.1, topology-id 101, Maximum SID depth: 6
Endpoint 11.11.11.11, color 10
Endpoint type: Node, Topology-id: 101, Protocol: isis, Router-id: 0011.0011.0011.00
Setup priority: 4, Hold priority: 4
Reserved bandwidth bps: 100000000
Install direct, protocol srte, peer 192.168.0.101
Policy index: 8, SR-TE distinguisher: 16777224
Binding-SID: 966006
Candidate paths:
Candidate-path preference 100
Path config valid
Metric: igp
Path-option: explicit
Explicit path name: EXCLUDE_SOME
This path is currently active
Calculation results:
Aggregate metric: 500
Topologies: ['101']
Segment lists:
[900005, 900007, 900010, 100003]
Policy statistics:
Last config update: 2024-09-05 17:28:56,025
Last recalculation: 2024-09-05 17:34:59.567
Policy calculation took 0 miliseconds
The relevant Segment list is: R7 node SID, R10 node SID, R10-R11 adj SID for blue link.
Anycast IP in explicit path
Similarly to SR-TE policies, LU policies can use anycast IP in explicit path. However, remember the limitation mentioned above: an LU policy will always have only one first hop.
Bandwidth reservations
Bandiwdth reservations for LU policies work exactly the same way as for SR-TE policies.
When a policy has bandwidth constraint, Traffic Dictator will perform bandwidth reservations. It will use configured setup priority to check bandwidth constraint, and hold priority to check if the policy can be kicked out to reserve bandwidth a higher-priority policy. Priority 0 is the highest and 7 is the lowest. Also setup priority cannot be higher than hold priority for the same policy.
You can check bandwidth reservations using “show topology” command. There is a very long output, relevant excerpt:
TD1#show topology
---
ISIS links
0006.0006.0006.00 [E][L2][I101][N[c65002][b0][s0006.0006.0006.00]][R[c65002][b0][s0009.0009.0009.00]][L[i10.100.10.6][n10.100.10.9]]
IGP metric: 100
TE metric: 500
Affinity: 0x6
Max-bw: 10000000000
Unrsv-bw priority 0: 10000000000
Unrsv-bw priority 1: 10000000000
Unrsv-bw priority 2: 10000000000
Unrsv-bw priority 3: 10000000000
Unrsv-bw priority 4: 9800000000
Unrsv-bw priority 5: 9800000000
Unrsv-bw priority 6: 9800000000
Unrsv-bw priority 7: 9800000000
Policies priority 0: []
Policies priority 1: []
Policies priority 2: []
Policies priority 3: []
Policies priority 4: ['R1_R11_EP_LOOSE_IPV4', 'R1_R9_EP_STRICT_IPV4']
Policies priority 5: []
Policies priority 6: []
Policies priority 7: []