Kitz Forum
Chat => Tech Chat => Topic started by: Weaver on June 24, 2018, 05:42:03 AM
-
I have said this before, but I just saw a new level of madness from the Ip2Location service which is a website that is supposed to do a geographical visual traceroute from some server if theirs to a chosen destination
I went to https://www.ip2location.com/free/traceroute and chose "from server in France" and did a traceroute to 81.187.147.197. Starting from Paris, I think, it headed to London via Zürich [!] landed inside Andrews and Arnold, the ISP, then decided that one of Andrews and Arnold’s intermediate internal routers is in Atlanta, USA, so it went off there for a short break, then came back to Andrews and Arnold where it decided to stay in Bracknell after all. It is the IPv4 address 204.68.252.151 that is shown by them as being in the USA.
Complete and utter insanity, unless AA is being intentionally evil with them.
-
Hi weaver
I could be wrong sorry, but I always thought geolocation looked up the cidr owner, which shows the country and sometimes the area, so say uk, Manchester for a cidr range.
This would explain why it can be wrong
We use geolocation for blocking certain countries to our systems
To show you exactly what I mean, which periodically keeps happening, some clients of ours are contacted by competitors, and they let them know they are hosted in Scotland. I soon correct them and give them the correct location of maidenhead with dark fibre to redbus. I also point out the lack of understanding of how geolocation works and it’s failings by the competitor.
So how does the location show as Scotland and not Maidenhead
We use pulsant, who register their cidr to headoffice, which is Scotland.
I know it is possible to track an ip to a central hub, and then as it goes further out, the results become less accurate and to attain the exact location of an broadband IP, would require access into the broadband supplier database (which should not happen unless court ordered). That said though, an educated guess could be used based an number of tests from others over time, where the tester corrects the location. Similar to guessing an ex directory telephone number from the addresses telephone numbers around the ex directory address
Mobile devices with gps are excluded from above, as they could use gps and not geolocation ip
Many thanks
John
-
I see your point about head offices. That doesn't apply in this particular case but certainly helps to explain a lot.
That just shows how utterly useless the whole thing is though, if they are using bogus data sources such as that. Without actual records that relate to the one particular node in question then they should just say “don't know” and omit one node rather than quoting utter nonsense.
The crazy thing about that case though is that one AA ISP-internal node is in the USA and the others are in England, which is simply nonsense. I can't even begin to understand how they got that nonsense. Interestingly, if you lop the last node off the end of that traceroute, that is, you traceroute to the n-1 th node then the whole path comes out completely different, and without that bug.
-
Indeed https://whois.arin.net/rest/net/NET-204-68-252-0-1/pft?s=204.68.252.151
-
Hi
Geolocation is getting better, but will never be perfect. Companies are building huge datasets of IP location, and some even mapping using satelite GPS to home routers (which becomes street level, perhaps even house level). Again, take it with a pinch a salt if fully correct. Google could use/are using their street view.
To answer the question over why USA on that IP, a whois of the IP shows USA
Many thanks
John
Contact Information
RegistrantAGIS
2450 N Street NW
DC
Administrative ContactCogent Communications
Technical ContactIP Allocation
Detailed WHOIS Response
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/whois_reporting/index.html
#
#
# Query terms are ambiguous. The query is assumed to be:
# "n 204.68.252.151"
#
# Use "?" to get help.
#
NetRange: 204.68.252.0 - 204.68.252.255
CIDR: 204.68.252.0/24
NetName: COGENT-204-68-252-24
NetHandle: NET-204-68-252-0-1
Parent: NET204 (NET-204-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS174
Organization: AGIS (AGIS)
RegDate: 1994-08-25
Updated: 2011-05-27
Ref: https://whois.arin.net/rest/net/NET-204-68-252-0-1
OrgName: AGIS
OrgId: AGIS
Address: 2450 N Street NW
City: Washington
StateProv: DC
PostalCode: 20037
Country: US
RegDate: 1994-08-25
Updated: 2015-06-04
Ref: https://whois.arin.net/rest/org/AGIS
OrgTechHandle: IPALL-ARIN
OrgTechName: IP Allocation
OrgTechPhone: +1-877-875-4311
OrgTechEmail: ipalloc@cogentco.com
OrgTechRef: https://whois.arin.net/rest/poc/IPALL-ARIN
OrgAbuseHandle: COGEN-ARIN
OrgAbuseName: Cogent Abuse
OrgAbusePhone: +1-877-875-4311
OrgAbuseEmail: abuse@cogentco.com
OrgAbuseRef: https://whois.arin.net/rest/poc/COGEN-ARIN
OrgNOCHandle: ZC108-ARIN
OrgNOCName: Cogent Communications
OrgNOCPhone: +1-877-875-4311
OrgNOCEmail: noc@cogentco.com
OrgNOCRef: https://whois.arin.net/rest/poc/ZC108-ARIN
RTechHandle: IPALL-ARIN
RTechName: IP Allocation
RTechPhone: +1-877-875-4311
RTechEmail: ipalloc@cogentco.com
RTechRef: https://whois.arin.net/rest/poc/IPALL-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/whois_reporting/index.html
#
-
I was seeing a domain name listed on that row that had something.aimless.aa.net.uk but when I look up that domain name in the DNS it has a different IPv4 address, not one that is 208.xx.yy.zz. So it just seems to be full of bugs. It's like they have got the various lines mixed up, and the d2d4j’s insight explains the rest.
They really are a complete shower. So the likes of google and apple have the good data based on wlan sniffing plus GPS and on the other hand some of these other database providers have the fake garbage for sale.
-
Hi
Sorry it’s early and not had enough coffee yet but it could be their POP I suppose
More likely they have a range from the AS
Many thanks
John
-
Sorry, posts crossed over. I edited mine when I should have made an additional post.
-
LookupServerv2 531ms
1 a.in-addr-servers.arpa 199.180.182.53 NON-AUTH 62 ms Received 6 Referrals , rcode=NO_ERROR 204.in-addr.arpa. 86400 IN NS x.arin.net,204.in-addr.arpa. 86400 IN NS r.arin.net,204.in-addr.arpa. 86400 IN NS z.arin.net,204.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net,204.in-addr.arpa. 86400 IN NS y.arin.net,204.in-addr.arpa. 86400 IN NS u.arin.net,
2 z.arin.net 199.212.0.63 NON-AUTH 0 ms Received 2 Referrals , rcode=NO_ERROR 252.68.204.in-addr.arpa. 86400 IN NS auth1.dns.cogentco.com,252.68.204.in-addr.arpa. 86400 IN NS auth2.dns.cogentco.com,
3 auth2.dns.cogentco.com 66.28.0.30 AUTH 62 ms Received 1 Answers , rcode=NO_ERROR 151.252.68.204.in-addr.arpa. 43200 IN PTR j.aimless.aa.net.uk,
B. PRIMARY DNS SERVICE
1. Do you want Cogent to perform Primary DNS Hosting for a domain for you?
[ ] Yes [ ] No
1a. If Yes, please write the domain here.
Please attach a copy of the explicit records to create, preferably a
zone transfer from your existing provider with any IP changes noted.
You will also need to change the DNS servers with your Domain Registrar
to point to the following DNS servers before we can answer DNS queries.
AUTH1.DNS.COGENTCO.COM and AUTH2.DNS.COGENTCO.COM
It makes sense the traceroute went through there, nothing to worry about as your actual IP is correctly registered.
-
Hi weaver
Without confusing things further, there is also some geodns and georoutimg, so it maybe correct depending upon what’s used and from where the originator is.
Also, don’t forget about preferred/preference routes, route loading (how congested pipes are) etc...
So you may want to tone down stating it’s bad because a lot of this information is hidden. It’s just not perfect that’s all
Many thanks and sorry if I have upset you, I did not mean to, it’s just a big bear where people go immediately to its bad
John
-
When tracerouting 81.187.147.197 from Israel, it doesn't route through US/cogentco. On Sweden/Germany, it is.
https://www.ip2location.com/free/traceroute
1 182.54.236.1 beseq-gateway.gplhost.com Israel, Tel Aviv
0.778 ms
2 82.80.248.254 bzq-82-80-248-254.dcenter.bezeqint.net Israel, HaMerkaz, Petah Tikva
66.734 ms
3 81.218.2.198 bzq-218-2-198.cablep.bezeqint.net Israel, HaMerkaz, Petah Tikva
0.736 ms
4 62.219.189.157 bzq-219-189-157.dsl.bezeqint.net Israel, HaMerkaz, Petah Tikva
51.439 ms
5 212.179.124.153 bzq-179-124-153.cust.bezeqint.net Israel, HaMerkaz, Petah Tikva
48.450 ms
6 46.33.89.237 ae8.cr1-fra2.ip4.gtt.net France, Ile-de-France, Paris
69.109 ms
7 89.149.135.122 xe-9-1-4.cr3-fra2.ip4.gtt.net Germany, Rheinland-Pfalz, Isenburg
68.207 ms
8 46.33.89.237 ae8.cr1-fra2.ip4.gtt.net France, Ile-de-France, Paris
66.679 ms
9 130.117.14.85 be3027.agr41.fra03.atlas.cogentco.com Germany, Hessen, Frankfurt am Main
58.013 ms
10 130.117.1.118 be3187.ccr42.fra03.atlas.cogentco.com Germany, Hessen, Frankfurt am Main
49.531 ms
11 130.117.0.121 be2813.ccr41.ams03.atlas.cogentco.com Netherlands, Noord-Holland, Amsterdam
62.550 ms
12 154.54.57.162 be2869.ccr22.lon01.atlas.cogentco.com United Kingdom, England, London
72.108 ms
13 130.117.51.41 be12488.ccr42.lon13.atlas.cogentco.com United Kingdom, England, London
64.322 ms
14 154.54.57.162 be2869.ccr22.lon01.atlas.cogentco.com United Kingdom, England, London
71.873 ms
15 90.155.53.216 216.53.155.90.in-addr.arpa United Kingdom, England, Bracknell
60.540 ms
16 81.187.13.90 wan.router.torr-gorm United Kingdom, England
95.793 m
1 46.101.128.253 46.101.128.253 Germany, Hessen, Frankfurt am Main
6.594 ms
2 138.197.250.146 138.197.250.146 Poland, Mazowieckie, Warsaw
6.279 ms
3 168.143.229.121 ce-0-8-0-3.r04.frnkge08.de.bb.gin.ntt.net Germany, Hessen, Frankfurt am Main
6.209 ms
4 129.250.3.217 ae-24.r24.frnkge08.de.bb.gin.ntt.net Germany, Hessen, Frankfurt am Main
6.213 ms
5 129.250.3.12 ae-5.r24.londen12.uk.bb.gin.ntt.net United Kingdom, England, London
19.147 ms
6 129.250.4.141 ae-1.r04.londen05.uk.bb.gin.ntt.net United Kingdom, England, London
17.426 ms
7 192.80.17.254 m.aimless.aa.net.uk United States, California, Los Angeles
15.096 ms
8 90.155.53.216 216.53.155.90.in-addr.arpa United Kingdom, England, Bracknell
14.584 ms
9 81.187.13.90 wan.router.torr-gorm United Kingdom, England
47.765 m
1 178.73.210.1 1-210-73-178.static.edis.at Sweden, Stockholms lan, Stockholm
0.346 ms
2 80.67.4.192 be4.cr1.sto1.se.portlane.net Sweden, Stockholms lan, Stockholm
0.752 ms
3 80.67.4.208 be-1.cr1.sto2.se.portlane.net Sweden, Stockholms lan, Stockholm
1.678 ms
4 83.231.187.161 83.231.187.161 United States, Virginia, Ashburn
0.757 ms
5 129.250.2.85 ae-1.r00.stocse02.se.bb.gin.ntt.net Sweden, Stockholms lan, Stockholm
30.694 ms
6 129.250.2.34 ae-25.r24.frnkge08.de.bb.gin.ntt.net Netherlands, Noord-Holland, Amsterdam
19.356 ms
7 129.250.3.12 ae-5.r24.londen12.uk.bb.gin.ntt.net United Kingdom, England, London
32.686 ms
8 129.250.4.24 ae-21.r00.londen10.uk.bb.gin.ntt.net United Kingdom, England, London
33.800 ms
9 192.80.17.250 e.aimless.aa.net.uk United States, California, Los Angeles
29.504 ms
10 90.155.53.216 216.53.155.90.in-addr.arpa United Kingdom, England, Bracknell
36.001 ms
11 81.187.13.90 wan.router.torr-gorm United Kingdom, England
65.499 ms
Edit: Indeed, this is bad routing from Germany, among others.
Results
Host tested: 81.187.147.197
Test performed from: Munich, Germany
Test performed at: 2018-06-24 11:20:57 (GMT +00:00)
PING 81.187.147.197 (81.187.147.197) 56(84) bytes of data.
64 bytes from 81.187.147.197: icmp_seq=1 ttl=58 time=88.7 ms
64 bytes from 81.187.147.197: icmp_seq=2 ttl=58 time=111 ms
64 bytes from 81.187.147.197: icmp_seq=3 ttl=58 time=132 ms
64 bytes from 81.187.147.197: icmp_seq=4 ttl=58 time=158 ms
64 bytes from 81.187.147.197: icmp_seq=5 ttl=58 time=76.8 ms
--- 81.187.147.197 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4079ms
rtt min/avg/max/mdev = 76.834/113.479/158.498/29.448 ms
-
Hi spring
I hope you don’t mind but you may want to edit your post to remove weaver details
Many thanks
John
-
Is this "routing issue" entry this month of any relevance?
https://aastatus.net/posts.cgi?itype=Broadband
-
Hi spring
I am not an AA customer but I think that report is on DSL TT only and not routing to AA systems from external to their networks from another AS/Datacentre
Sorry if I am wrong
Many thanks
John
-
https://aastatus.net/2501
Anyway, it's clearly AA's fault at this part xd
8 129.250.4.24 ae-21.r00.londen10.uk.bb.gin.ntt.net United Kingdom, England, London
33.800 ms
9 192.80.17.250 e.aimless.aa.net.uk United States, California, Los Angeles
29.504 ms
Details for 192.80.17.250
IP: 192.80.17.250
Decimal: 3226472954
Hostname: e.aimless.aa.net.uk
ASN: 2914
ISP: NTT America
Organization: NTT America
Services: None detected
Type: Broadband
Assignment: Static IP
Blacklist:
Continent: North America
Country: United States us flag
State/Region: Colorado
City: Englewood
Latitude: 39.6237 (39° 37′ 25.32″ N)
Longitude: -104.8738 (104° 52′ 25.68″ W)
Postal Code: 80111
https://us.ntt.net/about/network-map.cfm
Edit: Why is the latency fine at aimless.aa.co.uk, but higher to the actual home connection? Well, think I'll leave it alone now :D
Edit2: Some of the aimless domains are NTT's , those ones show USA location because they are registered so, not because they are located there. So the routing does not deviate, it just seems so when trying to geolocate. So there are no issues at all, of zero importance, but one thing to complain about is that there's higher latency on the last hop [to the home connection] by a consistent 30ms [I don't know if this is right: but it's not a good thing].
15 90.155.53.216 216.53.155.90.in-addr.arpa United Kingdom, England, Bracknell
60.540 ms
16 81.187.13.90 wan.router.torr-gorm United Kingdom, England
95.793 m
-
@d2d4j you made a good point - and shed some light on what is going on. I stand by my opinion that what might be 'correct' according to some criterion, in the sense that it is logical, turns out to be not at all useful. If you want to know where a server or a router is, then reporting some data based on the location of some head office of whoever owns it, possibly in a different continent simply is not useful and indeed invalidates and pollutes the whole thing. There was also a straight bug, I know realise, because they were showing me an ip address on the same row as a domain name that was nothing to do with it at all, looks like an off-by-one error. I think I was rather naive in that I never realised just how bad some of these things are.
Oh and I wasn't attempting to comment on the routing. It is what it is. However it happens to get routed is a complex issue, just as you said, but is of no concern to me here. You are surely correct though in that the Atlanta thing is most likely a red herring.
As mentioned iirc in an earlier thread these services all get very upset by "Andrews and Arnold" or 'Andrews & Arnold" maybe the latter because of the "&" or the white space, but many services go completely crazy and draw a point on the map at a village called Arnold in Nottinghamshire, would you believe. So that kind of data is just junk.
-
I sent them a very polite email and got a very helpful reply saying that they would fix it in a release at the end of the month. I just sent them a correction email now because I have since realised about the off-by-one error in the traceroute website code, which gave a domain name and it address pair that did not match, because they were getting rows/steps of the traceroute wrong, with an off-by one error somehow.