Hello Jordan,
Thank you very much for your email. This has really helped me.
Recently I have been rolling out a lot of changes that massively improve the database. I have not been 100% confident that all problems have been solved, however I did not have and indication that things went wrong.
One of the changes was a deduplication algorithm that is supposed to remove any subnets from the database we don’t need. That works well.
The second change is to merge neighbouring subnets (e.g. 10.0.0.0/24 and 10.0.1.0/24 could be stored as 10.0.0.0/23). That would save a lot of space, too. That algorithm relied on a function to count the bit length of an IP address (i.e. the minimum number of bits I need to represent a certain IP address). That function was total garbage. No idea how that didn’t cause bigger damage.
The fix is now here:
https://git.ipfire.org/?p=location/libloc.git;a=commitdiff;h=edbf280e6e043ea...
I have published an updated version of the database with the fix:
https://git.ipfire.org/?p=location/location-database.git;a=commitdiff;h=16e9...
We now have data for the networks that you have listed (as expected):
root@michael:~# location lookup 209.38.204.47 45.148.122.0 94.16.116.0 198.23.234.0 172.105.192.0 209.38.204.47: Network : 209.38.192.0/18 Country : United States of America Autonomous System : AS14061 - DigitalOcean, LLC 45.148.122.0: Network : 45.148.122.0/24 Country : Netherlands Autonomous System : AS64425 - SKB Enterprise B.V. Hostile Network safe to drop: yes 94.16.116.0: Network : 94.16.112.0/21 Country : Germany Autonomous System : AS197540 - netcup GmbH 198.23.234.0: Network : 198.23.224.0/20 Country : Canada Autonomous System : AS36352 - HostPapa 172.105.192.0: Network : 172.105.0.0/16 Country : United States of America Autonomous System : AS63949 - Akamai Technologies, Inc.
This all matches the table that you have drawn.
So, thank you very much for helping me find this bug. It is solved!
Best, -Michael
P.S. Out of my own curiosity, may I ask what your application for this database is?
On 22 Mar 2024, at 04:03, Jordan Savoca jsavoca@posteo.net wrote:
It seems there has been a significant reduction in the visibility of certain routes in the IPFire dataset recently, and/or spurious routes taking place of legitimate announcements.
For example, 209.38.204.47 is originated by AS14061 and announced in 209.38.192.0/19, but IPFire erroneously sees 209.38.0.0/16 and locates no corresponding AS.
Here are a few more prefixes with the same issue:
+----------+------------------+-----------------+------------+ | ASN | Prefix | IPFire Prefix | IPFire ASN | +----------+------------------+-----------------+------------+ | AS64425 | 45.148.122.0/24 | 45.148.120.0/22 | None | | AS197540 | 94.16.116.0/22 | 94.16.96.0/19 | None | | AS36352 | 198.23.234.0/23 | 198.23.128.0/17 | None | | AS63949 | 172.105.192.0/19 | 172.104.0.0/15 | None | +----------+------------------+-----------------+------------+
Thanks so much for all your hard work,
-- Jordan