Summary
This chapter describes the configuration of pure Egress Peer Engineering (EPE) policies that do not impact traffic steering within the IGP domain, but only choose egress peers. EPE-only policies can be useful when there is a requirement for EPE but the network is not running Segment Routing. Or it can run SR but without Traffic Engineering and the operator does not want to export the IGP topology to the controller.
Requirements
The standard, and preferred way to advertise EPE topology to Traffic Dictator is to configure routers to generate BGP Peer SID, and advertise those using BGP-LS.
If a router does not support BGP Peer SID, the alternative method is to have the router generate a BGP-LU route per egress peer and advertise those to Traffic Dictator.
Important: when using BGP-LU to advertise EPE routes to TD, you must setup a separate BGP session between TD and each egress ASBR that generates LU routes. Also, LU routes must be filtered out in route-maps on all other routers, so that TD receives only one EPE route for a given prefix, and that route is from the ASBR that generated it.
BGP Peer SID and BGP-LS are not impacted by this limitation. You can generate Peer SID on multiple egress ASBR, and have one router (e.g. a route-reflector) advertise all of those to TD.
When using EPE with affinity or bandwidth constraints, or using Null endpoints, make sure you have configured relevant ASBR nodes and egress peers in the relevant config section. Furthermore, specifically for EPE-only policies, you must configure IPv4 or IPv6 address for each egress ASBR as described here: https://vegvisir.ie/asbr-nodes-and-egress-peers-configuration/#ASBR_node_IP_for_EPE-only_policies
EPE-only policies always use BGP-LU as install method. This is because an SR-TE policy cannot recursively resolve over an LDP-only network, and while SR over RSVP is possible, it is complicated and not supported by every vendor.
Therefore, you must configure service-loopbacks for all egress ASBR, do not advertise it into IGP but advertise it via BGP-LU to the headend with lower LOCAL_PREF. Then change next-hop in BGP routes that you want to steer into policy to that service-loopback.
See the chapters about BGP-LU policies and EPE policies with BGP-LU.
EPE-only policy example
Consider the following topology:
TD has BGP-LU sessions with all ASBR which advertise their EPE routes using BGP-LU. It also has a BGP-LU session with R1 so that it can push policies to R1. There is no BGP-LS configured anywhere and IGP topology is not exported to TD.
Now, the requirement is to steer traffic from R1 to ISP4. TD does not control how traffic gets from R1 to R11 so it just folows the shortest path.
Policy config:
traffic-eng policies
!
policy R1_ISP4_EPE_ONLY
endpoint 10.100.19.104 service-loopback 103.11.11.11
epe-only
priority 7 7
install direct labeled-unicast 192.168.0.101
!
candidate-path preference 100
bandwidth 100 mbps
Note there is no headend configured. Headend is not required for EPE policies, because TD does not check IGP topology.
Egress ASBR config for R11:
traffic-eng nodes
!
node 11.11.11.11
ipv4 address 11.11.11.11
!
neighbor 10.100.19.104
affinity YELLOW
bandwidth 10 gbps
!
neighbor 10.100.20.105
affinity BLUE
bandwidth 10 gbps
Traffic Dictator checks bandwidth constraint, and uses configured ipv4 address 11.11.11.11 as LU nexthop which will resolve recursively over the existing MPLS control plane.
Verify an EPE-only policy
TD1#show traffic-eng policy R1_ISP4_EPE_ONLY detail
Detailed traffic-eng policy information:
Traffic engineering policy "R1_ISP4_EPE_ONLY"
Valid config, Active
This is an EPE-only policy
Endpoint 10.100.19.104, service-loopback 103.11.11.11
Endpoint type: Egress peer, Topology-id: None, Protocol: epe_only, Router-id: 11.11.11.11
Setup priority: 7, Hold priority: 7
Reserved bandwidth bps: 100000000
Install direct, protocol labeled-unicast, peer 192.168.0.101
Policy index: 2, SR-TE distinguisher: 16777218
Candidate paths:
Candidate-path preference 100
Path config valid
Metric: igp
Path-option: dynamic
This path is currently active
Calculation results:
Topologies: None
Segment lists:
[100000]
BGP-LU next-hop: 11.11.11.11
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
Check that an LU route has been created and advertised:
TD1#sh bgp ipv4 labeled-unicast [16777218][103.11.11.11/32]
BGP-LS routing table information
Router identifier 111.111.111.111, local AS number 65001
BGP routing table entry for [16777218][103.11.11.11/32]
Label stack: [100000]
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
TD1#show bgp neighbors 192.168.0.101 ipv4 labeled-unicast advertised-routes | grep 103 *>+ [16777218][103.11.11.11/32] - 0 - 0 i
Verify on the headend router
In this case, the headend is Arista EOS.
R1#show bgp ipv4 labeled-unicast 103.11.11.11/32
BGP routing table information for VRF default
Router identifier 1.1.1.1, local AS number 65002
BGP routing table entry for 103.11.11.11/32
Paths: 2 available
65001
11.11.11.11 labels [ 100000 ] from 192.168.0.1 (111.111.111.111)
Origin IGP, metric 0, localpref 500, IGP metric 410, weight 0, tag 0
Received 02:37:01 ago, valid, external, best
Community: no-advertise
Local MPLS label: 100004
Rx SAFI: MplsLabel
Tunnel RIB eligible
Local
11.11.11.11 labels [ 3 ] from 11.11.11.11 (11.11.11.11)
Origin IGP, metric 0, localpref 100, IGP metric 410, weight 0, tag 0
Received 02:37:11 ago, valid, internal
Local MPLS label: 100004
Rx SAFI: MplsLabel
Tunnel RIB eligible
Note that the first route (with EPE label 100000) has LOCAL_PREF set to 500 so it’s preferred. The second route (with imp-null) is a backup route advertised from R11, which will be used if the policy goes down or the controller fails, so the traffic will follow the usual BGP rules.
BGP-LU route is resolved via IS-IS SR:
R1#show bgp labeled-unicast tunnel Index Endpoint Nexthop/Tunnel Index Interface Labels Contributing Metric/Type Metric 2 Pref Pref 2 ----------- ---------------------- -------------------------- --------------- ------------------------------ ------------------ ----------------- -------------- ---------- ------ 4 103.11.11.11/32 IS-IS SR IPv4 (8) - [ 100000 ] Yes 0 MED 0 200 0
R1#show isis segment-routing tunnel 8
Index Endpoint Next Hop/Tunnel Index Interface Labels
----------- -------------------- --------------------------- --------------- ----------
8 11.11.11.11/32 10.100.1.2 Ethernet1 [ 900011 ]
10.100.2.4 Ethernet2 [ 900011 ]
10.100.3.5 Ethernet3 [ 900011 ]
10.100.21.3 Ethernet4 [ 900011 ]
In this case, the network is running SR, but if it was running LDP or RSVP, the route would be resolved the same way over those MPLS control planes.
Null endpoint with EPE-only policies
While it is possible to configure an EPE-only policy with null endpoint, similar to what is described here: https://vegvisir.ie/epe-and-null-endpoint-policies/#Null_endpoint_and_BGP-LU, this might not be the best idea. While in regular SR-TE or LU policies with Null endpoint, Traffic Dictator can evaluate all endpoints and pick the one with lowest IGP metric from headend, with EPE-only policies TD has no visibility of IGP topology so it will just pick the lowest egress peer IP.
Bandwidth reservations
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. “show topology epe” shows bandwidth reservations specifically for egress peers.
TD1#show topo epe
---
11.11.11.11 10.100.19.104
Affinities: ['YELLOW']
Shared bandwidth group: 104
Unrsv-bw priority 0: 10000000000
Unrsv-bw priority 1: 10000000000
Unrsv-bw priority 2: 10000000000
Unrsv-bw priority 3: 10000000000
Unrsv-bw priority 4: 10000000000
Unrsv-bw priority 5: 10000000000
Unrsv-bw priority 6: 10000000000
Unrsv-bw priority 7: 9800000000
Policies priority 0: []
Policies priority 1: []
Policies priority 2: []
Policies priority 3: []
Policies priority 4: []
Policies priority 5: []
Policies priority 6: []
Policies priority 7: ['R1_ISP4_ANY_COLOR_IPV4', 'R1_ISP4_EPE_ONLY']