Tracert showing failures at hops 12-15 en route to Final Fantasy XIV server. Can't log in or play without error.

RoryM

Honorable
Feb 7, 2014
3
0
10,510
Hi there,

I am a Time Warner Cable customer in upstate new york. For about a year, I used the "turbo" package (guaranteed 20mb down), and connected to the wireless network via a Netgear WNDA 3100 adapter. I recently moved into a new apartment where the internet is provided by the landlord. The ISP in this case is also Time Warner, but instead of the "turbo" package, the landlord has the "ultimate" package, which is one or two tiers of speed higher than my former package. I am still connecting to the internet wirelessly, with the same desktop computer and same netgear adapter. Here is the problem I'm running into:

When I open Final Fantasy XIV: A Realm Reborn, I am able to log in via the game launcher, and apply patches if necessary. However once I reach the title screen of the game, pressing "Start Game" (which would normally connect me to the north american datacenter) times me out, giving me an "error 2002," meaning that I could not connect to the datacenter. On the rare occasion that I am able to reach the character select screen, I am only able to get in the game proper for 1-3 minutes before getting a severe lag spike followed by a disconnect (error 90000, or "lost connection with game server).

The game server I am trying to connect to is as follows (via arrstatus.com): 199.91.189.40. I see the same failures at hops 12-14 no matter which North American server I connect to (they all belong to the 199.91.189.X series). I am able to ping/traceroute other websites with no issues whatsoever, and I do not lose connectivity during the FFXIV disconnects, leading me to believe that it is a problem specifically relating to the game.

The conclusion that I have drawn is that the failing hops are what are causing the disconnects, and the reason I am only getting them now, after having moved, is because the "Ultimate" package servers originate in NYC, and the "turbo" package servers originate in Albany. So the Albany--> Montreal route, while part of a slower package, had no "roadblocks" in it, unlike the faster NYC--> Montreal route.

The one thing I do not understand is, if the problem is out of my control and has to do with the route I am taking, why then does using a VPN tunneling service (in my case, WTFast) not fix the problem? I will boot FFXIV using WTFast and continue to get the errors upon trying to enter the game. I thought maybe one of the proxy servers used by the service was down, but after having tried Montreal servers 1&2, Boston servers 1&2, and a NYC server, I continue to have the disconnection problem.

Here is the tracert that I ran on the game server (again, if you want more IPs for game servers, I got it from arrstatus.com):

1 2 ms 1 ms 2 ms 192.168.0.1
2 29 ms 28 ms 29 ms 24.92.40.1
3 13 ms 20 ms 21 ms 24.29.42.233
4 16 ms 19 ms 30 ms 74.76.241.40
5 25 ms 35 ms 26 ms 74.76.241.193
6 30 ms 25 ms 28 ms 66.109.6.74
7 31 ms 28 ms 24 ms 107.14.17.169
8 36 ms 46 ms 37 ms 4.68.63.21
9 42 ms 45 ms 51 ms 4.69.156.30
10 45 ms 44 ms 43 ms 4.69.132.97
11 45 ms 50 ms 44 ms 4.69.141.5
12 32 ms 44 ms * 4.69.141.1
13 50 ms 44 ms 51 ms 4.59.178.74
14 51 ms 50 ms 57 ms 192.34.76.10
15 47 ms 52 ms 53 ms 199.91.189.242
16 54 ms 51 ms 56 ms 199.91.189.40

As you can see the problem is at hop 12. Other times it will be hops 13 or 14; others still will have no problems connecting at all. The only thign that remains consistent is that it's that same 12-14 range every time with the problems.

Any thoughts? If I understand things correctly I cannot "fix" this problem, so to speak, but perhaps there is some way around the faulty node, if that is indeed the problem? I would also like to know why the VPN tunneling service does not fix the issue. Thanks.
 
Solution
Some ISP let you run traceroute from their routers ...generically this is called looking glass.

So from the level 3 site I told it to traceroute from their new york router to that ip.

Traceroute results from New York, NY
to 199.91.189.40(199.91.189.40)

1 vlan80.csw3.NewYork1.Level3.net (4.69.155.190) 40 msec
vlan70.csw2.NewYork1.Level3.net (4.69.155.126) 12 msec
vlan60.csw1.NewYork1.Level3.net (4.69.155.62) 12 msec
2 ae-92-92.ebr2.NewYork1.Level3.net (4.69.148.45) 20 msec
ae-82-82.ebr2.NewYork1.Level3.net (4.69.148.41) 24 msec
ae-72-72.ebr2.NewYork1.Level3.net (4.69.148.37) 20 msec
3 ae-5-5.car1.Montreal2.Level3.net (4.69.141.5) 168 msec 148 msec 280 msec
4 *
ae-11-11.car2.Montreal2.Level3.net...
You are misinterpreting how traceroute works.

If you were to see problems in everything past say hop 12 to 16 you could say there was a problem starting at hop 12. Lets say hop 12 was dropping all the traffic how could traffic ever even get to hop 16. So if you see errors in hop 12 but not in hop 16 then it doesn't really matter since end to end traffic works.

The reason you see this is these device are configure to favor forwarding actual user traffic than responding to your traceroute commands.

Still lets assume there is some huge problem at that hop 12. That is in the network owned by level3. Even if you were to find a phone number to call level3 you are not their customer so they would refuse to talk to you.

Its hard to say what your problem is but this trace very clearly shows you do not have any network problems.
 

RoryM

Honorable
Feb 7, 2014
3
0
10,510
thank you for the timely response and correction. as you said, it's tough -- at least for me -- to figure out exactly what the problem is, but I am willing to provide any information necessary to help diagnose the issue. since the end-to-end connection remains intact, and the VPN does not make a difference, I am thoroughly confused about what could be causing the errors and disconnects if the hop in question is indeed part of the problem. my thinking w/r/t the VPN is that perhaps the servers I have chosen with the program continue to pass through that hop on their way to the game server, although it would be a strange coincidence if five separate servers were all coming into contact with that hop.

I have signed up for my own cable package, and have picked up my own modem from the local time warner office. I will soon be hard wired separately from the building wifi -- and back to the turbo package rather than the ultimate, which TWC confirmed to me each originate from different server banks -- so with any luck I will get around the issue. However even if I am able to resolve the problem in that way I'm still curious about what is causing the connection to fail to the FFXIV server specifically.
 
Some ISP let you run traceroute from their routers ...generically this is called looking glass.

So from the level 3 site I told it to traceroute from their new york router to that ip.

Traceroute results from New York, NY
to 199.91.189.40(199.91.189.40)

1 vlan80.csw3.NewYork1.Level3.net (4.69.155.190) 40 msec
vlan70.csw2.NewYork1.Level3.net (4.69.155.126) 12 msec
vlan60.csw1.NewYork1.Level3.net (4.69.155.62) 12 msec
2 ae-92-92.ebr2.NewYork1.Level3.net (4.69.148.45) 20 msec
ae-82-82.ebr2.NewYork1.Level3.net (4.69.148.41) 24 msec
ae-72-72.ebr2.NewYork1.Level3.net (4.69.148.37) 20 msec
3 ae-5-5.car1.Montreal2.Level3.net (4.69.141.5) 168 msec 148 msec 280 msec
4 *
ae-11-11.car2.Montreal2.Level3.net (4.69.141.1) 4 msec 8 msec
5 ORMUCO-COMM.car2.Montreal2.Level3.net (4.59.178.74) 8 msec 8 msec 8 msec
6 192.34.76.10 [AS20324] 8 msec 8 msec 8 msec
7 * * *
8 * * *
9 * * *
10 * * *

I have no clue why it will not trace farther but there may be a firewall. Still this trace shows the same thing yours does 4.69.141.1 and 4.69.141.5 ( i ran it multiple time and only posted one) have some kind of issue.

Still all we know is ae-5-5 router in montreal has some strange issue in level 3 network. The problem though is gone when it enters the next ISP which appears to be BC.net.

Not much a end consumer can do. They might tell us that their router was busy but they would point out that nothing is being dropped past there.

If you ping the 192.34.76.10 continuously you will see there is no loss at all and no delays. This means it passes all the way though level 3 to the next ISP with no issues.



 
Solution