If I were to put money on it, the issue is between ae-5.a00.dllstx14.us.bb.gin.ntt.net and ae-2.r20.dllstx14.us.bb.gin.ntt.net. I have two internet connections coming in, and on my spectrum line, I do not hit ae-5.a00.dllstx14.us.bb.gin.ntt.net and have not had issues in ~3 weeks. AT&T routing looks like:
Hop 4: 32.130.25.65
Hop 5: ae-5.a00.dllstx14.us.bb.gin.ntt.net
Hop 6: ae-2.r20.dllstx14.us.bb.gin.ntt.net
While spectrum looks like:
Hop 9: as2914.cr11-dal3.ip4.gtt.net
Hop 10: ae-2.r20.dllstx14.us.bb.gin.ntt.net
Hop 11: ae-2.r24.lsanca07.us.bb.gin.ntt.net
-
05-19-2023 12:53 AM #191Player
- Join Date
- Apr 2023
- Posts
- 33
- Character
- Generic Healer
- World
- Midgardsormr
- Main Class
- Scholar Lv 90
(1)
-
05-19-2023 12:58 AM #192Player
- Join Date
- Jul 2019
- Posts
- 1,764
- Character
- Aries Helle
- World
- Excalibur
- Main Class
- Black Mage Lv 100
Here is the first post showing none of those though:
Originally Posted by ntt_routing_is_an_issue
Originally Posted by Krojack
It's happening again. NTT having bad packet loss and lag all within their network. Please get this fixed once and for all.
Current packet loss.
Past 12 hours graphs. Can see when it start about 10:30am EST
Past 2.5 months.
(NTT made a change in early April that caused the average pings to increase by 5-10ms)
Still the only thing I can find in common so far is that people who are having problems are going through a 129.250.4.9 or a 129.250.4.239 address. If anyone can prove this is wrong lmk. You will also see that the known working optimum tracert does not include either of these.
*Update, first packet drop of the day recorded 10:45 AM -11 AM CST*
Reply from 204.2.29.86: bytes=32 time=120ms TTL=50
Reply from 204.2.29.86: bytes=32 time=110ms TTL=50
Reply from 204.2.29.86: bytes=32 time=121ms TTL=50
Reply from 204.2.29.86: bytes=32 time=107ms TTL=50
Reply from 204.2.29.86: bytes=32 time=114ms TTL=50
Reply from 204.2.29.86: bytes=32 time=109ms TTL=50
Reply from 204.2.29.86: bytes=32 time=115ms TTL=50
Reply from 204.2.29.86: bytes=32 time=118ms TTL=50
Reply from 204.2.29.86: bytes=32 time=122ms TTL=50
Reply from 204.2.29.86: bytes=32 time=117ms TTL=50
Reply from 204.2.29.86: bytes=32 time=117ms TTL=50
Reply from 204.2.29.86: bytes=32 time=120ms TTL=50
Reply from 204.2.29.86: bytes=32 time=111ms TTL=50
Request timed out.
Reply from 204.2.29.86: bytes=32 time=113ms TTL=50
Reply from 204.2.29.86: bytes=32 time=121ms TTL=50
Reply from 204.2.29.86: bytes=32 time=117ms TTL=50
Reply from 204.2.29.86: bytes=32 time=104ms TTL=50
Reply from 204.2.29.86: bytes=32 time=112ms TTL=50
Reply from 204.2.29.86: bytes=32 time=113ms TTL=50
Reply from 204.2.29.86: bytes=32 time=115ms TTL=50
Reply from 204.2.29.86: bytes=32 time=115ms TTL=50
Reply from 204.2.29.86: bytes=32 time=121ms TTL=50
Reply from 204.2.29.86: bytes=32 time=119ms TTL=50
Reply from 204.2.29.86: bytes=32 time=113ms TTL=50
Reply from 204.2.29.86: bytes=32 time=108ms TTL=50(1)Last edited by Ath192; 05-19-2023 at 01:03 AM.
-
05-19-2023 01:01 AM #193Player
- Join Date
- Apr 2023
- Posts
- 33
- Character
- Generic Healer
- World
- Midgardsormr
- Main Class
- Scholar Lv 90
Sure, and it's completely plausible that the nodes in my route map have an issue as well as other nodes. My stuff is going through Dallas, the post you linked is going through Chicago. It's an overall NTT issue.
Originally Posted by Ath192
Further, in your quote, they hop from Chicago to San Jose, I hop from Dallas to Los Angeles. The only explanation is that *something* in NTT's network is causing the issue.(3)Last edited by ntt_routing_is_an_issue; 05-19-2023 at 01:08 AM.
-
05-19-2023 01:12 AM #194Player
- Join Date
- Jul 2019
- Posts
- 1,764
- Character
- Aries Helle
- World
- Excalibur
- Main Class
- Black Mage Lv 100
Well I tried to follow up with NTT to press a bit more but this person is at least making it the ISP service's issue.
Originally Posted by ntt_routing_is_an_issue
---------------------------------------------------------------
Hey Victor,
Can you check this out for me if you have time?
In your email:
Your ping test you have a Response time of:
PING 204.2.29.87 (204.2.29.87): 56 data bytes
64 bytes from 204.2.29.87: icmp_seq=0 ttl=57 time=40.044 ms
In my tracert I have a response time of:
11 116 ms 117 ms * ae-5.a01.scrmca03.us.bb.gin.ntt.net [129.250.2.7] <<< The ms increase between Hop 8 and 11 is expected as the traffic traverses the NTT network between Dallas, TX to Sacramento, CA
Isn’t that a little strange that we are both from Texas, and getting vastly different ms response?
Also, I ran two different Tracerts to a hop earlier in the same route and get this:
Tracing route to ae-1.a00.scrmca03.us.bb.gin.ntt.net [129.250.4.76]
over a maximum of 30 hops:
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 29 ms 30 ms 30 ms 32.130.25.67
8 26 ms 30 ms 26 ms ae-5.a00.dllstx14.us.bb.gin.ntt.net [129.250.8.237]
9 * 26 ms 26 ms ae-2.r20.dllstx14.us.bb.gin.ntt.net [129.250.4.9]
10 112 ms 115 ms * ae-2.r24.lsanca07.us.bb.gin.ntt.net [129.250.7.69]
11 141 ms 123 ms 142 ms ae-5.a01.scrmca03.us.bb.gin.ntt.net [129.250.2.7]
12 72 ms 71 ms 73 ms ae-1.a00.scrmca03.us.bb.gin.ntt.net [129.250.4.76]
In the full route, I get this:
Tracing route to 204.2.29.87 over a maximum of 30 hops
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 30 ms 31 ms 31 ms 32.130.25.67
8 31 ms 27 ms 31 ms ae-5.a00.dllstx14.us.bb.gin.ntt.net [129.250.8.237]
9 * * * Request timed out.
10 111 ms * * ae-2.r24.lsanca07.us.bb.gin.ntt.net [129.250.7.69]
11 118 ms 117 ms 118 ms ae-5.a01.scrmca03.us.bb.gin.ntt.net [129.250.2.7]
12 * 175 ms 117 ms ae-1.a00.scrmca03.us.bb.gin.ntt.net [129.250.4.76]
13 119 ms 118 ms 119 ms xe-0-0-5-0.a00.scrmca03.us.ce.gin.ntt.net [128.241.2.18]
14 * * * Request timed out.
15 * 117 ms 117 ms 204.2.29.87
So that doesn’t match the description of the original email where:
8 40 ms 36 ms 30 ms ae-5.a00.dllstx14.us.bb.gin.ntt.net [129.250.8.237] <<< This is the ATT node where the traffic is picked up by NTT
9 * * * Request timed out. <<< This is a node that is not responding to ICMP, does not indicate packet loss or latency
10 * * * Request timed out. <<< This is a node that is not responding to ICMP, does not indicate packet loss or latency
11 116 ms 117 ms * ae-5.a01.scrmca03.us.bb.gin.ntt.net [129.250.2.7] <<< The ms increase between Hop 8 and 11 is expected as the traffic traverses the NTT network between Dallas, TX to Sacramento, CA
12 118 ms 117 ms 116 ms ae-1.a00.scrmca03.us.bb.gin.ntt.net [129.250.4.76] <<< The ms stayed consistent
13 117 ms 119 ms * xe-0-0-5-0.a00.scrmca03.us.ce.gin.ntt.net [128.241.2.18] <<< The ms stayed constsent
It seems like Hops 9 and 10 are:
9 * 26 ms 26 ms ae-2.r20.dllstx14.us.bb.gin.ntt.net [129.250.4.9]
10 112 ms 115 ms * ae-2.r24.lsanca07.us.bb.gin.ntt.net [129.250.7.69]
And yet we can see it cannot always display them reliably. Can you see if there is something strange going on there? Or is this normal behavior?
-----------------------------------------------
Good day,
Per my previous email, I do suggest contacting your upstream provider to determine the reliability issue you are working on.
See inline for response, in red, below:
---
Victor Nadalalicea
Network Analyst, Global IP NOC
Isn’t that a little strange that we are both from Texas, and getting vastly different ms response?
>>> Not strange at all, but more expected. Pings and traceroutes are different in that sense yes. Traceroute calculates how many hops it takes to its destination, and how long each hop takes. With Ping, this app just calculates the time per echo reply responses. Therefore, both numbers will always result in different ms readings. You should never receive the same results in ms.
So that doesn’t match the description of the original email where:
8 40 ms 36 ms 30 ms ae-5.a00.dllstx14.us.bb.gin.ntt.net [129.250.8.237] <<< This is the ATT node where the traffic is picked up by NTT
9 * * * Request timed out. <<< This is a node that is not responding to ICMP, does not indicate packet loss or latency
10 * * * Request timed out. <<< This is a node that is not responding to ICMP, does not indicate packet loss or latency
11 116 ms 117 ms * ae-5.a01.scrmca03.us.bb.gin.ntt.net [129.250.2.7] <<< The ms increase between Hop 8 and 11 is expected as the traffic traverses the NTT network between Dallas, TX to Sacramento, CA
12 118 ms 117 ms 116 ms ae-1.a00.scrmca03.us.bb.gin.ntt.net [129.250.4.76] <<< The ms stayed consistent
13 117 ms 119 ms * xe-0-0-5-0.a00.scrmca03.us.ce.gin.ntt.net [128.241.2.18] <<< The ms stayed constsent
>>> Traceroute to different destination IP addresses, you should expect different paths, because the destination network address is different and depending how the route path algorithms are calculated will determine the path it takes. The above traceroutes to two different destination addresses are expected.
And yet we can see it cannot always display them reliably. Can you see if there is something strange going on there? Or is this normal behavior?
>>> We only have visibility within our network, and I have shown there is no issue that would cause your reliability issues.
-----------------------------------------------------------
I don't think they're losing sleep over this.(1)
-
05-19-2023 01:23 AM #195Player
- Join Date
- Apr 2021
- Location
- Ul'dah
- Posts
- 141
- Character
- Janyd Shieldstrike
- World
- Sargatanas
- Main Class
- Paladin Lv 100
Bummer, just ran a few Ping commands, and the latency on both of them jumped up to 98-105ms.
(1)
-
05-19-2023 01:23 AM #196Player
- Join Date
- Apr 2023
- Posts
- 33
- Character
- Generic Healer
- World
- Midgardsormr
- Main Class
- Scholar Lv 90
This is largely what I expect. When I was experiencing this on both AT&T (5 gig fiber) and Spectrum (1 gig cable) SE told me to call the ISP. I knew what the response from AT&T and Spectrum would be, and I agree with them since as I leave both their networks I have good latency and no packet loss. AT&T eventually escalated me to some engineers in Dallas who confirmed what I already knew, the issue is inside NTT. This is evidenced by the fact that I have no problems with the first NTT hop in Dallas. The second hop, also in Dallas, can from time to time introduce some latency, but the packet loss occurs when transiting to NTT in California. By this time, we are already inside NTT's network and it completely outside of our ISP's control. NTT announces their routes, and the ISP uses what is broadcast. It's just a stall tactic that has unfortunately become common in the industry to save face. Also interesting that I have been complaining about this since early April and it wasn't until some site wrote an article about it that SE finally calls NTT to work the issue.
Originally Posted by Ath192
(3)
-
05-19-2023 01:30 AM #197Player
- Join Date
- Apr 2021
- Location
- Ul'dah
- Posts
- 141
- Character
- Janyd Shieldstrike
- World
- Sargatanas
- Main Class
- Paladin Lv 100
At this rate, wouldn't it behoove SE to demand that NTT take those faulty nodes offline until fixes can be made?
(0)
-
05-19-2023 01:31 AM #198Player
- Join Date
- Jul 2019
- Posts
- 1,764
- Character
- Aries Helle
- World
- Excalibur
- Main Class
- Black Mage Lv 100
IDK that SE will get anywhere. Lets hope they do though. I don't see the difference between them telling an intern to see what's up and us doing the same.
Originally Posted by ntt_routing_is_an_issue
PIA has decent prices I guess....
SE peeps! just move the Datacenter to Dallas plz. xD(0)
-
05-19-2023 01:35 AM #199Player
- Join Date
- Apr 2023
- Posts
- 33
- Character
- Generic Healer
- World
- Midgardsormr
- Main Class
- Scholar Lv 90
SE has more pull since they are the customer of NTT. If random Joe calls NTT they are going to brush it off, but if SE calls it's an issue because there are SLA's in place.
Originally Posted by Ath192
(2)
-
05-19-2023 01:35 AM #200Player
- Join Date
- Apr 2021
- Location
- Ul'dah
- Posts
- 141
- Character
- Janyd Shieldstrike
- World
- Sargatanas
- Main Class
- Paladin Lv 100
SE datacenter in Texas? Wouldn't that be nice?!
As a fellow Texan (San Antonio/South Texas region), I'd be down for that.
Other MMORPGs have had, or currently have, Texas-based datacenters. Not naming any games in particular, but suffice it to say they are not made by Square Enix.
Regardless, moving the NA datacenters out of California and to a more centralized part of the US would help a lot of us out significantly.(1)
Reply With Quote
