Packet loss confirmed via winMTR (instructions included)

[Shizue]

1) Found IP of server ffxiv.exe was connecting to while logged in to my primary server with netstat:

> Run cmd.exe with admin privileges
> Run the following command: netstat -ab > results.txt & results.txt
(literally this pipes the output of the command line into a file named "results.txt" and then opens the file)

I'm on Balmung. This resulted in the IP 199.91.189.33.

2) Ran traces using winMTR for several minutes while experiencing severe lag (NOTE: never had any lag issues until about 2 nights ago when Balmung went down about 3 hours before the scheduled maintenance). Results:

Trace # 1



Small amounts of packet loss are notable on a few of the hops, but the last 2 hops show significant packet loss. This could possibly be resulting from the packet loss on earlier hops, so I ran a similar trace of a much shorter duration to see where the packet loss becomes evident first. A second trace of similar duration ended up with very similar results.

Short Trace # 1



Here we can see the packet loss starts at 199.91.189.234 and likely trickles over to 199.91.189.33.

Whois results:

[Querying whois.arin.net]
[whois.arin.net]

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#


#
# Query terms are ambiguous. The query is assumed to be:
# "n 199.91.189.234"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=19...se&ext=netref2
#

Ormuco ORMUCO-FIBER-NETWORK (NET-199-91-184-0-1) 199.91.184.0 - 199.91.191.255
Eidos ORMUC-SE (NET-199-91-189-0-1) 199.91.189.0 - 199.91.189.255



#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

Looks like 199.91.189.234 (Ormuco) would be where I'd start poking around. Given the trend we've seen lately, I'd hazard a guess that we've got some overloaded infrastructure or faulty hardware at that hop.

Hopefully SE can start putting this to use in investigating this issue. Others can use the same method to investigate further on their own end as a single tracert isn't enough evidence to see what's going on.

Best of luck to all.

[Ruprect]

192.91.189.234 is most likely on the same subnet as the server, my guess would be it is the default gateway for the server you are pinging and maybe the gateway for all of the NA/EU servers. That would make sense that it would be a huge bottleneck then

[Shizue]

Seems highly plausible. As to the direct cause, it's up to SE or their provider to figure it out from the look of it.

[Appleh4x]

It's a normal side effect of server congestion which SE told me they are experiencing via a support email. I made a topic about it

[VexacionR]

So if we do see a problem on the route to the server how would someone go about altering the route to avoid the problem point? I used this method and tracert against some other known server ip address and I found a common issue with tinet-gw.customer.alter.net but I don't know how I would go about getting around it...:

[Appleh4x]

So if we do see a problem on the route to the server how would someone go about altering the route to avoid the problem point? I used this method and tracert against some other known server ip address and I found a common issue with tinet-gw.customer.alter.net but I don't know how I would go about getting around it...:

Your best bet is to use a VPN, or just wait it out until you are routed through a different node on their end.

[svann]

So if we do see a problem on the route to the server how would someone go about altering the route to avoid the problem point? I used this method and tracert against some other known server ip address and I found a common issue with tinet-gw.customer.alter.net but I don't know how I would go about getting around it...:

The pic you show is not showing a problem. If you have loss on one step and not on following steps then that is meaningless. Think about it. How would you have loss on step 7 but not on step 8, when it has to go through 7 to get to 8? Some servers give low priority to pings and that is likely what you are seeing. The only time you can take a tracert seriously is if 7 is lossy, and they every step after that was also lossy. Then you would know the problem starts at 7.

[KisaiTenshi]

So if we do see a problem on the route to the server how would someone go about altering the route to avoid the problem point? I used this method and tracert against some other known server ip address and I found a common issue with tinet-gw.customer.alter.net but I don't know how I would go about getting around it...:

Doesn't mean anything... case in point:

[Shizue]

Well, seems someone did something on SE's end today. This afternoon I was experiencing severe lag and packet loss on the last 2 hops (as seen in the OP). This evening I had no lag at all during FATEs, dungeons or anything else. No packet loss noted on the last 2 hops at the moment (left winMTR running a trace for a good hour or so).

Ninja fixed?

And Kisai and Svann are both accurate. As long as the destination is receiving all of the packets you are in good shape... also as long as the latency is acceptable as well. There are many reasons why one or more hops may show packet loss but ultimately it's moot if the packets reach the destination.

[Boretalith]

It seems that there have not been any further posts about this concern being an ongoing issue. Because of this, we are considering it to be resolved. If this does continue to be a concern, please create another thread to further discuss resolutions or contact the Support Center at support.na.square-enix.com for assistance.