Reading between the lines this network’s current lack of diverse providers is consistent with a geographic/monopoly disadvantage. I do agree that your transit provider is in bad form to pad your routes, but it does happen. A phone call or email to understand their limitations may be helpful. Trying to fit all of your traffic into an upstream’s own uplink that is far to small does not provide the best user experience. It could be an bug in the route-map. Speaking of bugs, trying to use communities can cause you to observe bugs in other network’s route-maps (with great power comes great…). Padding much past three usually has little affect. Splitting your advertisement into say four smaller announcements and starting to advertise them one at a time through your preferred provider is a good place to start. Traffic will prefer the more specific route. With luck that was done last night 😊 Once you have balanced this out somewhat, you have bought yourself time. Next fun thing is to understand how this works when one provider fails or similar. Traffic can prefer the oldest route, so a small bump down the road can cause unanticipated traffic changes the next nightly peak. Or to put it another way, this is how the sausage is made. P.S. Both of us top posting is also bad form. Kevin Burke 802-540-0979 Burlington Telecom 200 Church St, Burlington, VT From: NANOG <nanog-bounces+kburke=burlingtontelecom.com@nanog.org> On Behalf Of Douglas Fischer Sent: Thursday, October 20, 2022 8:51 AM To: Pirawat WATANAPONGSE <pirawat.w@ku.th> Cc: nanog@nanog.org Subject: Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing? WARNING!! This message originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. If your Upstream(Transit provider) prepends your routes without you asking or authorizing it to do so, you should SERIOUSLY consider switching providers! In the other email I talked about traffic engineering BGP communities. If those prepends were made from some community you were applying... OK, that's great! Even better if you could apply a community that did something like "apply 2 prepends for south america only". But a Transit Provider changing the AS-PATH (in addition to the mandatory hop) arbitrarily without your consent is not for good people. P.S. Your email replies are breaking threads in email readers. I suggest you review the email client tool. Em qui., 20 de out. de 2022 às 09:16, Pirawat WATANAPONGSE via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> escreveu: Dear all, Before all else: thank you all for the lightning-fast responses (even taking the time zone advantage into account). I really, really, really appreciate all your recommendations. Virtually all of you recommend prepending as the first choice. I also get the feeling that you guys consider de-aggregation “distasteful” (at the least) but sometimes unavoidable. I have considered the prepending myself, but dare not implement it yet for the fear that BGP (Human) Community will burn me alive, witch-hunt style, because of the following reasons: 1. I can see from looking glass(es) that my upstreams already practice prepending (some paths) at their level (at least 3 more hops [x4]), supposedly to “balance” their bandwidth. 2. Should I start prepending mine, I might upset their balance, causing them to prepend more, thus starting a “prepend war”. [I imagine that x20+ prepending starts out this way] The way I see it, prepending (or maybe even the whole BGP-Path thing) is a local-optimization problem: it’s only best for someone, not globally. And the Higher-Tiers (Lower Tier-Numbers) will always “engineer” me in the end. Worse yet, I might be out-voted by de-aggregation insider “cultists” anyway. Which forces me to proactively ask you guys questions about ROV-Overlapping and ROV “Hijack Gap” soon, in another posting with separate “Subject:”. Again, Thank you. Cheers, Pirawat. P.S. [Off-Topic] Any comment on the “SCION” System? Any good (I will even take "academically")? [Reference: https://scion-architecture.net/] -- Douglas Fernando Fischer Engº de Controle e Automação

On Thu, 20 Oct 2022, Tom Beecher wrote:

1. Prepending by itself isn’t bad. Prepending past the point that it is effective in accomplishing anything is what you generally want to avoid. Even then, it’s not nearly as big a deal as some make it out to be in most cases. 

To me, it's somewhat comical to see routes prepended 10-20 or more times. If one or two prepends doesn't do it, 10-20 isn't likely to either. AFAIK, it's pretty common to use localpref to prefer peering (free) routes over transit (paid paths), and in cases where remote networks see your prepended path via peering, "no amount" of prepends is going change the fact that they prefer the free path. 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. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

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