185.177.148.0/22 is allocated to Bradler & Krantz GmbH & Co KG and has it's country code set to "DE". However, subnets of this /22 are announced from LT, UK and MD, but are still reported to be located in DE by libloc. 185.177.148.0/23 should be GB instead. 185.177.150.0/24 should be LT instead. 185.177.151.0/24 should be MD instead. In my humble opinion, we should fix this as it seems rather common to allocate larger networks to a corporate headquarter (and inserting the corresponding country code in it's RIR object) while announcing subnets from different locations. I am aware of this making things more complicated, but since we have all necessary data already (announcements via BGP, country codes via RIR except for ARIN as far as I am concerned), this seems to be a low-haning fruit making or database more accurate.
The smaller subnets like 185.177.148.0/23 are not part of the feed that we download from RIPE. That is why they won't show up. I do not know what I can do about that. (In reply to Peter Müller from comment #0) > In my humble opinion, we should fix this as it seems rather common to > allocate larger networks to a corporate headquarter (and inserting the > corresponding country code in it's RIR object) while announcing subnets from > different locations. I disagree. We know that the database is not 100% perfect, but it is already a lot better than what we are replacing. We discussed that we are going to release this for now and later will fix the gaps. Otherwise we will never get this released. I will leave this ticket here so that we can work on it when time is available. Could you please find out why the subnets are not part of the RIPE feed?
> I disagree. We know that the database is not 100% perfect, but it is already a > lot better than what we are replacing. We discussed that we are going to > release this for now and later will fix the gaps. Otherwise we will never get > this released. All right, I am fine with that. > I will leave this ticket here so that we can work on it when time is available. D'accord. :-) > Could you please find out why the subnets are not part of the RIPE feed? Yes, I will do so as soon as I have some spare time.
On the other hand, this works perfectly for 196.16.0.0/14 (which is a stolen AfriNIC network, please refer to https://www.spamhaus.org/sbl/query/SBL364590 for further information): The entire /14 is announced by the Dutch bulletproof ISP AS202425 ("IP Volume Inc."), and since there is a country-override entry for this, libloc returns "NL" for this network. Some subnets are announced from different ASNs - for example, 196.19.251.0/24 from AS9009 -, and since there are no overrides for them, libloc returns "SC" for such networks (https://location.ipfire.org/lookup/196.19.251.1). Is that intentional or just a side effect? Either way, it currently is the desired behaviour. :-)
All overrides work for all subnets, too. That is desired behaviour.
> All overrides work for all subnets, too. In this case, they do not as some subnets are announced from different ASNs and the override directive was made for AS202425, not the IP network. :-) > That is desired behaviour. Indeed, thanks for clarifying. :-)
No, the ASNs don’t to that (yet)
This is actually a duplicate of #12458. *** This bug has been marked as a duplicate of bug 12458 ***