SR-TE Basic BGP EPE
Last updated
Last updated
Load sr.bgp.epe.init.cfg. You may need to load bootflash:blank.cfg and commit replace first.
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.
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:
Peer Node SID
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)
Peer Adj SID
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.
Peer Set SIDs
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.
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.
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.
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.
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.
