nanog mailing list archives

RE: BGP Traffic Engineering - Active\Passive


From: "tim () pelican org" <tim () pelican org>
Date: Fri, 21 May 2021 16:37:21 +0100 (BST)

On Friday, 21 May, 2021 16:13, "nanoguser100 via NANOG" <nanog () nanog org> said:

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?

For the egress situation, you could also start looking at accepting full table from A and B, but apply a route-map to 
routes received from B to alter the local-pref based on the AS-PATH.

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?

This is a conversation you need to have with A and B, or look at their transit documentation, where available.  Several 
of them have communities you can tag your routes with to vary how it is announced, which may include announce/don't, 
prepend N times, set local-pref within their own network, and on a region / country / exchange / peer basis.  If you 
really need this functionality, that may drive your choices for A and B.

Obviously you'd again need route maps to apply to correct communities to your own routes only towards the correct 
transit provider.

Take a look at, for example https://www.gin.ntt.net/support-center/policies-procedures/routing/ - no particular 
recommendation, just a well-documented example I have to hand.

Cheers,
Tim.


Current thread: