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....@nanog.org> On Behalf Of Douglas Fischer Sent: Thursday, October 20, 2022 8:51 AM To: Pirawat WATANAPONGSE <pirawa...@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
