Quote:
Originally Posted by Wisteso
[You must be logged in to view images. Log in or Register.]
Yep, h4tch. Thats exactly how I got around the issue when it was happening for me (till it was fixed). I used NordVPN and found a route that went around the XO Communications till it was fixed. Even with the VPN, you'll still probably have a little packet loss (its almost always there in minor amounts). Timeouts with traceroute/ping are totally normal (even for a healthy connection)
And yes 66.55.145.2 is basically the IP of the server (its technicallya shared IP for several servers, but.. yes essentially)
Both "bad" traceroutes that have been posted so far have been going through gtt.net while your "good" route does not. My guess is that gtt.net is the issue but we'll need more data to be more sure... Further, my connection does not route through gtt.net and I have consequently had no issues.
|
That makes sense, and gtt looks like maybe a cdn, or cloud service of some type. I think maybe they are messing with the mtu as well. It worked for me on 1472, but now it's 1462. So I'll edit my other post to say 1480 should work.
Here is what I see when I run a ping test.
C:\Users\Winterfell>ping 66.55.145.2 -f -l 1463
Pinging 66.55.145.2 with 1463 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 66.55.145.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\Winterfell>ping 66.55.145.2 -f -l 1462
Pinging 66.55.145.2 with 1462 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 66.55.145.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),