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.