Zone Crashing

[Wisteso]

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.

[Rickson]

I can confirm that using a VPN is working for me now as well. I posted about this earlier and now I have tested zoning and logging in and out and have had no issues. As soon as I disconnect the VPN, I get right back to the same issue.

Hopefully we do not all get flagged for having the same IP if we are using the same VPN. I am not sure if there is a way around that, though.

[evilkorn]

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.11.1 - 0 | 120 | 120 | 0 | 0 | 0 | 0 |
| cut - 0 | 120 | 120 | 8 | 11 | 28 | 8 |
| 162.151.114.249 - 0 | 120 | 120 | 8 | 13 | 71 | 30 |
|xe-11-0-0-0-sur02.delraywest.fl.pompano.comcast.net - 4 | 104 | 100 | 7 | 11 | 27 | 8 |
|xe-3-1-10-0-ar02.stuart.fl.pompano.comcast.net - 9 | 87 | 80 | 14 | 23 | 32 | 29 |
|he-0-9-0-0-ar01.northdade.fl.pompano.comcast.net - 4 | 104 | 100 | 0 | 19 | 36 | 19 |
|be-20214-cr01.miami.fl.ibone.comcast.net - 7 | 96 | 90 | 0 | 20 | 40 | 21 |
| 68.86.84.190 - 3 | 108 | 105 | 0 | 20 | 50 | 21 |
| 66.208.233.18 - 7 | 96 | 90 | 0 | 19 | 35 | 17 |
| et-8-3-0.nyc38.ip4.gtt.net - 58 | 35 | 15 | 0 | 52 | 56 | 51 |
| ae0-150.cr2.nyc3.ip4.gtt.net - 82 | 27 | 5 | 0 | 51 | 52 | 51 |
| No response from host - 100 | 23 | 0 | 0 | 0 | 0 | 0 |
| snip
|________________________________________________| ______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

[h4tch]

FYI: I did some mtu testing, and setting my mtu to 1490 allowed me to login. I'm still at work, so I can't mess with it much more. I did set my mtu back to 1500, and I wasn't able to login.

Anyone still have issues, if you try setting your mtu to 1480(was 1490) what happens?

[h4tch]

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),

[Wisteso]

That's another person (evilkorn) with the issue that's routing through GTT.

If we get enough information, should be possible to call GTT and let them know one of their nodes is having issues. (thats what I did with XO.net)

The MTU thing... I highly doubt its going to fix your issue. EQ does not send datagrams that are at risk to fragmentation. 512/576 is the largest packet the EQ client will send. Changing your MTU settings has no effect on how GTT handles their traffic.

Originally Posted by h4tch [You must be logged in to view images. Log in or Register.]

That makes sense, and gtt looks like maybe a cdn, or cloud service of some type.

GTT is a "Tier1" network. ISPs have peering agreements with networks and other ISPs to help them route traffic. GTT is a major network that many ISPs have a peering partnership with.

[Wisteso]

I'm looking at the logs so far and everyone who's posted a traceroute is being routed through NTT's "NYC3" network nodes. It doesn't appear to be a single specific node, since each route is slightly different but they are all still going through the NYC3 cluster.

In other words, its probably not faulty hardware. More likely that they either implemented some bad configuration changes, OR they're way above capacity. Or both.

[bspa0700]

Happened to me last weekend, and again tonight.

>> tracert 66.55.145.2

Tracing route to 66.55.145.2 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.0.0.1
  2    15 ms     8 ms     7 ms  98.245.120.1
  3     7 ms     7 ms     7 ms  xe-9-1-1-0-sur03.boulder.co.denver.comcast.net [
68.86.105.21]
  4    12 ms     8 ms     7 ms  ae-10-0-sur02.boulder.co.denver.comcast.net [162
.151.51.34]
  5    38 ms     9 ms    16 ms  ae-29-0-ar01.aurora.co.denver.comcast.net [162.1
51.51.13]
  6    12 ms    10 ms    12 ms  he-0-5-0-7-cr02.denver.co.ibone.comcast.net [68.
86.93.149]
  7    26 ms    27 ms    27 ms  be-11317-cr01.dallas.tx.ibone.comcast.net [68.86
.84.229]
  8    24 ms    23 ms    24 ms  he-0-10-0-1-pe03.1950stemmons.tx.ibone.comcast.n
et [68.86.86.114]
  9    23 ms    23 ms    23 ms  75.149.231.30
 10    90 ms    63 ms    63 ms  xe-10-1-6.nyc38.ip4.gtt.net [89.149.128.129]
 11    61 ms    61 ms    63 ms  ae0-150.cr2.nyc3.ip4.gtt.net [216.221.158.234]
 12    91 ms    91 ms    98 ms  as20473.ae7.ar2.nyc3.us.as4436.gtt.net [69.31.34
.78]
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.

[Kevris]

3 22 ms 18 ms 21 ms tge7-6.pldscabx01h.socal.rr.com [76.166.19.41]
4 46 ms 45 ms 44 ms agg15.pldscabx01r.socal.rr.com [72.129.38.14]
5 20 ms 20 ms 19 ms agg20.lsancarc01r.socal.rr.com [72.129.37.0]
6 17 ms 23 ms 23 ms bu-ether16.lsancarc0yw-bcr00.tbone.rr.com [66.10
9.6.102]
7 21 ms 20 ms 17 ms 0.ae0.pr1.lax00.tbone.rr.com [107.14.17.248]
8 34 ms 33 ms 36 ms ix-24-0.tcore1.LVW-Los-Angeles.as6453.net [66.11
0.59.81]
9 19 ms 18 ms 18 ms if-2-2.tcore2.LVW-Los-Angeles.as6453.net [66.110
.59.2]
10 19 ms 18 ms 17 ms 64.86.252.134
11 * 17 ms 18 ms ae-5.r21.lsanca03.us.bb.gin.ntt.net [129.250.5.8
5]
12 85 ms 89 ms 84 ms ae-6.r22.asbnva02.us.bb.gin.ntt.net [129.250.3.1
88]
13 88 ms 87 ms 89 ms ae-8.r23.nycmny01.us.bb.gin.ntt.net [129.250.2.1
48]
14 87 ms 87 ms 88 ms ae-1.r05.nycmny01.us.bb.gin.ntt.net [129.250.4.6
9]
15 122 ms 114 ms 114 ms ae-0.choopa.nycmny01.us.bb.gin.ntt.net [128.241.
2.202]
16 111 ms 110 ms 109 ms 108.61.244.41
17 * 114 ms 113 ms 108.61.244.50
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 *

etc..etc.

[Wisteso]

Kevris, you're the only person so far not going through GTT. How bad is the disconnecting for you?

I route through NTT as well (roadrunner too), but have not been having any issues for the last week. It could be that NTT is having minor issues as well, but not as severe.

Had a guildy having the issues as well, confirmed he was also routing through gtt.net