![]() |
#31
|
|||
|
![]() 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. | ||
Last edited by Wisteso; 07-06-2015 at 11:09 PM..
|
|
#32
|
|||
|
![]() 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. | ||
|
#33
|
|||
|
![]() |------------------------------------------------------------------------------------------|
| 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 | ||
|
#34
|
|||
|
![]() 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? | ||
Last edited by h4tch; 07-06-2015 at 11:44 PM..
Reason: change to reflect possible new mtu settings.
|
|
#35
|
||||
|
![]() Quote:
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), | |||
|
#36
|
||||
|
![]() 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. Quote:
| |||
Last edited by Wisteso; 07-06-2015 at 11:49 PM..
|
|
#37
|
|||
|
![]() 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. | ||
|
#38
|
|||
|
![]() Happened to me last weekend, and again tonight.
Code:
>> 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. | ||
|
#39
|
|||
|
![]() 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. | ||
|
#40
|
|||
|
![]() 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 | ||
Last edited by Wisteso; 07-07-2015 at 12:33 AM..
|
|
![]() |
Thread Tools | |
Display Modes | |
|
|