Hello,

The web app is using the same database, but from the day it was started. Since it is a long-running application, it won’t re-read the database when it has been changed. This is something that I would like to change and I have created a ticket for this here:

https://bugzilla.ipfire.org/show_bug.cgi?id=12413

Unfortunately I do not have any time at the moment to work on this.

thanks for your explanation.

Do you also know where the mismatch between AT vs. DE comes from?

https://stat.ripe.net/widget/whois#w.resource=89.58.16.0

inetnum 89.58.16.0/22 netname AT-NETCUP-01 country AT

location version Mon, 24 Jan 2022 06:02:28 GMT

location lookup 89.58.17.76 89.58.17.76: Network : 89.58.16.0/22 Country : Germany Autonomous System : AS197540 - netcup GmbH

kind regards, nusenu

Hello Michael, hello nusenu, hello Martin (???),

sorry for my late reply.

Yes, this change is due to an override of mine, committed as f3901759ede298e49cf5c056d0655b97e86cd211, affecting all location databases generated after January 9th, 2022.

This is because German hoster netcup GmbH claims to be located solely in Germany - quoted from https://www.netcup.eu/ueber-netcup/rechenzentrum.php:

The infrastructure of the netcup GmbH is located in Nuremberg, Germany.

However, some prefixes announced by AS197540 show country codes set to AT or CH. The former is probably thanks to netcup being a subsidiary of Austria-based ANEXIA Internetdienstleistungs GmbH now, but apparently they did not align the country codes to the physical location of their services.

185.216.176.0/22 is a good example:

inetnum: 185.216.176.0 - 185.216.179.255 netname: AT-ANEXIA-20170808 country: AT org: ORG-AIG10-RIPE admin-c: ANXT-RIPE tech-c: ANXT-RIPE status: ALLOCATED PA mnt-by: ANEXIA-MNT mnt-by: RIPE-NCC-HM-MNT created: 2021-09-08T11:53:09Z last-modified: 2021-09-08T11:53:09Z source: RIPE

Yet the entire /22 is announced out of DE (185.216.176.191 picked as an arbitrary example):

1. x
2. x
3. x
4. x
5. AS47147 ae10-0.bbr01.anx25.fra.de.anexia-it.net (144.208.208.211)
6. AS47147 ae0-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.142)
7. AS47147 ae1-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.140)
8. AS47147 94.16.25.77 (94.16.25.77)
9. AS197540 v220201236964137497.bestsrv.de (185.216.176.191)

At this point, I thought a blanket override for AS197540 might be in order, to have inaccuracies covered for the entire Autonomous System. After all, they claim it is not being located somewhere else than DE.

While investigating on this further after reading your mail, I have some doubts.

First, there is 2a04:b500::/32, apparently owned by a customer of netcup / ANEXIA:

inet6num: 2a04:b500::/29 netname: CH-HOSTSTAR-20140224 country: CH org: ORG-MNA17-RIPE admin-c: HSTR13 tech-c: HSTR13 status: ALLOCATED-BY-RIR mnt-by: RIPE-NCC-HM-MNT mnt-by: HSTR-FBR mnt-routes: HSTR-FBR mnt-routes: NETCUP-MNT created: 2014-02-24T07:07:25Z mnt-domains: NETCUP-MNT mnt-domains: HSTR-FBR last-modified: 2017-01-18T12:26:29Z source: RIPE # Filtered

Traceroutes to a destination in this /32 are rather funny:

1. x
2. x
3. x
4. AS47147 2a00:11c0:47:1:47::213 (2a00:11c0:47:1:47::213)
5. AS47147 2a00:11c0:47:3::33 (2a00:11c0:47:3::33) <<<<< average latency: ~ 2020 ms
6. (no route to host)

1. x
2. x
3. x
4. x
5. AS9002 RT.IRX.VIE.AT.retn.net (2a02:2d8::57f5:e0af)
6. AS??? et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (2001:7f8:30:0:1:1:4:7147)
7. AS47147 2a00:11c0:47:1:47::132 (2a00:11c0:47:1:47::132)
8. AS47147 2a00:11c0:47:1:47::137 (2a00:11c0:47:1:47::137)
9. AS47147 2a00:11c0:47:3::33 (2a00:11c0:47:3::33) <<<<< average latency: ~ 2040 ms
10. (waiting for reply)
11. (no route to host)

According to sources, I believe with a medium level of confidence 2a00:11c0:47:1:47::137 is located in Nuremberg, DE (thanks to ANEXIA for not providing PTRs to their IPv6 space :-/ ), but with a response time of around 2 seconds, the next hop can be located virtually anywhere in the world.

Oddly enough, the /22 you mentioned in your mail first traces to Vienna, AT, indeed, but then shows the same behaviour:

1. x
2. x
3. x
4. AS201011 ae16-2074.fra10.core-backbone.com (81.95.2.137)
5. AS1299 ffm-b5-link.ip.twelve99.net (62.115.9.225)
6. AS1299 anexia-ic327209-ffm-b5.ip.twelve99-cust.net (62.115.14.117)
7. AS47147 ae0-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.142)
8. AS47147 ae1-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.140)
9. AS47147 ae0-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.138)
10. AS47147 ae2-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.136)
11. AS47147 ae1-0.bbr02.anx04.vie.at.anexia-it.net (144.208.208.130)
12. AS47147 94.16.25.91 (94.16.25.91) <<<<< average latency: ~ 2020 ms
13. (waiting for reply)

1. x
2. x
3. x
4. x
5. AS9002 ae1-3.rt.irx.sto.se.retn.net (87.245.234.206)
6. AS1299 s-b3-link.ip.twelve99.net (62.115.174.226)
7. AS1299 s-bb2-link.ip.twelve99.net (62.115.118.108)
8. AS1299 ffm-bb2-link.ip.twelve99.net (62.115.138.105)
9. AS1299 ffm-b5-link.ip.twelve99.net (62.115.114.91)
10. AS1299 anexia-ic327209-ffm-b5.ip.twelve99-cust.net (62.115.14.117)
11. AS47147 ae0-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.142)
12. AS47147 ae1-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.140)
13. AS47147 ae0-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.138)
14. AS47147 ae2-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.136)
15. AS47147 ae1-0.bbr02.anx04.vie.at.anexia-it.net (144.208.208.130)
16. AS47147 94.16.25.93 (94.16.25.93) <<<<< average latency: ~ 2050 ms
17. (waiting for reply)

Frankly, this leaves me a bit puzzled:

(a) At least one network being announced by AS197540 is certainly not located in AT, albeit claiming to be.

(b) From our BGP feed, we learn 89.58.16.0/22 is announced by AS197540, yet traceroutes end somewhere in ANEXIA's main AS47147, being used at least across Europe. An IPv6 customer of netcup (2a04:b500::/32) shows a similar behaviour.

At the time of writing, I'd still say an override for AS197540 is fine, since it represents what the hosting company claims about its location. With regards to

route: 94.16.25.0/24 descr: powered by ANX descr: More specific route object, announced only descr: for engineering or in case of DDoS attack. origin: AS47147 mnt-by: ANEXIA-MNT created: 2020-10-14T12:11:39Z last-modified: 2020-10-14T12:11:39Z source: RIPE

the current situation might be due to an ongoing DDoS mitigation at ANEXIA, diverting the traffic to their scrubbing centers, which one of them appears to be located in Vienna, AT. They might just disabled ICMP responses to tracerouting attempts temporarily.

Do you happen to have further information on this, especially related to 89.58.16.0/22?

Thanks, and best regards, Peter Müller

Hello nusenu,

Maybe something I'll try to understand further: how can I easily determine if some information is provided due to a manual override vs. the raw WHOIS information? And if it was a manual override: What information did trigger that manual override?

unfortunately, there is no way of telling from the location database itself, since it does not contain the source (RIR, ISP geofeed, override, etc.) of a dataset due to space reasons.

However, manual overrides are always handed in as patches on this mailing list. If they are accepted, you will find them in the location-database Git repository (https://git.ipfire.org/?p=location/location-database.git;a=summary). Also, Patchwork (https://patchwork.ipfire.org/project/location/list/) tracks them, so it should be at least transparent which overrides were in place in a given timespan.

Today, I am the only person creating them, but would really love to see other people becoming active in this topic as well. Triggers for overrides are usually abusive or security-related activities I observe somewhere else, feedback from the IPFire community, or mentions at other mailing lists. As soon as I suspect such a network to have inaccurate or deliberately false country information set, I take a mental note of it.

Should an investigation confirm this, I create an override. Unless it is something urgent, I batch them on a (more or less) weekly basis, and send them to this mailing list.

btw: I'm surprised that you read individual provider company websites to determine and manually override the location of individual ASNs or prefixes of a given AS, I didn't expect that to be feasible

Indeed, this is probably not feasible at a large scale, and I don't do this preemptively, only if a network arises my suspicion. To the best of my knowledge, IPFire Location is less inaccurate - I won't claim we're "more accurate", since defining accuracy is tricky here - than its freely available competitors. At least that's the decision the Tor project came to.

However, I would love to see other people becoming active in this, especially with knowledge of parts of the world I lack oversight of. A "best-effort" approach is completely fine to me, and IMHO better than anything else we've currently got.

Hope to have your question answered.

Thanks, and best regards, Peter Müller

Hello Martin,

thanks for your reply. Please excuse my late reaction - I thought I answered this one earlier, but now saw I did not. :-/

...

...

The infrastructure of the netcup GmbH is located in Nuremberg, Germany.

I will open a ticket with the responsible team to change the statement there.

While doing this, may I ask you to open one as well for PTRs for ANEXIA's IPv6 space? Currently, some of their IPv6 routing infrastructure does not seem to have PTRs assigned, and while this is merely a courtesy to the internet community, it would help a lot while debugging and researching.

(At this point, I am always thankful for backbone providers/carriers having meaningful PTRs for their routing infrastructure set. Although I do not trust them blindly, they really help a lot.)

...

Do you happen to have further information on this, especially related to 89.58.16.0/22?

See https://www.netcup.de/vserver/root-server-vienna/ These are the servers that are really located in Vienna.

This also concerns 2a0a:4cc0::/40

I see, thank you for this information. Currently, we have a blanket override for the entire AS197540, but I will add one for these two networks, so they will be correctly located in AT.

Thanks, and best regards, Peter Müller

Hello Martin,

just a quick follow-up: This is now in production, and any database generated today or later contains the correct country information for those networks.

[root@maverick ~]# location version Tue, 08 Feb 2022 06:03:14 GMT [root@maverick ~]# location lookup 89.58.16.0 89.58.16.0: Network : 89.58.16.0/22 Country : Austria Autonomous System : AS197540 - netcup GmbH [root@maverick ~]# location lookup 2a0a:4cc0:: 2a0a:4cc0::: Network : 2a0a:4cc0::/40 Country : Austria Autonomous System : AS197540 - netcup GmbH

I will also get back to you if we announce more networks in Vienna or elsewhere.

Thanks in advance for this.

Thanks, and best regards, Peter Müller