On Thu, Oct 20, 2022 at 6:23 AM Jon Lewis <jlewis@lewis.org> wrote:
[...] While writing this though, two things occurred to me.
1) Are there any networks with routing policy that looks at prepends and says "if we see a peering path with >X number of prepends (or maybe just path length >X), demote the localpref to transit or lower"? "i.e. They obviously don't want us using this path, turn it into a backup path."
2) Particularly back when it was found some BGP implementations broke when encountering unusually long as-paths, I think it became somewhat common to reject routes with "crazy long" as-paths. If such policy is still in place in many networks, excessive prepending would actually have the desired effect for those networks. i.e. The excessive prepends would get that path rejected, keeping it from being used.
At a previous job, I explicitly crafted policies that were structured such that: if PREFIXLENGTH > MAXPREFIXLENGTH then reject if ASPATH > MAXASPATH then reject strip_internal_communities if ASPATH > MAX_VALID_PATH then set localpref = TRANSIT_DEPREF_LOCALPREF set communities DEPREF_TRANSIT blah blah blah if match external_signal_communities then set localpref set internal propagation communities set external propagation communities blah blah blah then accept that way, if the prefix size is too small, or the aspath is too long (>100), it gets dropped before even bothering to evaluate communities; save every bit of CPU and memory you can. Then, strip your internal communities off everything else that's a reasonable path length; set a lower threshold for what you consider a "reasonable" internet diameter to be, including a reasonable 3x prepend at one or two levels; if it's longer than that, it's a backup path at best, treat it that way (below standard transit level) finally, on all the remaining routes, evaluate your external signalling communities, and apply internal signalling communities as appropriate, and process normally. There's a clear tradeoff between trying to ensure maximum reachability to the rest of the internet versus protecting your CPU and memory from unnecessary work and state-keeping. As mentioned in another thread, what each network decides the MAXPREFIXLENGTH is will depend on their relationships and the capabilities of their hardware. It doesn't necessarily have to be /24 and /48, but it should be set at the longest value your network can happily support, unless you want to chase down odd connectivity issues in other people's networks. ^_^; Thanks! Matt