Re: BGP Traffic Engineering - Active\Passive
Hello First one needs to remember that it is always the sender that ultimately decides which path to use. You can use route-map or import policy to override local pref for each matched received prefix to steer exactly which ISP you want to use on a per prefix basis. But so can everyone else. Say you are AS1 and we are AS2. We have two common IP transit providers AS100 and AS200. You really want to use AS100 so you will prepend on AS200. However AS2 is free to ignore that prepend and set a lower local pref for your prefix towards AS200. Or the most obvious example, AS2 could simply be using AS200 as default, so nothing at all could make them use AS100 for sending. Now say AS100 and AS200 are actually connected. AS2 delivers the packet to AS200. AS200 sees that you prepended your prefix on your direct connection to AS200. The path length is much shorter if they deliver the packet to AS100 instead of delivering it directly to you due to prepending. In 99% of the cases, a transit provider will ignore path length in this situation. Everyone has a rule to deliver the packet directly to a customer if that is possible. Just one of many examples where path length is ignored in practical BGP. The only thing that generally works 100% is announcing a more specific prefix through one transit provider. That will however move everything to that provider leaving zero traffic on the other providers. Some transit providers allow you to use communities to selectively prepend towards certain destinations as described by others here. Just remember that you really do not have all that much control over the ingress direction. Not to say it does not work, but it may disappoint somewhat. Regards, Baldur
RE: BGP Traffic Engineering - Active\Passive
On Friday, 21 May, 2021 16:13, "nanoguser100 via NANOG" said: > Correct me if I'm wrong here but I *could* take full table + AS 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 traffic? to make: > > * ISP-A 174 > * ISP-B 1299 > * ISP-A 174 > * ISP-B 1299 > > If I'm unable to do that will most provider prepend on your behalf so that > ISP-A > would add the prepends for 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.
Re: BGP Traffic Engineering - Active\Passive
On Fri, 21 May 2021 at 17:13, nanoguser100 via NANOG wrote: > If I'm unable to do that will most provider prepend on your behalf so that > ISP-A would add the prepends for only? For this part, you will have to investigate which BGP standard/extended/large communities your ISP-A/B supports. By setting the correct community, your upstream can do the prepending for you. (usually 1, 2, or 3 times depending on the supported communities) E.g. * ISP-A 174 * ISP-B 1299 1299 or * ISP-A 174 174 174 * ISP-B 1299 > Now to mix this up let's say another ASN, was in-between 1299 and > but latency wise the route was still faster. Some(!) ISP's will support _only_ prepending to select ASN's they peer with. E.g. * prepend only to peers * prepend only to customers * prepend only to other upstream (in case of T2 and T3) * prepend if a route is exported outside $region-Y * prepend to ASN x 1-time * prepend to ASN x 2-times * prepend to ASN x 3-times E.g. * ISP-A 174 174 174 65001 * ISP-A 174 174 174 65002 * ISP-A 174 174 174 65003 * ISP-A 174 * ISP-B 1299 1299 You will need to investigate which BGP communities your ISP's support for the above example to be relevant to you. If they do not have the docs available on their public website or customer portal. Ask their support for a list of supported communities. /Chriztoffer
BGP Traffic Engineering - Active\Passive
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 174 * ISP-B 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, 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 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 traffic? to make: * ISP-A 174 * ISP-B 1299 * ISP-A 174 * ISP-B 1299 If I'm unable to do that will most provider prepend on your behalf so that ISP-A would add the prepends for only? Now to mix this up let's say another ASN, was in-between 1299 and but latency wise the route was still faster. - nanoguser100 Sent with [ProtonMail](https://protonmail.com) Secure Email.
