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 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.
On Fri, 21 May 2021 at 17:13, nanoguser100 via NANOG <nanog@nanog.org> wrote:
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?
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 1111 174 4444 * ISP-B 1111 1299 1299 4444 or * ISP-A 1111 174 174 174 4444 * ISP-B 1111 1299 4444
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.
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 xxxxx 1-time * prepend to ASN xxxxx 2-times * prepend to ASN xxxxx 3-times E.g. * ISP-A 1111 174 174 174 65001 * ISP-A 1111 174 174 174 65002 * ISP-A 1111 174 174 174 65003 * ISP-A 1111 174 7777 * ISP-B 1111 1299 1299 7777 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
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
participants (3)
-
Baldur Norddahl -
Chriztoffer Hansen -
nanoguser100