![]() |
#21
|
||||
|
![]() If you are suddenly having major issues with zoning and logging in (out of date spells, weird errors, crashing) AND your setup hasn't changed at all then you are dealing with packet loss.
It has nothing to do with the last patch. The best thing that you guys can do is provide a copy of your traceroute to 66.55.145.2 and we can hopefully see a common network node that you guys all have in common. That node is probably damaged or had its configuration changed in the last day. I had this issue for a solid week recently, and spent a lot of time figuring out who/what/where/when/why of it all. It took a while, but the issue was repaired. It will look something like... Quote:
| |||
Last edited by Wisteso; 07-06-2015 at 06:40 PM..
|
|
#22
|
|||
|
![]() Here is what I get. I cut it short because it just kept giving me timed out error for 30 hops:
tracing route to 66.55.145.2 over a maximum of 30 hops 1 <1 ms 1 ms 1 ms 192.168.1.1 2 * * * Request timed out. 3 8 ms 7 ms 15 ms gateway-p1-399-senjblocal1.spo.ptd.net [24.229.33.97] 4 9 ms 9 ms 9 ms xe-1-0-3-854.ar1.nyc3.us.as4436.gtt.net [69.31.95.125] 5 16 ms 11 ms 12 ms as20473.ae7.ar1.nyc3.us.as4436.gtt.net [69.31.34.62] 6 11 ms 110 ms 10 ms ethernet1-2-2-c8-12-b2-1.pnj1.choopa.net [108.61.80.218] 7 * 10 ms 10 ms 108.61.244.50 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * | ||
|
#23
|
|||
|
![]() If some of you are willing to try that have this issue and are tech savvy, I would still recommend trying to optimize your MTU: http://www.tp-link.us/FAQ-190.html
If the packets fragment, it's definitely a higher chance for packet loss. Some of the most common DoS attacks also work by heavily fragmenting packets so sometimes fragmented packets will be flat out dropped at a node when trying to fight a DoS attack so by not fragmenting your packets it allows you to get through. This actually happened with Destiny not too long ago. People were lowering their MTU to connect when they were being attacked and the reason that worked is largely the same reason as mentioned above. The issue mostly occurs with DSL, which has a maximum MTU of 1492 and a lot of routers/devices are still set at 1500 because they don't know what type the underlying connection is. Worst case, it doesn't fix your issues on P99, but will actually speed up your connection quite a bit if your MTU is indeed set wrong. | ||
Last edited by Tahlvin; 07-06-2015 at 07:19 PM..
|
|
#24
|
|||
|
![]() What's funny about a tracert is I get time outs but I don't have any problems with connecting :/
| ||
|
#25
|
|||
|
![]() Tarkhis, yeah cutting the tail off is fine. Windows tracert will keep trying for a max of 30 hops, even if the route is much shorter than that. WinMTR does a better job but I dont expect people to have it installed.
Swish, yeah that's because network nodes often ignore or de-prioritize meta traffic. Its actually a bad idea to use packet loss of meta traffic for determining where issues occur, but people (even tech support) still does it all the time. Tahlvin, optimizing the MTU will not help. EQ uses datagrams of size 512 (576 including the header) which is guaranteed to not fragment. It also wouldn't suddenly start acting up for big groups of people all of a sudden. | ||
Last edited by Wisteso; 07-06-2015 at 07:48 PM..
|
|
#26
|
|||
|
![]() I'm having the issue as well now (I was fine yesterday), either I can't get logged in (disconnected) or when I finally got in once I was fine until I zoned and never finished zoning, had to reboot the computer. Now can't get back in, says server issue then disconnects.
| ||
|
#27
|
|||
|
![]() Just keep trying. Its a packet loss issue so eventually you'll probably get lucky.
Rebooting wont help you. | ||
|
#28
|
|||
|
![]() Getting this too
__________________
| ||
|
#29
|
|||
|
![]() Guys, "me too" posts aren't helpful. Its not an issue with P99. Please post a traceroute.
http://kb.intermedia.net/article/682 (how-to guide) | ||
|
#30
|
|||
|
![]() So this does appear to be a routing issue. I tried it with normal internet, and a vpn. I was able to login when using the vpn. This was all working normally for me just a few hours ago. Is 66.55.145.2 the actual ip address of the server? I get timeouts even over the vpn that I can login with. First trace is my normal internet, and second is a vpn.
C:\Users\Winterfell>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 192.168.1.1 2 23 ms 14 ms 15 ms 96.120.48.193 3 22 ms 14 ms 14 ms te-0-2-0-5-sur01.crosstown.mn.minn.comcast.net [68.85.164.1] 4 18 ms 14 ms 12 ms te-0-5-0-0-sur02.crosstown.mn.minn.comcast.net [69.139.219.8 5 18 ms 17 ms 31 ms te-0-6-0-0-ar01.roseville.mn.minn.comcast.net [68.87.174.217 6 25 ms 27 ms 27 ms he-5-3-0-0-cr01.350ecermak.il.ibone.comcast.net [68.86.166.2 7 28 ms 27 ms 28 ms c-eth-0-2-0-pe05.350ecermak.il.ibone.comcast.net [68.86.86.3 8 33 ms 29 ms 28 ms ae12.chi11.ip4.gtt.net [199.229.229.249] 9 49 ms 48 ms 46 ms et-8-1-0.nyc38.ip4.gtt.net [89.149.180.206] 10 48 ms 50 ms 56 ms ae0-150.cr2.nyc3.ip4.gtt.net [216.221.158.234] 11 84 ms * 94 ms as20473.ae7.ar2.nyc3.us.as4436.gtt.net [69.31.34.78] 12 * * * Request timed out. 13 * * * Request timed out. 14 ^C C:\Users\Winterfell>tracert 66.55.145.2 Tracing route to 66.55.145.2 over a maximum of 30 hops 1 110 ms 116 ms 110 ms 10.9.0.1 2 * * * Request timed out. 3 * * * Request timed out. 4 119 ms 118 ms 119 ms xe-5-0-2-0.lon-001-score-1-re0.interoute.net [194.150.37.81] 5 181 ms 184 ms * ae0-0.lon-001-score-2-re0.interoute.net [84.233.218.190] 6 199 ms 184 ms 185 ms ae1-0.nyc-002-score-1-re0.interoute.net [212.23.43.169] 7 181 ms 178 ms 183 ms ae0-0.nyc-002-score-2-re1.interoute.net [212.23.43.158] 8 184 ms 192 ms 185 ms nyiix.gi3-6.cr1.nyc1.choopa.net [198.32.160.157] 9 183 ms 190 ms 184 ms 108.61.244.50 10 * * * Request timed out. 11 * * * Request timed out. P.S. If anyone wants me to do additional testing just let me know. I'm a network engineer though I'm a managed services guy, so I don't deal with core, or cdn routers ever. | ||
Last edited by h4tch; 07-06-2015 at 10:59 PM..
|
|
![]() |
|
|