That said you're ultimately right that my upstream provider is filtering the 4294901866 value from the article as well anyways for the reasons you stated.
Does anyone have a theory to how that 4294967296 might have made its way into the data? I'm getting 0 matches on the actual internet with:
birdc show route protocol peer4 | grep 4294967296 -c
And ASNs are certainly not >32 bit.Edit: actually, I'm not seeing it in the linked iptoasn data either?
IP-to-ASN mappings are typically built from route collectors [2,3] that peer with various networks and receive their announcements. AFAIK route collectors don't filter anything and it's easy to find bogus announcements (e.g. private ASNs) in the data.
I can't find 4294967296 from a quick glance at the latest RouteViews data but I can find other private ASNs. For example AS7594 - AS2764 - AS4294901866 for 210.10.189.0/24 seen by the route-views.perth collector.
I don't know what kind of filtering iptoasn.com is doing but at work (ipinfo.io) we do filter bogus origins, as well as a bunch of other things like RPKI/IRR-invalid routes and hyper-specific prefixes (> /24 or /48) [4].
[1] https://bgpfilterguide.nlnog.net
[2] https://www.routeviews.org/routeviews/
[3] https://www.ripe.net/analyse/internet-measurements/routing-i...
There are several free ASN MMDBs [2,3] but you can also build your own MMDB files from any Prefix->Value mapping with the mmdbwriter library [4] or a CLI tool built on top of it like mmdbctl [5].
Assuming the ASN MMDB is fully loaded in memory, it would use around 60MB.
[1] https://maxmind.github.io/MaxMind-DB/
[2] https://dev.maxmind.com/geoip/docs/databases/asn/
[3] https://ipinfo.io/products/free-ip-data-downloads
[4] https://github.com/maxmind/mmdbwriter
[5] https://github.com/ipinfo/mmdbctl
(I work for IPinfo, but there are lots of other companies offering MMDB files).
Are there an examples of regions which dramatically violate the triangle equality? (That is, where the A--C latency is much worse than the best A--B + B--C latencies)?
Just as a curiosity, could you use that idea to "infer" which data-centers are most likely directly connected by fiber, and show only the likely fiber connections?
Now there are some issues with this methodology (all common issues with ICMP/RTT measurements + traffic was not really routed through the "relay" probe), but such pairs do exist.
[1] https://theses.hal.science/tel-03666771/document (see page 84 for an example; if you can read French :-))
Pretty sure that is the reason why he used
> ping across a Starlink connection from the customer side terminal to the first IP end point behind the Starlink earth station
instead of pinging the terminal itself.
(ICMP packets passing _through_ a router are handled just like any other traffic and are therefore OK for an analysis like this)
These changes are more typical of a physical path change, as suggested by the author.
CPU/soft processing latency would look more like additive noise.
I give some examples of RTT patterns in this talk: https://ripe77.ripe.net/archives/video/2250/
Also, can this data collection see enough of internal China traffic?
I've also played a bit with an interactive visualization of the graph by using map tiles [4].
[1] https://github.com/TheOpteProject/LGL
[2] https://github.com/maxmouchet/minilgl (cleaned-up version of the code)
[3] https://www.maxmouchet.com/internet-viz/
[4] https://github.com/maxmouchet/internet-visualization