test content
What is the Arc Client?
Install Arc

DC - Boston Deadzone

birkepbirkep Member Posts: 73 Arc User
Got totally booted. Trace route fails at boston cogent. Guess its time to try something else.

12 209 ms 263 ms 265 ms te0-0-0-0.rcr11.b002133-1.bos01.atlas.cogentco.com [154.54.46.130]
13 * * * Request timed out.
Post edited by birkep on

Comments

  • quintarisquintaris Member Posts: 816 Arc User
    edited May 2015
    I blame Brady. We're all being punished because of DeflateGate.
    w8xekp.jpg
  • doctordositheusdoctordositheus Member Posts: 29 Arc User
    edited May 2015
    This happens to me several times every day. I disconnect and run a traceroute. The traffic makes it to that Boston server just fine and always fails on the last hop to the Cryptic server. It is not Cogent when it fails to make that last hop. That is Cryptic's server not responding. Something is wrong with their servers. They drop connections. It probably only happens to a small percentage of people. I'm sure we'll get the usual crowd in here momentarily exclaiming that it doesn't happen to ME so it all must be your fault or your imagination or Cogent or gremlins but it is definitely Cryptic's server dropping some small percentage of connections and then not responding to some small percentage of incoming traffic from those dropped connections. What is weird is I usually will be unable to log back in or reach their patch server at all to restart the launcher unless I restart my network connection. For some reason, their server will continue to ignore traffic from a dropped connection for a period of time, but if I restart my network connection I will be able to connect again almost 100% of the time.
  • birkepbirkep Member Posts: 73 Arc User
    edited May 2015
    Thats good to know - thx

    First time I've been down hard without a crowd complaining.
  • trekpuppytrekpuppy Member Posts: 446 Arc User
    edited May 2015
    30 years as a network technician here. You should be aware that not all network equipment on your path to Cryptic necessarily is configured to reply to ICMP echo requests (i.e. pings). Although it's a breach against RFC 792 it's a fairly common practice amongst ISPs for various reasons.
    Traceroute can use both ICMP and UDP but a request timeout doesn't conclusively tell you that something is wrong at a specific node. Despite people's good intentions, a traceroute is useless for serious network diagnostics. Long term traceroute statistics might give you a hint to where a problem is located (assuming it's on the network path) but for anything else you'll need access to both endpoints so you can record incoming and outgoing traffic and compare them. This will reveal any true delays on the network path and delays created on the client or server side (which might be application or hardware related).
    ---
    "-Grind is good!" --Gordon Geko
    Accolades checklist: https://bit.ly/FLUFFYS
  • doctordositheusdoctordositheus Member Posts: 29 Arc User
    edited May 2015
    That server: te0-0-0-0.rcr11.b002133-1.bos01.atlas.cogentco.com [154.54.46.130]
    is usually the last hop before Cryptic's servers. I take what I said previous to the edit back. I think I've identified the server that is dropping traffic after this piece of equipment. See post below after my current tracert.
  • doctordositheusdoctordositheus Member Posts: 29 Arc User
    edited May 2015
    Here's a fresh example. I just disconnected from the game a few minutes ago.

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation. All rights reserved.

    C:\Users\[Redacted]>tracert patchserver.crypticstudios.com

    Tracing route to patchserver.crypticstudios.com [208.95.185.41]
    over a maximum of 30 hops:

    1 1 ms 2 ms <1 ms [Redacted]
    2 53 ms 51 ms 52 ms [Redacted]
    3 56 ms 52 ms 52 ms dist4-vlan60.chcgil.sbcglobal.net [99.108.51.2]

    4 56 ms 55 ms 56 ms 12.83.106.198
    5 56 ms 55 ms 55 ms 12.122.99.78
    6 54 ms 59 ms 55 ms gar13.cgcil.ip.att.net [12.122.132.121]
    7 55 ms 57 ms 58 ms be2000.ccr21.ord03.atlas.cogentco.com [154.54.12
    .85]
    8 57 ms 54 ms 55 ms be2005.ccr41.ord01.atlas.cogentco.com [66.28.4.7
    3]
    9 64 ms 65 ms 62 ms be2351.ccr21.cle04.atlas.cogentco.com [154.54.44
    .86]
    10 76 ms 75 ms 74 ms be2009.ccr21.alb02.atlas.cogentco.com [154.54.25
    .89]
    11 80 ms 79 ms 80 ms be2299.ccr21.bos01.atlas.cogentco.com [154.54.43
    .9]
    12 78 ms 80 ms 78 ms te0-0-1-0.rcr11.b002133-1.bos01.atlas.cogentco.c
    om [154.54.46.134]
    13 * * * Request timed out.
    14 * * * Request timed out.
    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 * 83 ms 79 ms patchserverrebirth.crypticstudios.com [208.95.18
    5.41]

    Trace complete.

    C:\Users\[Redacted]>

    Next, I will restart my network interface, and watch how it resolves the issue.
  • jbmonroejbmonroe Member Posts: 809 Arc User
    edited May 2015
    @Trekpuppy -- your points are well-taken but I'm pretty sure everything along the path to Cryptic via Cogent supports ICMP. They've even asked me to trace to some other names while diagnosing this. One of the BOS nodes along the way has historically been spotty, but there's actually something going on once the packets get into the Cryptic side of things. There's a weekly outage that starts between 3:00PM-3:10PM every Sunday and lasts 15-20 minutes. That smells like a weekly reset and reload on a switch or router, but no one will admit to it. It's too regular to be anything but a scheduled job.

    During that time pings to patchserver2.crypticstudios.com get ACK'd just fine (with the odd RTO here and there) but nothing connects beyond it.
    boldly-watched.png
  • doctordositheusdoctordositheus Member Posts: 29 Arc User
    edited May 2015
    I think I've identified the culprit. After restarting my network interface, I was able to log back in as usual. However, it seems there IS a piece of network equipment between that Boston server and the Cryptic servers. Trekpuppy, my apologies. You were right.

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation. All rights reserved.

    C:\Users\[Redacted]>tracert patchserver.crypticstudios.com

    Tracing route to patchserver.crypticstudios.com [208.95.185.41]
    over a maximum of 30 hops:

    1 4 ms <1 ms 1 ms [Redacted]
    2 53 ms 53 ms 54 ms [Redacted]
    3 58 ms 52 ms 53 ms dist4-vlan60.chcgil.sbcglobal.net [99.108.51.2]

    4 56 ms 55 ms 55 ms 12.83.106.198
    5 54 ms 59 ms 55 ms 12.122.99.78
    6 58 ms 56 ms 58 ms gar13.cgcil.ip.att.net [12.122.132.121]
    7 58 ms 54 ms 54 ms be2000.ccr21.ord03.atlas.cogentco.com [154.54.12
    .85]
    8 55 ms 56 ms 54 ms be2005.ccr41.ord01.atlas.cogentco.com [66.28.4.7
    3]
    9 65 ms 63 ms 63 ms be2351.ccr21.cle04.atlas.cogentco.com [154.54.44
    .86]
    10 76 ms 75 ms 77 ms be2009.ccr21.alb02.atlas.cogentco.com [154.54.25
    .89]
    11 78 ms 81 ms 80 ms be2299.ccr21.bos01.atlas.cogentco.com [154.54.43
    .9]
    12 90 ms 80 ms 78 ms te0-0-1-0.rcr11.b002133-1.bos01.atlas.cogentco.c
    om [154.54.46.134]
    13 88 ms 85 ms 89 ms 38.111.40.114
    14 83 ms 81 ms 80 ms xboxpatchserver.crypticstudios.com [208.95.185.4
    1]

    Trace complete.

    C:\Users\[Redacted]>tracert patchserver.crypticstudios.com

    Tracing route to patchserver.crypticstudios.com [208.95.185.41]
    over a maximum of 30 hops:

    1 80 ms 1 ms 1 ms [Redacted]
    2 51 ms 52 ms 52 ms [Redacted]
    3 53 ms 53 ms 53 ms dist4-vlan60.chcgil.sbcglobal.net [99.108.51.2]

    4 55 ms 79 ms 55 ms 12.83.106.198
    5 61 ms 59 ms 54 ms 12.122.99.78
    6 57 ms 58 ms 57 ms gar13.cgcil.ip.att.net [12.122.132.121]
    7 58 ms 54 ms 57 ms be2000.ccr21.ord03.atlas.cogentco.com [154.54.12
    .85]
    8 56 ms 54 ms 55 ms be2005.ccr41.ord01.atlas.cogentco.com [66.28.4.7
    3]
    9 64 ms 67 ms 62 ms be2351.ccr21.cle04.atlas.cogentco.com [154.54.44
    .86]
    10 76 ms 78 ms 79 ms be2009.ccr21.alb02.atlas.cogentco.com [154.54.25
    .89]
    11 80 ms 80 ms 82 ms be2299.ccr21.bos01.atlas.cogentco.com [154.54.43
    .9]
    12 81 ms 79 ms 79 ms te0-0-1-0.rcr11.b002133-1.bos01.atlas.cogentco.c
    om [154.54.46.134]
    13 78 ms 86 ms 89 ms 38.111.40.114
    14 79 ms 80 ms 80 ms xboxpatchserver.crypticstudios.com [208.95.185.4
    1]

    Trace complete.

    C:\Users\[Redacted]>


    38.111.40.114 whois:

    NetRange: 38.0.0.0 - 38.255.255.255
    CIDR: 38.0.0.0/8
    NetName: COGENT-A
    NetHandle: NET-38-0-0-0-1
    Parent: ()
    NetType: Direct Allocation
    OriginAS: AS174
    Organization: PSINet, Inc. (PSI)
    RegDate: 1991-04-16
    Updated: 2011-05-20
    Comment: Reassignment information for this block can be found at
    Comment: rwhois.cogentco.com 4321
    Ref: http://whois.arin.net/rest/net/NET-38-0-0-0-1

    OrgName: PSINet, Inc.
    OrgId: PSI
    Address: 1015 31st St NW
    City: Washington
    StateProv: DC
    PostalCode: 20007
    Country: US
    RegDate:
    Updated: 2014-10-16
    Comment: rwhois.cogentco.com
    Ref: http://whois.arin.net/rest/org/PSI

    Why is our traffic reaching Boston, then taking a little visit down to our nation's capital, before being sent back to it's destination? This is a building that houses Cogent's Washington, D.C. office. A quick check down in the support section of these forums shows that most domestic traffic coming in on Cogent's network all goes through this server in between the Boston one and Cryptic's servers.

    Edit -- Nevermind, further research indicates that 38.111.40.114 is physically located in Boston. It is merely registered to PSINet, Inc., the Washington, D.C. based ISP that Cogent bought out. They probably moved that piece of equipment up to Boston at some point after the buyout. Specifically, it is this device at 38.111.40.114 that is dropping domestic traffic and not responding to attempts to reconnect.

    So we can all go back to blaming Cogent for the disconnects and trouble logging back in afterward.
  • trekpuppytrekpuppy Member Posts: 446 Arc User
    edited May 2015
    I don't mean to criticize anyone's efforts, I'm just asking you to be careful putting blame on a certain node since your client tools aren't capable of knowing this.
    The network infrastructure of today is highly complex. You can have a virtual tunnel between points A and B and a traceroute will show that as one(1) hop but the actual multiple physical nodes on that path will not reveal themselves at all.
    You also have the issue of net neutrality. If your ISP doesn't have a peering agreement directly with the ISP of the server center, your data will have to traverse one or more 3rd party ISPs to reach the server. Several ISPs are notorious to shape traffic that doesn't come from their own customers, especially if the destination is also not one of their own customers. All sorts of weird non standard things can happen to your data then.

    The pattern described by jbmonroe is highly interesting though. This is exactly the kind of behaviour users should pay attention to and report.
    ---
    "-Grind is good!" --Gordon Geko
    Accolades checklist: https://bit.ly/FLUFFYS
  • nickdeamrco019nickdeamrco019 Member Posts: 24 Arc User
    edited June 2015
    I posted this http://sto-forum.perfectworld.com/showthread.php?t=1471191 thinking the server was down yesterday. Today I still can not connect to the patch server after resetting my connection and do all of steps everyone has mentioned and ... Nothing :(:confused:

    9 71 ms 75 ms 89 ms be3030.agr21.fra03.atlas.cogentco.com [130.117.14.217]
    10 103 ms 72 ms 68 ms be2188.ccr42.fra03.atlas.cogentco.com [130.117.48.114]
    11 79 ms 79 ms 79 ms be2262.ccr42.ams03.atlas.cogentco.com [154.54.37.33]
    12 89 ms 103 ms 89 ms be2183.ccr22.lpl01.atlas.cogentco.com [154.54.58.69]
    13 156 ms 169 ms 154 ms be2387.ccr22.bos01.atlas.cogentco.com [154.54.44.165]
    14 156 ms 155 ms 155 ms te0-0-0-0.rcr11.b002133-1.bos01.atlas.cogentco.com [154.54.46.130]
    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.
Sign In or Register to comment.