AS21299 - 46.42.196.0/24 ASN prepending 255 times
If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks! This is a Kazakhstan register IP Block and ASN Network Next Hop Metric LocPrf Weight Path *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
On 3/24/2022 5:43 PM, Erik Sundberg wrote: If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks! This is a Kazakhstan register IP Block and ASN Network Next Hop Metric LocPrf Weight Path *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 <many prepends snipped> ------------------------------------------------------------ This is the one I was asking about in: https://mailman.nanog.org/pipermail/nanog/2022-March/217925.html There're a lot more prefixes from them. 86.107.128.0/21 92.49.252.0/24 176.222.164.0/23 176.222.166.0/23 176.222.181.0/24 37.99.2.0/23 5.34.106.0/23 In that email I was worried they were probing for attack vectors, but when I looked into it I found it has been happening off and on for a fairly long time. My bet is the network guys don't want to do anything until told by non-tech managers as the Kazakhstan people just went through (are still going through?) an authoritarian beat down from the Kazakhstan government helped by the Russian government just before the invasion of Ukraine. scott
I emailed all the contacts listed for their ASN in the RIPE Database. One of them just respond to me saying they will fix this, so there is some hope that this will get addressed. Now that you mentioned it. I remember seeing the previous thread and responding to it. Erik ________________________________ From: surfer@mauigateway.com <surfer@mauigateway.com> Sent: Thursday, March 24, 2022 11:45 PM To: Erik Sundberg <ESundberg@nitelusa.com>; nanog@nanog.org <nanog@nanog.org> Subject: Re: AS21299 - 46.42.196.0/24 ASN prepending 255 times On 3/24/2022 5:43 PM, Erik Sundberg wrote: If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks! This is a Kazakhstan register IP Block and ASN Network Next Hop Metric LocPrf Weight Path *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 <many prepends snipped> ------------------------------------------------------------ This is the one I was asking about in: https://mailman.nanog.org/pipermail/nanog/2022-March/217925.html There're a lot more prefixes from them. 86.107.128.0/21 92.49.252.0/24 176.222.164.0/23 176.222.166.0/23 176.222.181.0/24 37.99.2.0/23 5.34.106.0/23 In that email I was worried they were probing for attack vectors, but when I looked into it I found it has been happening off and on for a fairly long time. My bet is the network guys don't want to do anything until told by non-tech managers as the Kazakhstan people just went through (are still going through?) an authoritarian beat down from the Kazakhstan government helped by the Russian government just before the invasion of Ukraine. scott ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
:) probably the longest prepend in the world. A thought though, is it breaking any standard or best practice procedures? Regards Paschal Masha | Engineering Skype ID: paschal.masha ----- Original Message ----- From: "Erik Sundberg" <ESundberg@nitelusa.com> To: "nanog" <nanog@nanog.org> Sent: Friday, March 25, 2022 6:43:38 AM Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks! This is a Kazakhstan register IP Block and ASN Network Next Hop Metric LocPrf Weight Path *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Paschal Masha <paschal.masha@ke.wananchi.com> writes:
:) probably the longest prepend in the world.
A thought though, is it breaking any standard or best practice procedures?
Don't think so. But there is this draft suggesting max 5: https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/ Bjørn
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 procedures?
Many popular BGP implementations have historically had weaknesses with excessively long AS-paths. Best practice is to protect ones' infrastructure so many networks drop paths over certain lengths (at various times, 50 or 100 were common due to specific issues). It is highly common for any filtering mechanism, once established, to stay in place, so I fully expect this path to be invible to many and fragile for the rest [see https://blog.apnic.net/2019/07/15/excessive-bgp-as-path-prepending-is-a-self...]. 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 -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
On Fri, 25 Mar 2022 at 17:32, Joe Provo <nanog-post@rsuc.gweep.net> wrote:
That said, prepending pretty much anything more than your current view of the Internet's diameter in ASNs is useless in practice.
That is one way of viewing it. But prepending can also be used for traffic engineering. I could prepend 1 to my free peers, 2 to my paid peers, 3 to cheap ip transit, 4 to expensive ip transit etc. The linked draft RFC does not appear to discuss this at all. The depth of prepending used this way only relates to how many different classes of peers you can imagine in your setup and is not at all related to the "internet's diameter". To someone on the other side of the planet, who are neither peers nor customers of peers, they will just observe that I am prepending 3 or 4 times and wondering why the extra prepends? The answer is that closer to my home there are people who are observing the same routes with 1 or 2 prepends and that it matters. The draft RFC lists some alternatives to prepends of which none can do anything of the sort I just described. Regards, Baldur
On Fri, 25 Mar 2022, Baldur Norddahl wrote:
On Fri, 25 Mar 2022 at 17:32, Joe Provo <nanog-post@rsuc.gweep.net> wrote: That said, prepending pretty much anything more than your current view of the Internet's diameter in ASNs is useless in practice.
That is one way of viewing it. But prepending can also be used for traffic engineering. I could prepend 1 to my free peers, 2 to my paid peers, 3 to cheap ip transit, 4 to expensive ip transit etc. The linked draft RFC does not appear to discuss this at all. The depth of prepending used this way only relates to how many different classes of peers you can imagine in your setup and is not at all related to the "internet's diameter".
Is prepending used for any purpose other than TE? The point I think Joe was trying to make was prepending once or even a few times has uses. Prepending more than a few times is unlikely to accomplish anything a few prepends didn't get done. Prepending 50, 100, 200+ times is kind of a universal "We have no clue what we're doing and you should reject our routes." Once upon a time, such long prepends would break certain BGP implementations, causing session resets when a route like this was encountered. Hopefully, that's not a problem anymore, but enough networks likely still block excessive prepends that you shouldn't expect to be able to do this and have your route globally accepted...just like you can't advertise a v4 /25 and expect global reachability if there are no covering aggregate advertisements. The interesting question here is, "did they really think a few more prepends would get the job done?" or did they misunderstand their router's prepend function, prepend 21299 (thinking they were telling it to prepend their ASN), and that got truncated because the syntax was actually telling it how many times to prepend the local AS? I'm guessing the latter, as they seem to have 254 prepends, and I'm guessing 255 is the max number of instances of their ASN their router is willing to put on an advertised route. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Sun, 27 Mar 2022 at 18:31, Jon Lewis <jlewis@lewis.org> wrote:
Is prepending used for any purpose other than TE? The point I think Joe was trying to make was prepending once or even a few times has uses. Prepending more than a few times is unlikely to accomplish anything a few prepends didn't get done.
I suppose so-called "backup routes" could also be called traffic engineering yet it is different from the use case I described. I understand the "diameter of the internet" to mean the maximum number of unique AS numbers in an AS PATH observed in any route in my DFZ routing table. Say I have two IP transit uplinks and I want one to be strictly backup meaning I want to receive no traffic unless the other is down. I might then prepend at least "the diameter of the internet" and that would be enough. Any more prepends will do nothing. This could probably be proven mathematically for the worst case, although in reality you would not even need that many prepends to get the effect. However using prepends for traffic engineering in the sense prioritizing my peers relatively to each other is completely different. Especially true when some are peers on internet exchanges (not IP transit). Here the diameter of the internet is completely irrelevant. What matters is the number of classes I can make up for my peers. I admit those two numbers might not be all that different, but I feel it is still worth pointing out the error in the logic. The logic is wrong even for the backup case. Say I have an extreme of N x IP transits and I want all of them to be backups in a strict order. Such that all traffic comes in on transit A. If transit A is down, then everything should use B. If A and B are down then 100% to C etc. In that case I would need to prepend "the diameter of the internet" on B and "the diameter of the internet" times two on C etc. Why times two and not + 1? Because when A is down we have B with a number of prepends. C needs to have "the diameter of the internet" more than B to be sure no traffic goes that way when B is active. Prepending 50, 100, 200+ times is kind of a universal "We have no clue
what we're doing and you should reject our routes."
That is likely yes. Regards, Baldur
Joe Provo 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 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
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
Matthew Petach wrote:
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.
IOW if your peer or customer has prepended 5 times or more, dont LOCAL_PREF or maybe even de-LOCAL_PREF it <very good advice snipped>
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
I think more and perhaps different knobs were and still are needed. Here is an idea, as part of the all extra processing updates have to go through nowadays, how about a long call back to each AS in the path using some sort of standardized service, perhaps published via DNS, sort of an automated looking glass results compared to update-out. And then the receiver, however many AS's away starts to get a much clearer picture of the intent all the through and maybe perhaps some much better intelligent automated properly reactive internet wide traffic engineering standards will emerge. Until then I think a slew of standardized communities that elicit near universal and predictable standard reactions is probably the best bet. The problem is that shifting too much control to the advertiser makes it a non-starter from the point of view of the receiver, and then you can forget about deployment. Would be nice to be able to publish your community scheme as simply conforming with RFCX and the to configure peers with process-rfcX statement and be mostly done. Joe
-----Original Message----- From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> On Behalf Of Joe Maimon Sent: Thursday, March 31, 2022 6:20 PM Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
[...] I think more and perhaps different knobs were and still are needed.
YES. YESYESYES. Having said that, I am currently able to express my local traffic policies (roughly 1/3 due to one particular upstream hamstrung by their parent company, 1/3 due to NREN, 1/3 due to local IXP) using prepends of no more than +2 (both outbound and inbound, which I gather might be somewhat unusual). That includes dealing with a "special" issue because both my local NREN RAN and I are both connected to the local IXP, and to a mutual downstream, which produces an interesting double-triangle topology, and this topology produces surprising emergent behaviours that I haven't seen described anywhere. Prior to some reorganization (and several compromises) I needed +5 on both inbound and outbound (usually not at the same time) to adequately steer normal traffic. Prepending is, IMHO literally, the abuse of a mechanism not initially designed to express complex policies. It's a 1-dimensional tool in a space that really needs a 2- or 3-dimensional tool. LOCAL_PREF is not useful for me and my upstreams, downstreams and peers: I have not yet found a scenario where it fixes any of my problems without creating even greater ones. My traffic-steering issues ~all exist n>3 hops away, not directly with my BGP peers. So prepending remains the only useful, usable knob I have. And it's not a great knob for this, which I think might be the one thing everyone here can agree on!
through nowadays, how about a long call back to each AS in the path
I'm not really loving that solution more than prepends, but at least it's something different?
Would be nice to be able to publish your community scheme as simply conforming with RFCX and the to configure peers with process-rfcX statement and be mostly done.
That's a LONG way off! Not that any other solution isn't equally far off, so... <shrug> Gotta start somewhere, I guess! I don't have any better suggestions, other than I wish the LOCAL_PREF crowd could understand that it doesn't solve all the world's problems. (Neither of my commercial upstreams currently admit to supporting communities that control it, anyway!) Frustrated at the state of the world today, -Adam Adam Thompson Consultant, Infrastructure Services MERLIN 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca www.merlin.mb.ca
The best practice with regards to as_path length is to have an edge filter that dumps any prefix with a length longer than say 10. Depending on the situation, might even be able to go smaller. At a certain point, keeping that route around does nothing for you, just shoot it and ride the 0/0 train. On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha <paschal.masha@ke.wananchi.com> wrote:
:) probably the longest prepend in the world.
A thought though, is it breaking any standard or best practice procedures?
Regards Paschal Masha | Engineering Skype ID: paschal.masha
----- Original Message ----- From: "Erik Sundberg" <ESundberg@nitelusa.com> To: "nanog" <nanog@nanog.org> Sent: Friday, March 25, 2022 6:43:38 AM Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks!
This is a Kazakhstan register IP Block and ASN
Network Next Hop Metric LocPrf Weight Path
*> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i
CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Tom, how exactly does someone “ride the 0/0” train in the DFZ? I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global inbound traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu). If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place. -Adam Adam Thompson Consultant, Infrastructure Services [MERLIN] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> On Behalf Of Tom Beecher Sent: Friday, March 25, 2022 4:13 PM To: Paschal Masha <paschal.masha@ke.wananchi.com> Cc: nanog <nanog@nanog.org> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times The best practice with regards to as_path length is to have an edge filter that dumps any prefix with a length longer than say 10. Depending on the situation, might even be able to go smaller. At a certain point, keeping that route around does nothing for you, just shoot it and ride the 0/0 train. On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha <paschal.masha@ke.wananchi.com<mailto:paschal.masha@ke.wananchi.com>> wrote: :) probably the longest prepend in the world. A thought though, is it breaking any standard or best practice procedures? Regards Paschal Masha | Engineering Skype ID: paschal.masha ----- Original Message ----- From: "Erik Sundberg" <ESundberg@nitelusa.com<mailto:ESundberg@nitelusa.com>> To: "nanog" <nanog@nanog.org<mailto:nanog@nanog.org>> Sent: Friday, March 25, 2022 6:43:38 AM Subject: DMARC ViolationAS21299 - 46.42.196.0/24<http://46.42.196.0/24> ASN prepending 255 times If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24<http://46.42.196.0/24> from 255 prepends to a more reasonable number of prepends let's say 20. Thanks! This is a Kazakhstan register IP Block and ASN Network Next Hop Metric LocPrf Weight Path *> 46.42.196.0/24<http://46.42.196.0/24> x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Ask your upstream providers for a BGP community tag that lowers localpref below 100 within their network. Set that community tag on any backup routes along with your (moderate) path prepending. The backup upstream will then install that route only if there is no other way to get to your AS. The path prepending remains so that other providers can more quickly install the primary route when it comes back. Those two actions together have always made any backup route behave correctly for me. -Brian
On Mar 25, 2022, at 4:57 PM, Adam Thompson <athompson@merlin.mb.ca> wrote:
Tom, how exactly does someone “ride the 0/0” train in the DFZ?
I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global inbound traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu).
If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place.
-Adam
Adam Thompson Consultant, Infrastructure Services
100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca www.merlin.mb.ca
From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> On Behalf Of Tom Beecher Sent: Friday, March 25, 2022 4:13 PM To: Paschal Masha <paschal.masha@ke.wananchi.com> Cc: nanog <nanog@nanog.org> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
The best practice with regards to as_path length is to have an edge filter that dumps any prefix with a length longer than say 10. Depending on the situation, might even be able to go smaller.
At a certain point, keeping that route around does nothing for you, just shoot it and ride the 0/0 train.
On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha <paschal.masha@ke.wananchi.com> wrote: :) probably the longest prepend in the world.
A thought though, is it breaking any standard or best practice procedures?
Regards Paschal Masha | Engineering Skype ID: paschal.masha
----- Original Message ----- From: "Erik Sundberg" <ESundberg@nitelusa.com> To: "nanog" <nanog@nanog.org> Sent: Friday, March 25, 2022 6:43:38 AM Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks!
This is a Kazakhstan register IP Block and ASN
Network Next Hop Metric LocPrf Weight Path
*> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i
CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson <athompson@merlin.mb.ca> wrote:
Tom, how exactly does someone “ride the 0/0” train in the DFZ?
It's not so much "ride the 0/0 train" as much as it is "treat excessive prepends as network-unreachable" Think of prepends beyond say 10 prepends as a way to signal "infinite" distance--essentially, "unreachable" for that prefix along that path. Anyone that is prepending to do traffic engineering is doing *differential* prepending; that is, a longer number of prepends along one path, with a shorter set of prepends along a different path. So, dropping the inbound announcement with 255 prepends merely means your router will look for the advertisement with a shorter number of prepends on it. If you're only announcing one path for your prefix, and it is prepended 255 times, you're fundamentally not understanding how BGP works, and the only way to get a clue-by-four might be to discover you've made your prefix invisible to a significant portion of the internet.
I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global *inbound* traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu).
If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place.
You dump the excessively-long path based on the assumption that the only reason for a long set of prepends out one path is to shift traffic away from that path to one that you're advertising out with a *shorter* set of prepends. The router doesn't need to 'look' for or 'keep track' of the different path; the human makes the decision that any sane BGP speaker would only prepend 255 times on a path if there was a shorter as-path advertisement they wanted people to use instead. So, drop the excessively long prepended path, and make use of the 'should be in the table somewhere' advertisement of the prefix with fewer prepends. Easy-peasy.
-Adam
Hi Matthew and NANOG, I don't want to defend prepending 255 times, and can understand filtering of extra-prepended-announcements, but I think Matthew may not be correct here:
Anyone that is prepending to do traffic engineering is doing *differential* prepending; that is, a longer number of prepends along one path, with a shorter set of prepends along a different path.
So, dropping the inbound announcement with 255 prepends merely means your router will look for the advertisement with a shorter number of prepends on it.
Right. But let's consider the (typical) case where someone is prepending for traffic engineering. Now, if you're not very near to the origin of the prepended announcement, and still received it (and not the shorter alternative), then it is quite likely that you received it since the alternate path failed - and the backup path was announced, instead (by upstreams of the origin). So your router is quite likely not to receive the shorter announcement. After all, if your router received both short and long announcements (from same relationship, e.g., both from providers), then your router would probably select the shorter path anyway, without need to filter out the long one, right? So, filtering announcements with many prepends may cause you to lose connectivity to these networks. Of course, you may not mind losing connectivity to Kazakhstan :) ... best, Amir
--
Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Fri, Mar 25, 2022 at 8:19 PM Matthew Petach <mpetach@netflight.com> wrote:
On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson <athompson@merlin.mb.ca> wrote:
Tom, how exactly does someone “ride the 0/0” train in the DFZ?
It's not so much "ride the 0/0 train" as much as it is "treat excessive prepends as network-unreachable"
Think of prepends beyond say 10 prepends as a way to signal "infinite" distance--essentially, "unreachable" for that prefix along that path.
Anyone that is prepending to do traffic engineering is doing *differential* prepending; that is, a longer number of prepends along one path, with a shorter set of prepends along a different path.
So, dropping the inbound announcement with 255 prepends merely means your router will look for the advertisement with a shorter number of prepends on it.
If you're only announcing one path for your prefix, and it is prepended 255 times, you're fundamentally not understanding how BGP works, and the only way to get a clue-by-four might be to discover you've made your prefix invisible to a significant portion of the internet.
I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global *inbound* traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu).
If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place.
You dump the excessively-long path based on the assumption that the only reason for a long set of prepends out one path is to shift traffic away from that path to one that you're advertising out with a *shorter* set of prepends.
The router doesn't need to 'look' for or 'keep track' of the different path; the human makes the decision that any sane BGP speaker would only prepend 255 times on a path if there was a shorter as-path advertisement they wanted people to use instead.
So, drop the excessively long prepended path, and make use of the 'should be in the table somewhere' advertisement of the prefix with fewer prepends.
Easy-peasy.
-Adam
On Fri, Mar 25, 2022 at 6:19 PM Amir Herzberg <amir.lists@gmail.com> wrote:
Hi Matthew and NANOG,
I don't want to defend prepending 255 times, and can understand filtering of extra-prepended-announcements, but I think Matthew may not be correct here:
Anyone that is prepending to do traffic engineering is doing *differential* prepending; that is, a longer number of prepends along one path, with a shorter set of prepends along a different path.
So, dropping the inbound announcement with 255 prepends merely means your router will look for the advertisement with a shorter number of prepends on it.
Right. But let's consider the (typical) case where someone is prepending for traffic engineering. Now, if you're not very near to the origin of the prepended announcement, and still received it (and not the shorter alternative), then it is quite likely that you received it since the alternate path failed - and the backup path was announced, instead (by upstreams of the origin). So your router is quite likely not to receive the shorter announcement.
Note that as-path prepending only matters as a *differential* value. Choosing between 5 and 8 prepends, for example, gives you 3 levels of differentiation between the paths. Prepending 255 times is equivalent to setting MAXCOST in OSPF; it's an overload setting, saying "don't freaking use this path *EVER*". If you want to traffic engineer, you set your less preferred path with say 5 prepends, and your more preferred path with 3 prepends, and your really really preferred path with 1 prepend. If you're setting 255 prepends on a path, that's not traffic engineering, that's equivalent to setting the overload bit; it's the maximum metric equivalent in a link-state routing protocol. It's clearly a DO-NOT-USE indicator, in the same category as community 0xFFFFFF04 or 65535:0 In short--if someone sends me 255 prepends, it's going to be treated the same way as LSInfinity in OSPF. Matt
After all, if your router received both short and long announcements (from same relationship, e.g., both from providers), then your router would probably select the shorter path anyway, without need to filter out the long one, right?
So, filtering announcements with many prepends may cause you to lose connectivity to these networks. Of course, you may not mind losing connectivity to Kazakhstan :) ...
best, Amir
--
Amir Herzberg
Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook>
On Fri, Mar 25, 2022 at 8:19 PM Matthew Petach <mpetach@netflight.com> wrote:
On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson <athompson@merlin.mb.ca> wrote:
Tom, how exactly does someone “ride the 0/0” train in the DFZ?
It's not so much "ride the 0/0 train" as much as it is "treat excessive prepends as network-unreachable"
Think of prepends beyond say 10 prepends as a way to signal "infinite" distance--essentially, "unreachable" for that prefix along that path.
Anyone that is prepending to do traffic engineering is doing *differential* prepending; that is, a longer number of prepends along one path, with a shorter set of prepends along a different path.
So, dropping the inbound announcement with 255 prepends merely means your router will look for the advertisement with a shorter number of prepends on it.
If you're only announcing one path for your prefix, and it is prepended 255 times, you're fundamentally not understanding how BGP works, and the only way to get a clue-by-four might be to discover you've made your prefix invisible to a significant portion of the internet.
I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global *inbound* traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu).
If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place.
You dump the excessively-long path based on the assumption that the only reason for a long set of prepends out one path is to shift traffic away from that path to one that you're advertising out with a *shorter* set of prepends.
The router doesn't need to 'look' for or 'keep track' of the different path; the human makes the decision that any sane BGP speaker would only prepend 255 times on a path if there was a shorter as-path advertisement they wanted people to use instead.
So, drop the excessively long prepended path, and make use of the 'should be in the table somewhere' advertisement of the prefix with fewer prepends.
Easy-peasy.
-Adam
Mostly what Matt said. ( I should have also said 'ride the 0/0 train INTO the DFZ, my mistake.) Essentially, if ASN X is announcing a prefix with an excessive number of prepends, they are saying to the world 'This path exists , but it is hot garbage.' I'm more than happy to oblige those instructions and just drop that announcement completely. If ASN X announces that prefix with a reasonable number of prepends, happy to take it and use it. If I get a prefix with an as-path longer than 10, (regardless of the state of prepends), I interpret that as : 1. They have made a mistake. 2. Someone else made a mistake. 3. They think that's a good idea, and have some things yet to learn. ( The old clue by four as Matt put it.) 4. It's malicious. 5. They actually are somehow more than 10 ASNs away from me. ( I don't even know if this is possible anymore without extreme effort. ) In any of those scenarios , I don't really care about optimized routing to that destination. Perfectly happy to just follow 0/0 to a DFZ upstream and let it go how it's going to go, or not. If there is a traffic impact such that an exception HAS to be made, that can be addressed as needed, but I can't think of a single circumstance I have hit where the correction involved accepting an obnoxiously long as_path announcement. ( I don't mean to imply none exist ; I'm sure someone has had to work though that. ) Maybe a length of 10 doesn't work for some environments and use cases, but I still am a firm believer that at a certain point, there is a length that becomes straight 'really don't care'. I'd rather not discover a BGP implementation problem or acid trip memory pointer party by accepting announcements that are useless. On Fri, Mar 25, 2022 at 5:56 PM Adam Thompson <athompson@merlin.mb.ca> wrote:
Tom, how exactly does someone “ride the 0/0” train in the DFZ?
I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global *inbound* traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu).
If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place.
-Adam
*Adam Thompson* Consultant, Infrastructure Services [image: MERLIN] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca www.merlin.mb.ca
*From:* NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> *On Behalf Of *Tom Beecher *Sent:* Friday, March 25, 2022 4:13 PM *To:* Paschal Masha <paschal.masha@ke.wananchi.com> *Cc:* nanog <nanog@nanog.org> *Subject:* Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
The best practice with regards to as_path length is to have an edge filter that dumps any prefix with a length longer than say 10. Depending on the situation, might even be able to go smaller.
At a certain point, keeping that route around does nothing for you, just shoot it and ride the 0/0 train.
On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha < paschal.masha@ke.wananchi.com> wrote:
:) probably the longest prepend in the world.
A thought though, is it breaking any standard or best practice procedures?
Regards Paschal Masha | Engineering Skype ID: paschal.masha
----- Original Message ----- From: "Erik Sundberg" <ESundberg@nitelusa.com> To: "nanog" <nanog@nanog.org> Sent: Friday, March 25, 2022 6:43:38 AM Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks!
This is a Kazakhstan register IP Block and ASN
Network Next Hop Metric LocPrf Weight Path
*> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i
CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
I partially agree with you, but… 10 is way too aggressive. I’m already seeing a “true” internet diameter of up to 13 AS hops today. Here’s the data I’m using to form that opinion. [ NOTE: my tooling didn’t handle BGP confederations in the RIB dump properly. It’s sufficiently rare (only 1009 routes in total) that I’m not going back to square one to compensate for that, the data’s not noticeably skewed because of it, with one exception: the len=15 and len=16 entries in the de-prepended tale are both bogus. I left them in in the spirit of full disclosure. ] This is the AS path-length distribution in my RIB as of a few minutes ago. Like everyone else, I do some moderately strange things for <reasons> including artificially locally prepending routes from some of my upstreams, so I’m quite certain no-one else’s will exactly match mine. The overall shape of the distribution, though, should be very similar, probably with the peak shifted left or right slightly. Pathlen Count 1 1864 2 77314 3 223030 4 248878 5 729240 6 627685 7 224092 8 105225 9 60962 10 50201 11 22856 12 11914 13 7224 14 5423 15 4421 16 2756 17 1577 18 945 19 422 20 669 21 477 22 116 23 70 24 75 25 163 26 33 27 40 28 5 29 41 30 5 31 5 33 1 35 12 38 5 39 2 40 1 55 1 I took a look at some of the outliers, and they are, in the extreme cases, somewhat insane, with over 20 prepends or more in those last few cases. However, at least a few of the pathlen>=20 entries could be legit. Could be. Not saying they are, just that there are some paths that aren’t immediately obvious BS and it would take a lot more time & effort to figure that out. I then eliminated ALL the prepends, remote, and local and transit, and that length distribution changes to look like this, which should reflect the “true” diameter of the internet as seen from here: Pathlen Count 1 18950 2 223149 3 563843 4 824648 5 532985 6 165056 7 47559 8 16759 9 8430 10 3746 11 519 12 233 13 6 15 1 16 2 (Interestingly, the shape of the distribution doesn’t change significantly. That hints that most people could be doing prepending in roughly the same way.) Using your suggestion of as AS-PATH length of 10 as a cutoff, you’d be dropping ~4.5% (109,460 routes here) of the total RIB. But even in my artificially de-prepended dataset, I still see 4,507 presumably-legitimate routes with a path length >= 10. I’m not saying a threshold is a bad idea. (I’m on the fence.) I AM saying that using 10 as your cutoff point is too aggressive, and in my opinion, way too aggressive. Based on the de-prepended dataset, the approximate diameter of my internet (not necessarily yours) is 13 AS hops. (Not 15 or 16, see note above.) Since it’s entirely public data, here’s the raw paths from me to AS 270606, prepends and all, that generated my “true” diameter of 13, as recorded in my looking glass: * I* N 177.37.16.0/22 206.211.216.51 100 0 7122 7122 577 6461 52320 53087 262740 262740 262740 262740 262740 262740 266097 268868 61568 26615 10429 263144 270606 * I* N 177.37.16.0/22 206.211.216.52 100 0 7122 7122 577 6461 52320 53087 262740 262740 262740 262740 262740 262740 266097 268868 61568 26615 10429 263144 270606 * I* N 177.37.16.0/22 216.73.71.131 100 0 6327 6327 6327 6461 52320 53087 262740 262740 262740 262740 262740 262740 266097 268868 61568 26615 10429 263144 270606 (Formatting didn’t translate well… the locally-prepended AS path for these 3 examples starts with 7122 7122 577, or 6327 6327 6327.) I do not have any alternate path to those prefixes in my RIB. The deduped 13-long path is “7122 577 6461 52320 53087 262740 266097 268868 61568 26615 10429 263144 270606”. Do I really care if education users in Manitoba can reach R3 Telecom users in Brazil? Probably not (although there are quite a lot of Brazilian international students here, so maybe?) but this demonstrates that the “diameter of the internet” is absolutely not well under 10. I’ll point out, since I speculated about this in a previous email, the most extreme case discussed here was purely on commercial internet, and did not involve NREN paths at all. I went looking for NREN-style prepending and found several examples buried in the middle of the distribution. That presumptive root cause doesn’t appear, at least at first glance, to contribute much to the extreme path lengths I see. Imposing a limit like this has a strong precedent: Sprint(?)’s cap at accepting only /24 and larger, waaaaaay back. Like that action, this max-path-len proposal is likely to be discriminatory because it implicitly favours ASNs located in areas with good connectivity to the “core”, i.e. mainly the eastern US and some areas of western Europe. (I also did not examine the entire path to AS270606 for sanity – it’s not always about simple availability, sometimes perverse incentives play a strong role, too.) If I start looking at the 233 routes of “true” distance 12, where will they be located? Or the 519 at 11? Remember, those are already the de-prepended paths. I don’t want to have to police the RIB that tightly, deciding which routes I will and won’t accept and adjusting the limit periodically. Unless your intent is to eliminate prepend-based traffic engineering from the internet altogether, which case 10 is a perfectly reasonable choice, but in the absence of any other globally-usable tool/knob, that’s a hill I WILL die on. If there’s broad consensus that a path length limit is a good thing, I would suggest a value of no less than 32, based on the data I’ve got in my RIB right now. I think, based only on random sampling of longer AS paths in my RIB, that 32 would still give operators the latitude to perform AS-path-based traffic engineering at origin, during transit, and locally upon receipt, without routes getting inexplicably blackholed anywhere. I’ve heard tonight that a path length limit of 32 is already commonly implemented. Regardless of whether I think that’s a good idea, the spectre of the stack-breakingly-long path seems to be already mitigated in many places, but perhaps not widely? To sum up, Tom’s conclusions as expressed in his email (below) may be qualitatively correct, but they are quantitatively wrong, at least on the matter of the numeric threshold. And… I don’t really want to be the next Sprint(?) in BGP history just to protect myself from newbies on Mikrotiks[1], do you? -Adam [1] and others, yes, I know it’s not purely a Mikrotik issue. Adam Thompson Consultant, Infrastructure Services [MERLIN] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> From: Tom Beecher <beecher@beecher.cc> Sent: Saturday, March 26, 2022 11:35 AM To: Adam Thompson <athompson@merlin.mb.ca> Cc: Paschal Masha <paschal.masha@ke.wananchi.com>; nanog <nanog@nanog.org> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times Mostly what Matt said. ( I should have also said 'ride the 0/0 train INTO the DFZ, my mistake.) Essentially, if ASN X is announcing a prefix with an excessive number of prepends, they are saying to the world 'This path exists , but it is hot garbage.' I'm more than happy to oblige those instructions and just drop that announcement completely. If ASN X announces that prefix with a reasonable number of prepends, happy to take it and use it. If I get a prefix with an as-path longer than 10, (regardless of the state of prepends), I interpret that as : 1. They have made a mistake. 2. Someone else made a mistake. 3. They think that's a good idea, and have some things yet to learn. ( The old clue by four as Matt put it.) 4. It's malicious. 5. They actually are somehow more than 10 ASNs away from me. ( I don't even know if this is possible anymore without extreme effort. ) In any of those scenarios , I don't really care about optimized routing to that destination. Perfectly happy to just follow 0/0 to a DFZ upstream and let it go how it's going to go, or not. If there is a traffic impact such that an exception HAS to be made, that can be addressed as needed, but I can't think of a single circumstance I have hit where the correction involved accepting an obnoxiously long as_path announcement. ( I don't mean to imply none exist ; I'm sure someone has had to work though that. ) Maybe a length of 10 doesn't work for some environments and use cases, but I still am a firm believer that at a certain point, there is a length that becomes straight 'really don't care'. I'd rather not discover a BGP implementation problem or acid trip memory pointer party by accepting announcements that are useless. On Fri, Mar 25, 2022 at 5:56 PM Adam Thompson <athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca>> wrote: Tom, how exactly does someone “ride the 0/0” train in the DFZ? I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global inbound traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu). If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place. -Adam Adam Thompson Consultant, Infrastructure Services [MERLIN] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org<mailto:merlin.mb.ca@nanog.org>> On Behalf Of Tom Beecher Sent: Friday, March 25, 2022 4:13 PM To: Paschal Masha <paschal.masha@ke.wananchi.com<mailto:paschal.masha@ke.wananchi.com>> Cc: nanog <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24<http://46.42.196.0/24> ASN prepending 255 times The best practice with regards to as_path length is to have an edge filter that dumps any prefix with a length longer than say 10. Depending on the situation, might even be able to go smaller. At a certain point, keeping that route around does nothing for you, just shoot it and ride the 0/0 train. On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha <paschal.masha@ke.wananchi.com<mailto:paschal.masha@ke.wananchi.com>> wrote: :) probably the longest prepend in the world. A thought though, is it breaking any standard or best practice procedures? Regards Paschal Masha | Engineering Skype ID: paschal.masha ----- Original Message ----- From: "Erik Sundberg" <ESundberg@nitelusa.com<mailto:ESundberg@nitelusa.com>> To: "nanog" <nanog@nanog.org<mailto:nanog@nanog.org>> Sent: Friday, March 25, 2022 6:43:38 AM Subject: DMARC ViolationAS21299 - 46.42.196.0/24<http://46.42.196.0/24> ASN prepending 255 times If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24<http://46.42.196.0/24> from 255 prepends to a more reasonable number of prepends let's say 20. Thanks! This is a Kazakhstan register IP Block and ASN Network Next Hop Metric LocPrf Weight Path *> 46.42.196.0/24<http://46.42.196.0/24> x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
participants (13)
-
Adam Thompson -
Amir Herzberg -
Baldur Norddahl -
Bjørn Mork -
Brian Knight -
Erik Sundberg -
Joe Maimon -
Joe Provo -
Jon Lewis -
Matthew Petach -
Paschal Masha -
surfer＠mauigateway.com -
Tom Beecher