On Thu, Mar 31, 2022 at 3:16 PM Joe Maimon <jmaimon@jmaimon.com> wrote:
On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:
:) probably the longest prepend in the world.
A thought though, is it breaking any standard or best practice
Joe Provo wrote: procedures?
That said, prepending pretty much anything more than your current view of the Internet's diameter in ASNs is useless in practice. Cascading effects are considered in https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/ where a decent low number (5) is propsed.
Chers,
Joe
So is there a good way to signal along with a BGP route that the originator of the route wants you to know that this route has very high suckage factor and even if you normally prefer your peers customers whatever, you should perhaps think twice about that for this route, cause its really last resort.
Because as-path is an overloaded multimeaning traffic influencing hammer that has imprecise and frequently undesirable results. And if that were not the case, than discussions of its relative size compared to internet diameter would be much more relevant.
Joe
Unfortunately, the reason crazy-long prepends actually propagate so widely in the internet core is because most of those decisions to prefer your peer's customers are done using a relatively big and heavy hammer. LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most of the networks out there seem to have settled on, to the point of having published BGP communities to use for controlling the LOCAL_PREF setting on received routes: https://onestep.net/communities/ I've long practiced, and advocated for, the use of MEDs or tweaking origin codes as a better way to nudge traffic towards customers, peers, customers of peers, etc., because it still allows as-path to be a factor in nudging traffic away. Prepend inbound 3 times on routes learned from your transit provider, but not on your peers, listen to MEDs from your peers, and enable always-compare-med and deterministic-med to allow values to be compared across different pathways. That way, someone trying to say "don't use this path" can do a simple triple-prepend, and see their traffic shift. In our current world of using LOCAL_PREF, however, the poor customer keeps prepending more and more, and never sees their traffic shift. In desperation, they prepend the maximum number of times allowed, hoping that maybe this will somehow do the trick...not understanding that no matter what they do in the prepend realm, so long as their upstreams are using the LOCAL_PREF hammer, their prepends will fall on deaf ears. For the most part--if you think LOCAL_PREF is the right knob to use for moving traffic, it probably means you need to go back and rethink your traffic engineering approach. ^_^; Matt