BGP Traffic Engineering - Active\Passive

Fri May 21 15:13:18 UTC 2021

Nanog,

At my organization we historically would get T1 ISPs at our POPs and take full table + default. BGP would simply "do it's thing" and for the most part everything worked out. There are instances where we have had heavily lopsided traffic even though AS path length is the same.

To make things easier to track we will do something such as:

* BGP Peer ISP-A - Lower local pref, advertise all prefixes.
* BGP Peer ISP-B - Normal local pref, prepend

In the routing table it looks like:

* ISP-A 1111 174
* ISP-B 1111 1111 1111 1111 1299

Ingress everything takes 174 for the most part (due to prepending), egress the same (due to local pref).

Let's say there's a special AS, 9999 which despite AS path lengths being the same is way better latency in ISP-B.

Correct me if I'm wrong here but I *could* take full table + AS 9999 on B meaning the traffic will prefer 'B' due it it having a more specific route since I'm only taking default from A (despite local pref). That will correct my egress situation but how can I fix ingress?

Is it possible to prepend to JUST one upstream ASN so normal traffic takes ISP A back except 9999 traffic? to make:

* ISP-A 1111 174 4444
* ISP-B 1111 1111 1111 1111 1299 4444
* ISP-A 1111 1111 1111 1111 1111 1111 174 9999
* ISP-B 1111 1111 1111 1111 1299 9999

If I'm unable to do that will most provider prepend on your behalf so that ISP-A would add the prepends for 9999 only?

Now to mix this up let's say another ASN, 7777 was in-between 1299 and 9999 but latency wise the route was still faster.

- nanoguser100

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210521/d8c5d2de/attachment.html>