From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: location@lists.ipfire.org Subject: Re: location db mismatch Date: Tue, 25 Jan 2022 18:15:44 +0000 Message-ID: In-Reply-To: <1D1C8279-E28B-44FA-AE24-F964BA2186F8@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5741251671298902845==" List-Id: --===============5741251671298902845== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, hello nusenu, hello Martin (???), sorry for my late reply. Yes, this change is due to an override of mine, committed as f3901759ede298e4= 9cf5c056d0655b97e86cd211, affecting all location databases generated after January 9th, 2022. This is because German hoster netcup GmbH claims to be located solely in Germ= any - 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 Internetdienstlei= stungs GmbH now, but apparently they did not align the country codes to the physical location of their servic= es. 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 arbit= rary 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, t= o have inaccuracies covered for the entire Autonomous System. After all, they claim it is not being locat= ed somewhere else than DE. While investigating on this further after reading your mail, I have some doub= ts. First, there is 2a04:b500::/32, apparently owned by a customer of netcup / AN= EXIA: > 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 late= ncy: ~ 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 late= ncy: ~ 2040 ms > 10. (waiting for reply) > 11. (no route to host) According to sources, I believe with a medium level of confidence 2a00:11c0:4= 7: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 t= raceroutes end somewhere in ANEXIA's main AS47147, being used at least across Europe. An IPv6 customer of netc= up (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, d= iverting the traffic to their scrubbing centers, which one of them appears to be located in Vienna, AT. The= y might just disabled ICMP responses to tracerouting attempts temporarily. Do you happen to have further information on this, especially related to 89.5= 8.16.0/22? Thanks, and best regards, Peter M=C3=BCller --===============5741251671298902845==--