RE: jon postel
The book, being written by an actual credentialed historian, contains their complete sources as footnotes/endnotes. That section was overwhelming, I mostly skipped it... Adam Thompson Consultant, Infrastructure Services MERLIN 100 - 135 Innovation Drive Winnipeg, MB R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) https://www.merlin.mb.ca Chat with me on Teams: athomp...@merlin.mb.ca > -Original Message- > From: NANOG On Behalf Of > Carsten Bormann > Sent: October 17, 2022 11:54 AM > To: Grant Taylor > Cc: nanog@nanog.org > Subject: Re: jon postel > > On 2022-10-17, at 16:57, Grant Taylor via NANOG wrote: > > > > In my not so humble opinion, Where Wizards Stay Up Late should be required > reading for anyone wanting to learn about the history / development of the > ARPAnet and the Internet. > > That said, it would be a worthwhile project to collect the places in which > this source can be supplemented with additional information (a.k.a. grains > of salt). > > Grüße, Carsten
RE: any dangers of filtering every /24 on full internet table to preserve FIB space ?
I can't find the original message, so replying to the wrong spot in the thread, but... no, filtering /24s is a bad idea if you want (more or less) all your packets to get to their destinations. If you filter all /24s you will lose reachability to 4x /24s I publish that have no covering route because they are not contiguous and not part of any larger logical aggregate. Then there's the 10-20 legacy /24s I *don't* currently publish - if I start advertising them, you won't be able to reach them, either, because they're in the same boat: discontiguous singletons. There are a LOT of legacy discontiguous IPv4 singletons assigned out of the old Class-C space to small/medium businesses, schools, etc. in the pre-ARIN days, and I would guess that the vast majority of them do not have a correct covering /23 or larger - certainly none of the ones I'm currently working with/aware of do. I believe there's at least a couple of DNS servers running in my /24s, so you could potentially lose access to much more than those /24s. Your packet will *probably* hit a next-hop carrier who happens to have the more-specific /24, and it will *probably* eventually reach me, but I thought everyone more-or-less agreed that internet router was already nondeterministic enough as it is? IMHO, if you don't want all the /24s in your FIB (or even RIB!), just pick a carrier, set a default route, and stop worrying about all the headaches BGP provides. Alternately, a valid technique is to have a default route AND a partial BGP feed (a filtered full feed is by definition a partial feed). That helps optimize outbound routing a little bit, you still get the advantage - mostly - of multiple inbound carriers; but you still have to pick one carrier to do the heavy lifting for you. And you are paying them to route for you, so that's not an unfair shifting of the routing burden, unlike relying on covering routes. Note that this approach does NOT provide any redundancy, unlike having full BGP feeds. Separately, I don't know if Geoff has produced such a survey/article, but if not he can probably type it from memory by now :-). Adam Thompson Consultant, Infrastructure Services MERLIN 100 - 135 Innovation Drive Winnipeg, MB R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) https://www.merlin.mb.ca Chat with me on Teams: athomp...@merlin.mb.ca > -Original Message- > From: NANOG On Behalf Of > Stephane Bortzmeyer > Sent: October 10, 2022 10:21 AM > To: Edvinas Kairys > Cc: NANOG Operators' Group > Subject: Re: any dangers of filtering every /24 on full internet table to > preserve FIB space ? > > On Mon, Oct 10, 2022 at 05:58:45PM +0300, > Edvinas Kairys wrote > a message of 35 lines which said: > > > But theoretically every filtered /24 could be routed via smaller > > prefix /23 /22 /21 or etc. > > I don't think this is true, even in theory, specially for legacy > prefixes. There is probably somewhere a Geoff Huston survey on /24 > without a covering route.
Re: Detecting, mitigating, and preventing distributed large-scale prefix de-aggregation attacks
Your research is remarkably interesting. I intend to study it more closely in the coming days. I just like to share a methodology that I came across to mitigate this type of problem, and that I found very elegant. It's not ideal, but it has very small implementation requirements. Using basically SNMP and Ansible, the company in question historically kept the numbers of received/accepted/rejected routes. Having that information, we could create curves and forecasts from those numbers. And with ansible, cyclically adjusting the session prefix limiters at shorter intervals is quite simple. This way, the practice of ", even if this client is only advertising 3 routes, I'm going to put a limit of 500 routes here so I don't have to keep coming back here to adjust this limit is avoided." Em qui., 20 de out. de 2022 às 16:25, Lars Prehn escreveu: > Dear NANOG, > > Our apologies to those who received this message via multiple channels. > > My colleagues and I recently revisited the topic of prefix de-aggregation > attacks. We believe that the current IPv6 allocation policies combined with > the ever-growing number of interconnection opportunities may facilitate > those attacks to the point where they may circumvent traditional prevention > mechanisms. Hence, we'd like to raise awareness on how to detect, mitigate, > and prevent these kinds of attacks. > > > # Prefix De-aggregation Attacks > > While allocation policies in IPv4 are very tight, even a new LIR can > obtain, e.g., a /29 IPv6 address block from RIPE without justification [1]. > This /29 may source more than a million unique IPv6 prefixes when using all > CIDR sizes between /29 and /48 (the largest CIDR size that is not > filtered). To prevent this many prefixes from flooding the DFZ, many ASes > set a maximum prefix limit on their eBGP sessions. > > When initially introduced, these max-prefix limits prevented prefix > de-aggregation attacks. In today's hyper-connected world, prefix limits > transform these attacks into session-hunting challenges. To better > illustrate this relationship, consider the following example: If an > adversary combines two remote-peering offerings of BSO's IXReach [2] and > Epsilon's Infinity Platform [3], they can establish ports at more than a > hundred peering LANs. If this adversary uses Hurricane Electric as their > IPv6 transit provider and establish a BGP session at every in-common > peering LAN [4], this will lead to 100+ sessions. With a per-session limit > of e.g. 500 prefixes, the adversary could redistribute 50K unique prefixes > via this setup alone. > > If an adversary further increases the number of remote peering providers, > adds announcements from BGP-enabled VPS services (e.g., Vultr [5] among > many others [6]), and contracts additional IPv6 transit providers, they may > globally increase the current IPv6 routing table size manifold. Notably, > each of these new routes would have a valid ROV status once the adversary > adds a single ROA entry for a /29 with a max CIDR size of /48; hence, they > would pass the redistribution requirements for various transit providers. > > While many current router models support multiple million IPv6 routes, > especially older models may crash, drop sessions, or behave in other > unintended ways when either their FIB or RIB runs out of memory. When the > adversary also withdraws all routes simultaneously, the number of updates > generated from BGP's path-hunting may further lead to very high load for > extended periods of time. > > To put this into perspective: Some of you might have noticed increased CPU > load alongside other effects when Vultr was de-aggregating 12k IPv6 > prefixes on October 5th [7]. Using the different methods described above, > an highly-motivated adversary might be able to produce 1-2 orders of > magnitude more updates. > > Please note that we performed various smaller (<600 prefixes) > de-aggregation tests as part of our research---see sections 6 and 8 in the > document referenced at the end of this notification for detailed > explanations. While our experimental setup was very similar to the October > 5th incident (we also announced address space obtained from SecureBit via > VMs within Vultr), we are in no way related to that incident neither did we > share any information about our research or findings with individuals > outside our research group prior to the start of our private disclosure > phase on October 11th. > > > # Detection, Mitigation, and Prevention Mechanisms. > > Luckily, prefix de-aggregation attacks are easily detectable (e.g., based > on prefix-limit notification thresholds or direct routing table size > monitoring) and can be mitigated quickly by filtering either the more > specifics of the covering prefix or all prefixes announced by the > adversary's ASN(s). Effectively, damage can only be done within the human > reaction time---which we hope to shorten with this notification. > > To protect yourself from prefix de-agg
Detecting, mitigating, and preventing distributed large-scale prefix de-aggregation attacks
Dear NANOG, Our apologies to those who received this message via multiple channels. My colleagues and I recently revisited the topic of prefix de-aggregation attacks. We believe that the current IPv6 allocation policies combined with the ever-growing number of interconnection opportunities may facilitate those attacks to the point where they may circumvent traditional prevention mechanisms. Hence, we'd like to raise awareness on how to detect, mitigate, and prevent these kinds of attacks. # Prefix De-aggregation Attacks While allocation policies in IPv4 are very tight, even a new LIR can obtain, e.g., a /29 IPv6 address block from RIPE without justification [1]. This /29 may source more than a million unique IPv6 prefixes when using all CIDR sizes between /29 and /48 (the largest CIDR size that is not filtered). To prevent this many prefixes from flooding the DFZ, many ASes set a maximum prefix limit on their eBGP sessions. When initially introduced, these max-prefix limits prevented prefix de-aggregation attacks. In today's hyper-connected world, prefix limits transform these attacks into session-hunting challenges. To better illustrate this relationship, consider the following example: If an adversary combines two remote-peering offerings of BSO's IXReach [2] and Epsilon's Infinity Platform [3], they can establish ports at more than a hundred peering LANs. If this adversary uses Hurricane Electric as their IPv6 transit provider and establish a BGP session at every in-common peering LAN [4], this will lead to 100+ sessions. With a per-session limit of e.g. 500 prefixes, the adversary could redistribute 50K unique prefixes via this setup alone. If an adversary further increases the number of remote peering providers, adds announcements from BGP-enabled VPS services (e.g., Vultr [5] among many others [6]), and contracts additional IPv6 transit providers, they may globally increase the current IPv6 routing table size manifold. Notably, each of these new routes would have a valid ROV status once the adversary adds a single ROA entry for a /29 with a max CIDR size of /48; hence, they would pass the redistribution requirements for various transit providers. While many current router models support multiple million IPv6 routes, especially older models may crash, drop sessions, or behave in other unintended ways when either their FIB or RIB runs out of memory. When the adversary also withdraws all routes simultaneously, the number of updates generated from BGP's path-hunting may further lead to very high load for extended periods of time. To put this into perspective: Some of you might have noticed increased CPU load alongside other effects when Vultr was de-aggregating 12k IPv6 prefixes on October 5th [7]. Using the different methods described above, an highly-motivated adversary might be able to produce 1-2 orders of magnitude more updates. Please note that we performed various smaller (<600 prefixes) de-aggregation tests as part of our research---see sections 6 and 8 in the document referenced at the end of this notification for detailed explanations. While our experimental setup was very similar to the October 5th incident (we also announced address space obtained from SecureBit via VMs within Vultr), we are in no way related to that incident neither did we share any information about our research or findings with individuals outside our research group prior to the start of our private disclosure phase on October 11th. # Detection, Mitigation, and Prevention Mechanisms. Luckily, prefix de-aggregation attacks are easily detectable (e.g., based on prefix-limit notification thresholds or direct routing table size monitoring) and can be mitigated quickly by filtering either the more specifics of the covering prefix or all prefixes announced by the adversary's ASN(s). Effectively, damage can only be done within the human reaction time---which we hope to shorten with this notification. To protect yourself from prefix de-aggregation attacks, you may establish dynamic yet tight per-session limits on all eBGP sessions. As an adversary could enter unreasonably large values into databases such as PeeringDB, we'd recommend to not solely rely on them but also accept at most 1.5-2x the number of yesterday's prefixes for peers and customers and 1.2x yesterday's routing table size for transit providers (which would currently reflect a headroom of ~32k prefixes with a yearly growth rate of <50k prefixes [8]). We'd also recommend ensuring that the summed prefix limits across all sessions do not drastically exceed the router's maximal FIB size. To protect others, you may: (i) ensure that you only redistribute a certain number of routes per origin; currently, AS 9808 announces the most (~4K) IPv6 prefixes. (ii) ensure that you only redistribute a certain number of more-specific routes for each assigned address block; currently, 2409:8000::/20
abha
abha ahuja died 21 years ago today; a force in routing, ops, and trying to liberate the culture. fort hose who want to pull threads, http://www.neebu.net/~khuon/abha/ https://archive.nanog.org/resources/scholarships/abha_ahuja there are others here who will have much better cites (hint hint). randy
Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
On Thu, Oct 20, 2022 at 6:23 AM Jon Lewis 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
Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
> > 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." > Yes. At a previous job, this is exactly what I did. If the path length was X or longer, set localpref to our last resort value. If path length was Y or longer, then I dropped completely, and at that point following defaults was just as good. Maybe once I hit something that caused a performance problem , but an email to that AS was all it took to fix ; they didn't realize they were prepending that much and corrected it. I have firsthand knowledge of some other networks that do similar things. On Thu, Oct 20, 2022 at 9:21 AM Jon Lewis wrote: > 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_ >
RE: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
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 On Behalf Of Douglas Fischer Sent: Thursday, October 20, 2022 8:51 AM To: Pirawat WATANAPONGSE 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 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
Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
On Thu, Oct 20, 2022 at 5:13 AM Pirawat WATANAPONGSE via NANOG wrote: > 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. Hi Pirawat, You asked the experts how it's done. It's done with prepends. Do you really want to argue with the answer? De-aggregation is a last resort, the bluntest tool in the toolchest. And it costs other people money so they don't appreciate you doing it unless you absolutely have to. https://bill.herrin.us/network/bgpcost.html As others have said, no one is going to yell at you because you prepended your AS two or three or even five times. If you don't get the desired effect after 5, you're running up against a problem prepends won't solve. The typical problem is that your upstream has used "localprefs" to prefer a particular path to you, overriding AS path length as the deciding factor. Competent upstreams that employ this technique also allow you to set a "BGP community" on your advertisement that overrides this behavior. A "BGP Community" is a 32-bit number often expressed as two 16-bit numbers the first of which is the ISP's AS number. When detected by the router, the number causes it to apply some locally-chosen rule to the route. If you ask them, the ISP will provide you with a list of "BGP Communities" (numbers) they allow you to set on your route advertisement along with what action they will take if they see that number. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
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_
Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
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. 2. De-aggregation has it’s uses and it’s place. Have a /20 , but announcing all the component /24s, even though you aren’t doing anything different with any of those? Bad practice. You’re just polluting the global table size for no good reason. However, perhaps you have a set of hosts in a single /24 that you want to try and protect from a prefix hijack. Announce the /20 and that singe /24. Not perfect protection , but provides some cover, and isn’t that big a deal. The answers to all of these questions are really : “It depends on what you are trying to do.” There are generally accepted solutions to certain problems, and there are plenty of dumb solutions that are the only thing possible due to circumstances, so sometimes that’s what you have to do too. Don’t worry about the pitchforks so much. :) On Thu, Oct 20, 2022 at 08:15 Pirawat WATANAPONGSE via NANOG < nanog@nanog.org> wrote: > 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/] > >
Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
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> 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
Re: Prepending
Always a bunch of them out there. Sometimes accidental, sometimes from folks who are trying to do something , just using ineffective methods to do it. On Tue, Oct 18, 2022 at 10:21 Sandoiu Mihai wrote: > Hi > > > > We have witnessed a lot of prepending in the last days, we got a few > internet routes that have 30…200 prepends, did you face the same issue? > > > > Regards > > Mihai >
RE: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
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/]
