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.