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:
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.
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
* ISP-A 1111 174 4444
* ISP-B 1111 1299 1299 4444
* 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.
* 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
* 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.
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.