On 8/30/23 18:56, michael brooks - ESC wrote:
I, too, am looking for something sexy (explained below). But can you
explain why you think AS_PATH is "useless," Mark?
Because most network operators use LOCAL_PREF heavily, and no amount of
AS_PATH prepending will be able fight that with any reasonable success.
You can still achieve some success with AS_PATH prepending, but with the
way content is getting distributed around the world, it is becoming as
useful as running a Squid cache yourself these days.
For background, and the reason I asked about DPA:
Currently, our routing carries user traffic to a single data center
where it egresses to the Internet via three ISP circuits, two
carriers. We are peering on a single switch stack, so we let L2 "load
balance" user flows for us. We have now brought up another ISP circuit
in a second data center, and are attempting to influence traffic to
return the same path as it egressed our network. Simply, we now have
two datacenters which user traffic can egress, and if one is used we
want that traffic to return to the same data center. It is a problem
of asymmetry. It appears the only tools we have are AS_Path and MED,
and so I have been searching for another solution, that is when I came
across DPA. In further looking at the problem, BGP Communities also
seems to be a possible solution, but as the thread has explored,
communities may/may not be scrubbed upstream. So, presently we are
looking for a solution which can be used with our direct peers.
Obviously, if someone has a better solution, I am all ears.
When you have multiple transit providers, you are really implicitly
accepting that forwarding asymmetry is now part of your life. You will
have full control of your outbound forwarding, but return forwarding
will be a coin toss.
You can guarantee this, to some degree, if you also have lots of
peering, as most peers will prefer to return traffic to you via peering
and not via their transit providers. But even this is not always a sure
thing, especially in situations where a network you are peering with is
doing Remote Peering.
Ultimately, the level of influence you have on the remote network's
forwarding decision, especially if you are not peering, is slim. Our
solution to this has been to focus on the "typically large" transit
providers, announce routes consistently to them, and ensure we have the
same port capacity to each one. Even with those attributes, we can't get
perfect load sharing, because we provide customers the ability to decide
which transit providers (and exchange points) they want their routes to
transit, or not. So the only routing we can consistently guarantee is
our own routes. We can't guarantee customers will let their routes exit
all transit or peering points, so we just make sure we have ample
capacity across all such relationships.
I understand that not all networks may have the ability to do this for
financial reasons, but if you can only afford to have one or two transit
providers, your best bet is to leverage the existing BGP tools as best
you can, even though the results will not be perfect.
Mark.
