Recent lag issues and the tech-support incompetence

[Hustensaft]

There are and have been several lag reports in the technical support forum the past few days/weeks.

The tech support copy paste it's usual answers (check your wifi/settings), if that doesn't resolve the issues, the problem is defaulted to your ISP, and moved to the closed section.

Currently active threads include:
http://forum.square-enix.com/ffxiv/t...-LAG-since-wed
http://forum.square-enix.com/ffxiv/t...as-fine-before.
http://forum.square-enix.com/ffxiv/t...nt-disconnects

Closed threads include:
http://forum.square-enix.com/ffxiv/t...-the-new-patch.
http://forum.square-enix.com/ffxiv/t...erver-problems

Closing practically any connection issue thread with "talk to your ISP" is absolutely horrendous customer supoort and total incompetence.

[Valkyrie_Lenneth]

In this case though, it's not the servers. There isn't much SE can do to help you troubleshoot a thing that isn't on their end specifically.

[Macleod]

Neither I, nor anyone I know in game, has complained about experiencing any lag lately. I don't know a lot about networking stuff, but I'd say, if it's not affecting everyone, it's not their servers. /shrug So, what are they supposed to do about it exactly?

[Xtrasweettea]

http://forum.square-enix.com/ffxiv/t...erver-problems

Hi, ISP shill here.

The SE admin literally tells everyone they can only provide support for user end devices and user end network settings (ie: your settings on devices you own and manage).

It is not incompetence, as much as you accuse them of. They cannot troubleshoot network problems they have no control over.

If you look through the posts from those you will see traceroutes. There's always one or two IP addresses with lag spikes. Those IP addresses are part of the network within the general network backbone. Those routers are owned by network carriers, not by SE.

I don't know how people imagine they are connecting to SE servers. It is not a straight connection from your CPE to their CPE. It is your CPE connecting to different routers along a path to eventually the last network router to SE's CPE. How your ISP has set up your routing dictates where to go from your CPE to SE's CPE.

The only way to solve this is to get the ISPs involved and have them fix the issue. You could always band-aid this by using a VPN and troubleshoot each VPN connection until you find one that circumvents that router.

Again, SE has no control over this. This is a ISP cause problem.

[Hustensaft]

If you look through the posts from those you will see traceroutes. There's always one or two IP addresses with lag spikes. Those IP addresses are part of the network within the general network backbone. Those routers are owned by network carriers, not by SE.

Yes, and if you check some of the traceroutes, you'll notice that the IP ranges were the errors occurs are owned by KDDI - which is SE's european data center provider.

I can't talk to them, neither can my ISP, yet i'm being told to talk to them. Brilliant solution.

Connection issues can happen on ISP side, and SE's side. So you're telling me, that there is practically noone capable and or responsible for possible connections issues that happen on SE's sde? Noted.

Neither I, nor anyone I know in game, has complained about experiencing any lag lately. I don't know a lot about networking stuff, but I'd say, if it's not affecting everyone, it's not their servers. /shrug So, what are they supposed to do about it exactly?

Because obviously, those thread exists for nothing.

[Xtrasweettea]

Yes, and if you check some of the traceroutes, you'll notice that the IP ranged were the errors occurs are owned by KDDI - which is SE's european data center provider. No EU customer can do anything with that, as it's not their ISP - it's SE's data center provider.

KDDI is the carrier and owner of that particular router along the backbone. 195.82.50.234, in particular is the one causing the lag spike. IP address 195.82.50.60 is to be the assumed CPE for SE. I am going to assume KDDI owns the transport for that IP address.

If SE rents the data center, they probably don't have a contract between KDDI and themselves. KDDI and the Data Center has a contract between each other in regards to at least WAN. This isn't that uncommon in the world of ISPs. SE and the data center may have a contract that outlines some network performance SLAs.

SE more-than-likely cannot do anything about this. They can talk to the data center owners to see if something can get done, but more-than-likely, the data center owners won't do anything unless it breaks contract or violates any SLAs.

I am going to assume that this is the last hop router since I am from the USA and I also got that router:

1 <1 ms <1 ms <1 ms Gateway [192.168.1.1]
2 10 ms 14 ms 9 ms static-24-214-21-1.knology.net [24.214.21.1]
3 16 ms 22 ms 9 ms 69.73.1.1
4 11 ms 13 ms 22 ms user-24-96-198-97.knology.net [24.96.198.97]
5 13 ms 10 ms 11 ms static-216-186-180-250.knology.net [216.186.180.250]
6 25 ms 21 ms 18 ms 143.59.255.198
7 61 ms 19 ms 19 ms dynamic-75-76-35-117.knology.net [75.76.35.117]
8 * * * Request timed out.
9 29 ms 31 ms 28 ms ash-bb3-link.telia.net [62.115.125.190]
10 110 ms 102 ms 104 ms prs-bb4-link.telia.net [62.115.122.158]
11 119 ms 113 ms 114 ms ffm-bb2-link.telia.net [62.115.122.139]
12 113 ms 110 ms 120 ms ffm-b1-link.telia.net [62.115.137.169]
13 116 ms 121 ms 123 ms kddi-ic-319844-ffm-b1.c.telia.net [62.115.32.106]
14 112 ms 120 ms 111 ms 195.82.61.14
15 129 ms 121 ms 117 ms 195.82.50.234 [LAST HOP ROUTER]
16 118 ms 120 ms 116 ms 195.82.50.60

Though I don't have a huge lag spike when I hit that router. 129 ms is close to industry standard from East Coast USA to Europe. There may be a specific port within the last hop router that is causing the problem.

Regardless, SE cannot do anything about that. Your ISP has to talk to the carrier who owns that router to troubleshoot that particular router and perform a repair. It is still not SE's problem.

[Hustensaft]

KDDI is the carrier and owner of that particular router along the backbone. 195.82.50.234, in particular is the one causing the lag spike. IP address 195.82.50.60 is to be the assumed CPE for SE. I am going to assume KDDI owns the transport for that IP address.

The .234 node "belongs" to SE

inetnum: 195.82.50.0 - 195.82.50.255
netname: Square-ENIX
country: DE

and the one before:

inetnum: 195.82.61.12 - 195.82.61.15
netname: KDDI-Square_ENIX

The problems are also pretty much mostly during primetime, which starts in an hour or so for EU people (might be a load balancing issue).

[Xtrasweettea]

The .234 node "belongs" to SE( or KDDI)

inetnum: 195.82.50.0 - 195.82.50.255
netname: Square-ENIX
country: DE
admin-c: MA1211
tech-c: MA1211
status: ASSIGNED PA
mnt-by: AS8375-MNT
created: 1970-01-01T00:00:00Z
last-modified: 2017-05-31T08:25:28Z
source: RIPE

The problems are also pretty much mostly during primetime, which starts in an hour or so for EU people.

192.82.50.60, the IP address I used, falls within the of range within the inetnum.

In good faith, I traceroute 195.82.50.01 and got timed out before I could get to the last hop router:
1 <1 ms <1 ms <1 ms Gateway [192.168.1.1]
2 12 ms 9 ms 22 ms static-24-214-21-1.knology.net [24.214.21.1]
3 11 ms 10 ms 10 ms 69.73.1.1
4 11 ms 11 ms 10 ms user-24-96-198-97.knology.net [24.96.198.97]
5 9 ms 11 ms 10 ms static-216-186-180-250.knology.net [216.186.180.250]
6 18 ms 19 ms 19 ms 143.59.255.198
7 27 ms 19 ms 19 ms dynamic-75-76-35-117.knology.net [75.76.35.117]
8 * * * Request timed out.
9 29 ms 31 ms 30 ms ash-bb2-link.telia.net [62.115.125.129]
10 117 ms 116 ms 119 ms prs-bb3-link.telia.net [62.115.112.243]
11 * 126 ms * ffm-bb1-link.telia.net [62.115.123.12]
12 129 ms 127 ms 139 ms ffm-b1-link.telia.net [62.115.141.237]
13 119 ms 120 ms 121 ms kddi-ic-319844-ffm-b1.c.telia.net [62.115.32.106]
14 124 ms 118 ms 119 ms 195.82.61.14
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.


I then did 192.82.50.60 again and got timed out before I could hit the last-hop router.

So, the problem is the last hop router. Though, I am still having trouble as to seeing how this is SE's problem SE doesn't own nor manage the last hop router. They have "ownership" (or at least contractual partnership) with 192.82.50.0 - 255 ranges. SE is only at fault for what they contractually own or manage.

Call your ISP, send a report so the ISPs can fight it out. I am sure this is causing problems to thousands of people and businesses.

[Xtrasweettea]

The .234 node "belongs" to SE

inetnum: 195.82.50.0 - 195.82.50.255
netname: Square-ENIX
country: DE

and the one before:

inetnum: 195.82.61.12 - 195.82.61.15
netname: KDDI-Square_ENIX

The problems are also pretty much mostly during primetime, which starts in an hour or so for EU people (might be a load balancing issue).

The two "nodes" you gave me are two routers. One is a main router and the other is a backup router.

Almost all datacenters are set up with a dual router with dual access setup with fail-over. Sometimes both backup and main routers are live and perform load balancing. It counts on how SE had set up their WAN connection with the carrier.

If we were experience lag spikes at SE's end, we would see it from one of those two ip ranges from those routers.

[Jimmymagic]

Hi, ISP shill here.

The SE admin literally tells everyone they can only provide support for user end devices and user end network settings (ie: your settings on devices you own and manage).

It is not incompetence, as much as you accuse them of. They cannot troubleshoot network problems they have no control over. .



If you look through the posts from those you will see traceroutes. There's always one or two IP addresses with lag spikes. Those IP addresses are part of the network within the general network backbone. Those routers are owned by network carriers, not by SE.

I don't know how people imagine they are connecting to SE servers. It is not a straight connection from your CPE to their CPE. It is your CPE connecting to different routers along a path to eventually the last network router to SE's CPE. How your ISP has set up your routing dictates where to go from your CPE to SE's CPE.

The only way to solve this is to get the ISPs involved and have them fix the issue. You could always band-aid this by using a VPN and troubleshoot each VPN connection until you find one that circumvents that router.

Again, SE has no control over this. This is a ISP cause problem.

literally this! I too at first accused SE servers being messed up but after investigating and being educated SE really cant do anything. The router issues can only be resolve so many ways and the one that is currently with me is to hard reset my router and clear the addresses from storage and voila my connection was great until it filled up again.