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)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: Tom Beecher <beec...@beecher.cc>
Sent: Saturday, March 26, 2022 11:35 AM
To: Adam Thompson <athomp...@merlin.mb.ca>
Cc: Paschal Masha <paschal.ma...@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 
<athomp...@merlin.mb.ca<mailto:athomp...@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)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG 
<nanog-bounces+athompson=merlin.mb...@nanog.org<mailto:merlin.mb...@nanog.org>> 
On Behalf Of Tom Beecher
Sent: Friday, March 25, 2022 4:13 PM
To: Paschal Masha 
<paschal.ma...@ke.wananchi.com<mailto:paschal.ma...@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.ma...@ke.wananchi.com<mailto:paschal.ma...@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" <esundb...@nitelusa.com<mailto:esundb...@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.

Reply via email to