location db mismatch

location db mismatch

[nusenu]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

Hi,

I'm trying to understand a difference between the local updated
database and the output seen on location.ipfire.org:

sha256sum /var/lib/location/database.db
fe305bea50c2a916cf9f5c4a1bdee8457ced3033279d7e64598141bb0f1bd607  /var/lib/location/database.db

location version
Fri, 21 Jan 2022 05:50:50 GMT

location:amd64 0.9.9-2

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


https://location.ipfire.org/lookup/89.58.16.0
> Network        89.58.16.0/22
> Announced by   AS197540 - netcup GmbH
> Country        Austria 

https://stat.ripe.net/widget/whois#w.resource=89.58.16.0
> inetnum	89.58.16.0/22
> netname	AT-NETCUP-01
> country	AT
> status	ASSIGNED PA
> mnt-by	NETCUP-MNT
> mnt-by	NETCUP-MNT
> source	RIPE


I'm wondering if something is broken on my side?


kind regards,
nusenu

-- 
https://nusenu.github.io

Re: location db mismatch

[nusenu]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]



after fetching the database.txt from
https://git.ipfire.org/?p=location/location-database.git;a=tree;hb=HEAD

grep 89.58.16.0/22 -A2 database.txt -n
1340305:net:                     89.58.16.0/22
1340306-country:                 DE
1340307-aut-num:                 197540

I get the same result as locally.

So now I'm wondering what file is used for the service at:
https://location.ipfire.org/

kind regards,
nusenu


-- 
https://nusenu.github.io

Re: location db mismatch

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

Hello,

> On 21 Jan 2022, at 19:02, nusenu <nusenu-lists(a)riseup.net> wrote:
> 
> 
> 
> after fetching the database.txt from
> https://git.ipfire.org/?p=location/location-database.git;a=tree;hb=HEAD
> 
> grep 89.58.16.0/22 -A2 database.txt -n
> 1340305:net:                     89.58.16.0/22
> 1340306-country:                 DE
> 1340307-aut-num:                 197540
> 
> I get the same result as locally.
> 
> So now I'm wondering what file is used for the service at:
> https://location.ipfire.org/

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.

-Michael

> 
> kind regards,
> nusenu
> 
> 
> -- 
> https://nusenu.github.io

Re: location db mismatch

[nusenu]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

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

-- 
https://nusenu.github.io

Re: location db mismatch

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

Hello,

I believe this is one for Peter.

-Michael

> On 24 Jan 2022, at 17:37, nusenu <nusenu-lists(a)riseup.net> wrote:
> 
> 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
> 
> -- 
> https://nusenu.github.io

Re: location db mismatch

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 6649 bytes --]

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

Re: location db mismatch

[nusenu]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

Hi Peter,

Peter Müller:
> 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.

thanks for your thorough reply.
For me the relevant part was that this is due to a manual override.
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?

I don't have any information on where these prefixes are actually located.

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 fiven AS, I didn't expect that to be feasible :)

kind regards,
nusenu




-- 
https://nusenu.github.io

Re: location db mismatch

[Martin Gebhardt (Die LINKE.)]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

Hello Peter,

through me the topic came up here, originally my question was asked to 
the tor-relay operator list, because in the metrics a wrong location was 
given.

I work at Anexia, specifically for netcup in Karlsruhe. Our datacenter 
and AS197540 is in Nuremberg.

Meanwhile, as you wrote, we are part of Anexia in Austria. This made new 
products possible for us.

https://www.netcup.de/vserver/root-server-vienna/

(I don't know why this page is only available in german..)

On 1/25/22 19:15, Peter Müller wrote:
[..]> 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.

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

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

This customer itself is based in Switzerland. Their website tells us 
that their servers are located in Germany.

https://www.hoststar.ch/en/hosting/product-comparison (Dropdown 
"Hosting", then "Server location")

Here a manual overwrite is correct.

[..]> 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 hope I could clarify a little bit.

Thanks and regards,
Martin

Re: location db mismatch

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]

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

Re: location db mismatch

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

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

Re: location db mismatch

[Martin Gebhardt]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

Hello Peter,

On 2/4/22 14:40, Peter Müller wrote:
[..]
>> 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.

I have opened a ticket at our NOC. I agree with you there and I wonder 
what that inadequate state is...

[..]> 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 for that.

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

--Martin

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3466 bytes --]

Re: location db mismatch

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

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(a)maverick ~]# location version
> Tue, 08 Feb 2022 06:03:14 GMT
> [root(a)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(a)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