# SR-TE Basic BGP EPE
Load **sr.bgp.epe.init.cfg**. You may need to load **bootflash:blank.cfg** and commit replace first.
```
configure
load bootflash:sr.bgp.epe.init.cfg
commit replace
y
```
R5 and R6 are now edge routers in the core AS100. R7 and R8 belong to AS7 and AS8.
Currently AS100 prefers using R5 to get to 7.7.7.1/32 due to higher LP that R5 is setting. R1 wants to direct traffic to 7.7.7.1/32 via R6. As an attempt, R1 has set weight from R6 as higher. However, R6 still routes traffic to R5 instead of directly to R7. (The path goes R1-R6-R5-R7). This is because R6 makes its own bestpath decision, which R1 cannot influence or traffic engineer directly.
Using BGP EPE on R6, program an explicit SR-TE policy on R1 that takes the desired path.
## Answer
```
#R6
router bgp 100
neighbor 10.6.7.7
egress-engineering
#R1
extcommunity-set opaque COLOR10
10
end-set
!
route-policy IBGP_IN
if destination in (7.7.7.1/32) and next-hop in (6.6.6.1/32) then
set weight 1000
set extcommunity color COLOR10
endif
pass
end-policy
!
segment-routing
traffic-eng
segment-list EPE
index 1 mpls label 16006
index 2 mpls label 24008
!
policy POL1
color 10 end-point ipv4 6.6.6.1
candidate-paths
preference 100
explicit segment-list EPE
```
## Explanation
Segment Routing BGP Egress Peer Engineering (SR BGP EPE) allows you to traffic engineer a path which includes the egress peer forwarding decision on the egress PE.
Under normal operation, BGP traffic engineering in which you choose the remote egress peer is difficult to accomplish. It is fairly simple to choose a single egress PE by using a BGP PA such as local pref. However, if that egress PE has multiple peers, that PE is in full control of which eBGP peer it uses. You cannot use normal BGP traffic engineering to influence that PE’s bestpath decision.
BGP does not take into account metrics such as latency for performance optimization. Using SR-TE with EPE is a technique that allows the source node to specify the complete end-to-end path, including the egress eBGP peer that is used. Without this, at most you can specify the end-to-end LSP to the egress PE. EPE allows you to specify the path one hop further.
EPE works using a peering SID, which is similar to an IGP Adj SID. There are three types of BGP EPE peering SIDs:
1. Peer Node SID
1. The instruction for a peer node SID is to pop the label and forward to the BGP peer on the ECMP aware path (in case the peering is over loopbacks and multiple links exist to the peer)
2. Peer Adj SID
1. When an eBGP session is multihop, a peer Adj SID is automatically allocated per link used to reach the eBGP neighbor. This happens even if there is only one link. The instruction is to pop the label and forward to the BGP peer on the specific link.
3. Peer Set SIDs
1. You can identify a set of peers using a peer set SID. The instruction is to forward to any BGP peer in that given set.
2. This is not supported on IOS-XR
Note that the remote eBGP peer does not need to be concerned with SR or labeling. It does not need to care about BGP EPE. The local edge PE simply allocates peer SID(s) for the eBGP neighbor, and signals this internally within its domain, usually using BGP-LS (which we will see in a future article).
BGP peer SIDs are local segments which are dynamically allocated.
The configuration for BGP EPE is quite simple. Simply activate **egress-engineering** under the BGP neighbor statement. The router will detect whether multihop is used. If so, it will allocate a peer Adj SID per link, in addition to the one peer node SID for that neighbor.
```
#R6
router bgp 100
neighbor 10.6.7.7
egress-engineering
```
The command **show bgp egress-engineering** shows BGP EPE information. There is not much we really need to verify here. We can see the MPLS label allocated for this peer node SID. (This is not a multihop session, so no peer Adj SIDs are allocated).
This information would typically be distributed via BGP-LS to a PCE controller. The controller would then potentially have a way to monitor latency on the end to end path. It would signal which path to use to the headends by specifying the full SID list, with the EPE label as the last label in the stack. However, for this simple lab, we can prove that the path works by using an explicit path directly on the headend.
```
#R1
segment-routing
traffic-eng
segment-list EPE
index 1 mpls label 16006
index 2 mpls label 24008
!
policy POL1
color 10 end-point ipv4 6.6.6.1
candidate-paths
preference 100
explicit segment-list EPE
```
Additionally, we set the color on the received route. To do this, we simply re-create the existing route-policy which is setting weight and add the **set extcommunity color** statement.
```
#R1
extcommunity-set opaque COLOR10
10
end-set
!
route-policy IBGP_IN
if destination in (7.7.7.1/32) and next-hop in (6.6.6.1/32) then
set weight 1000
set extcommunity color COLOR10
endif
pass
end-policy
```
If we trace to the prefix, we can see we are taking the expected path now:
In summary, one use of BGP EPE is to traffic engineer the egress PE’s nexthop decision, specifying which exact BGP peer to use and even which link to that peer. The egress PE does not make a forwarding decision, bypassing its own local BGP bestpath process. This allows a PCE/controller to take into account metrics such as end-to-end latency to produce paths that are optimized for that performance metric.
Another use for BGP EPE is to replace BGP-LU in a unified MPLS or inter-domain topology. Not only can BGP EPE replace the need to do the complex next-hop changes and advertisement of /32s with unified MPLS, but it also allows us to use the EPE labels for domain-wide traffic engineering. We will see this in the next lab.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/sr/sr-te-basic-bgp-epe.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.