[deanhills]

@deanhills

Another (new) note about the IP address(es) geolocation. Based on my previous post and what @fChk also mentioned I think that the IP address is geolocated correctly (actually) because the tunnel endpoint of this protected IP address space (your VPS IP) is at the Las Vegas, Nevada location / data center. You see this being even confirmed by the fact that the first hop from the traceroute is another IP address out of Las Vegas, Nevada. You also see that for some reason the traffic goes back to Phoenix, Arizona and from there on it goes its normal route.

Thanks @"Hidden Refuge".  I understood this from your explanation yesterday, but even better now.

(It wasn't necessary to censor any other IP address than the first hop and the last hop. Everything in between are core routers and exchanges at data centers.)

 Thanks for that valuable tip.  I'm always unsure what to censor, now have a better understanding.

1st hop is most likely the core router or similar in Las Vegas going to 2nd hop in Phoenix at Serverhub (data center) where it is passing another Serverhub Phoenix router (hop 3) and then going to a local Phoenix bandwidth exchange hosted by Telia.net (hop 4). From there on it continues further through the US and etc over Germany (hop 9 through 13) before it seems to reach South Africa and continues there (hop 15).

So in light of their tunnel to protect the VPSs from attacks it rather seems to be correct that the IP space is geolocated to Las Vegas, Nevada as all their tunnels seem to end there and from there they get their Internet connection. Hence why Virmach keeps and will keep insisting and saying not to worry about the location. So why sites detect different locations still stays mostly like I said before: due to geolocation databases being inaccurate and / or multiple databases being used at different times and checks.

Thanks HR, I understand this now.  Also, that although the new IP given to me resembles the German IP numbering, if one checks Virmach has registered it correctly as from the US.  

Another note about the traceroute as you mentioned it. The initator IP of the traceroute (your VPS) will never appear in the traceroute path. A traceroute always starts with the first hop that your machine reaches when it communicates with a network. That is usually the first router or a firewall. That is the 107.* IP address in Las Vegas, Nevada. So you will never see the IP address of the machine from where you started a traceroute or ping from unless you capture the network packets and analyze them (with Wireshark for example).

 That's interesting, as yesterday when I experimented with VPS 9 Dallas just for comparison, the traceroute started with the IP for the VPS - Dallas IP - or it had the appearance of it.  I.e. the IP for Dallas is 23.**.75.34 and the first IP in the Dallas traceroute then was exactly the same except for the .34 was .33.  

BTW.  Dallas has the exact same issues as VPS 9 Phoenix.  CentOS 6.5 works OK.  CentOS 7.0 has issues.  I don't know whether you would like to have a look at VPS 9 Dallas.  It's not occupied presently.  Let me know if you are game to test it, goal of which would be to compose a ticket to Virmach but giving them technical details that will help them to help fix the problem.

Priority issues would be problems with OS - not having Ubuntu available, and not having an up to date CentOS.  Possibly you could be more analytical with proper IT speak that the technicians at Virmach would be able to understand.  If and when you have time available.

About the speed tests. You could use speedtest.net still if you really wanted but don't let it auto pick the location but rather pick a location in Arizona or around it manually. Additional speed tests you can do easily with for example the benchmark scripts. The speed tests there do basically the same as speedtest.net by downloading a big file and measuring the speed (no upload speed here though). As I explained before maybe a much more proper test would be a iperf test to a iperf server near to the VPS location.

There are a few public iperf3 servers available:
- https://iperf.cc/ (Multiple locations)
- https://speedtest.serverius.net/ (Netherlands)
- https://iperf.fr/iperf-servers.php (France)
- http://iperf.volia.net/ (Ukraine)

For example at https://speedtest.serverius.net/ you have instructions to perform a download and upload speed test using iperf3 to the Serverius iperf server. This server is hosted in the Netherlands though.

You could use the Fremont, CA server from https://iperf.cc/ for a test because that seems to be the closest server to your VPS location.

Download:

Code: (Select All)

iperf3 -c iperf.scottlinux.com -p 5002 -P 10 -4 -R

Upload:

Code: (Select All)

iperf3 -c iperf.scottlinux.com -p 5002 -P 10 -4

^ You have to install iperf3 on your VPS first before you can run these commands.

Alternatively you can of course even host your own iperf server and test your VPS against it for example.

Thank you very much for this suggestion.  I did something yesterday along these lines for both VPS 9 Dallas and Phoenix to compare the two.  The speedtest.net showed great results for Dallas compared with Phoenix, but then when I did a Benchmark summary of both, I'd say they're more or less the same speed - relative to their geolocation.