3 ms·
> 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
by zamadatix 2y ago
> 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?
- de46le 2y agohttps://datatracker.ietf.org/doc/html/rfc6996#section-5 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?
- rayhaanj 2y agoAlso 4_294_901_931 is actually just small enough to fit in a u32 whose max value is 4_294_967_295
- astrobe_ 2y agoPerhaps hex notation helps to see things better: 0xFFFF00AB. It's actually nearly 64K below the maximum. 0xAB is 171.
- zamadatix 2y agoHa, 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!
- tialaramex 2y agoThe ip2asn-v4-u32.tsv file has 996520704 996520959 4294901931 Unknown AS4294901931 3523770368 3523770623 4294901931 Unknown AS4294901931 3523771136 3523771391 4294901931 Unknown AS4294901931
- maxmouchet 2y agoBogus 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 https://bgpfilterguide.nlnog.net [2] https://www.routeviews.org/routeviews/ https://www.routeviews.org/routeviews/ [3] https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ https://www.ripe.net/analyse/internet-measurements/routing-i... [4] https://hyperspecifics.io https://hyperspecifics.io
- zamadatix 2y agoActually 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 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.
- maxmouchet 2y agoAh right haha. Thanks for the heads up, I should have checked ^^