Hacker News Reader

Comment by zamadatix | Hacker News Reader

> As an aside – I’m storing the ASN in a uint32, is that right? I looked in the ip2asn file and the biggest one seems to be 401307, though there are a few lines that say 4294901931 which is much bigger and would not fit in a uint32. I decided to just ignore the gigantic ASNs and assume I could fit everything in a uint32.

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?

View on HN

https://datatracker.ietf.org/doc/html/rfc6996#section-5 - it's in the range reserved for private use, so it's probably network internal to wherever the list is originally from?

Bogus announcements are probably filtered by your upstream(s) (see [1] for a common list of filters).

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...

[4] https://hyperspecifics.io

Actually 4294967296 couldn't ever appear as the maximum value you can fit in the protocol field is 1 less than that... my problem here was I couldn't manage to keep the 2 numbers I was comparing (the one in the article and 2^32) straight haha! This was mistake was noted by a commenter here https://news.ycombinator.com/item?id=41963745

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.

Ah right haha. Thanks for the heads up, I should have checked ^^

Also 4_294_901_931 is actually just small enough to fit in a u32 whose max value is 4_294_967_295

Perhaps hex notation helps to see things better: 0xFFFF00AB. It's actually nearly 64K below the maximum. 0xAB is 171.

Ha, this is exactly right! It's 100% in u32 range and part of the private use reservations so wouldn't appear in the internet table unless such values aren't filtered by the provider and/or it's being used locally.

Originally I went to write your exact comment because it seemed the value in the article should fit at a glance and then I must have done the comparison check backwards because I started pasting the 2^32 value in the rest of my comment concluded it was actually too large when really I had just jumbled things about.

Thanks for setting my mind straight!

The ip2asn-v4-u32.tsv file has

    996520704       996520959       4294901931      Unknown AS4294901931

    3523770368      3523770623      4294901931      Unknown AS4294901931

    3523771136      3523771391      4294901931      Unknown AS4294901931

Reply on news.ycombinator.com