EVE General Discussion

I emailed telia and asked them about the Destination net unreachable issue as it's coming on two days and still not able to access Eve Online. Their response:

Hello,



This is not our router , but our customer’s router that is nor responding:



ldn-b3_re0> traceroute 87.237.38.200

traceroute to 87.237.38.200 (87.237.38.200), 30 hops max, 40 byte packets

1 eveonline-ic-138015-ldn-b3.c.telia.net (213.248.83.198) 0.586 ms !X 0.565 ms !X *



Unfortunately, for any further troubleshooting with our customer, you would have to raise a ticket with your provider, we are only business support.



Kind Regards,



Nebojsa Trazivuk

Data & Infra Customer Care

Phone: +46 771 191 170
carrier-csc@teliasonera.com
TeliaSonera International Carrier, part of TeliaSonera group

So I'd say its an issue with CCP and there router.

of course they are. easier that way.

Guys -


If you're not aware, traceroute is actually a pretty terrible tool for determining where network problems are, because of how it works. Essentially it sends out packets with a fixed lifetime. Wherever the packets "die" the router can send a notice back saying "packet died here" which can help diagnose issues. The source of the trace sends a series of packets with hops to live = 1,2,3,4,5 etc.

The problem with it is that allowing the type of packet traceroute generates in the first place is optional (many routers block it for security because it's a general type of packet not specific to traceroute) and likewise many block the return packet saying "a packet stopped here" for security. Doing these blocks helps reduce load on the router because it does not need to originate or handle the traffic for them.

Because both types of packets are "control messages" they are high priority when handled and they get used a lot in DDOS attacks. Many, many providers block them now.

In Summary, traceroute is only a general tool for figuring out where packets go, and I haven't even covered the possibility that packets can take a different route from the one displayed because the trace is really only valid for packets that are part of the trace itself!

From what I can see from the trace telia sent, what they are saying is correct from their perspective. The interface on the router that goes to CCP London (but which is probably a step in the path, not the final location) is refusing traceroute packets from the source. It may or may not be refusing actual traffic, and there may be a reason it's refusing anything at all.

Looking at the address that's having issues from a network site in London (a utility site provided by a backbone) I see the following:

core1.fmt2.he.net> traceroute 213.248.83.198 Target 213.248.83.198
Hop Start 1
Hop End 30
Hop Packet 1 Packet 2 Packet 3 Hostname
1 0.227 ms 0.225 ms 0.308 ms ge5-19.core1.fmt2.he.net (64.71.148.109)
2 3.906 ms 5.503 ms 3.986 ms 10ge1-1.core1.sjc2.he.net (72.52.92.74)
3 0.659 ms 0.698 ms 0.645 ms sjo-bb1-link.telia.net (213.248.67.105)
4 73.804 ms 73.828 ms 75.293 ms nyk-bb2-link.telia.net (80.91.254.176) ash-bb4-link.telia.net (213.155.135.158)
5 145.355 ms 143.750 ms 143.749 ms ldn-bb2-link.telia.net (62.115.141.93) ldn-bb2-link.telia.net (213.155.133.6) ldn-bb2-link.telia.net (213.155.135.70)
6 143.839 ms 144.132 ms 143.805 ms ldn-b3-link.telia.net (80.91.251.165) ldn-b3-link.telia.net (62.115.137.197) ldn-b3-link.telia.net (80.91.249.176)


(sorry about the formatting)

What the above means is that from the perspective of routers in London (where Tranquility is located) everything is ok up until the link between "sjo-bb1-link.telia.net (213.248.67.105)" and "nyk-bb2-link.telia.net (80.91.254.176)" when packets start taking a lot of time to get from point A to point B.

Bearing in mind that traceroute can be unreliable, just making a quick assessment off the top of my head it looks like Telia has some issues with load (there's no packets dropped at the moment, just slow times) between those two addresses and addresses further down the line (closer to Sweden from the perspective of this trace).

Both addresses are within Telia's backbone, which means probably there's just too much traffic at this point.

Is it still impossible to connect to Eve, and at what time of day UTC? I can try to look at it then and see if it's an issue.


(I'm in the US by the way, I'm an IT person with a bit of experience, no connection to CCP or Telia).

I wonder if the instigators of the DDOS used ISBOXER?

I was dealing with the same issues but it seems to have resolved itself.

For now anyways.

I'm seeing this as well. Had thought it was on my end as this is a new public connection I'm using. It didn't like the fact that I was using Google's nameservers and had to use theirs.

Tracerts below:

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

C:\Users\Dr. Mike>tracert 87.237.38.200

Tracing route to srv200-g.ccp.cc [87.237.38.200]
over a maximum of 30 hops:

  1     2 ms     1 ms     1 ms  172.16.1.1
  2    40 ms    40 ms    40 ms  70.159.192.8
  3   149 ms    86 ms    46 ms  70.159.208.29
  4    49 ms    48 ms    46 ms  12.81.34.66
  5   108 ms    47 ms    47 ms  12.81.104.61
  6    48 ms   152 ms    47 ms  12.81.46.5
  7    49 ms    50 ms    51 ms  12.81.104.42
  8    46 ms    46 ms    44 ms  12.81.56.11
  9    63 ms    56 ms    59 ms  cr2.rlgnc.ip.att.net [12.123.152.110]
 10    58 ms    55 ms    59 ms  cr2.rlgnc.ip.att.net [12.123.152.110]
 11   170 ms    62 ms    58 ms  cr1.wswdc.ip.att.net [12.122.3.170]
 12    56 ms    57 ms    59 ms  gar18.wswdc.ip.att.net [12.122.113.37]
 13    56 ms    55 ms    55 ms  192.205.32.42
 14  204.245.39.42  reports: Destination net unreachable.

Trace complete.

C:\Users\Dr. Mike>tracert 87.237.38.200

Tracing route to srv200-g.ccp.cc [87.237.38.200]
over a maximum of 30 hops:

  1     2 ms     1 ms     1 ms  172.16.1.1
  2    39 ms    40 ms    39 ms  70.159.192.8
  3    52 ms    47 ms    46 ms  70.159.208.29
  4    48 ms    46 ms    46 ms  12.81.34.66
  5    58 ms    46 ms    52 ms  12.81.104.61
  6    47 ms    50 ms    56 ms  12.81.46.5
  7    49 ms    55 ms    49 ms  12.81.104.42
  8    45 ms    44 ms    46 ms  12.81.56.11
  9    57 ms    58 ms    61 ms  cr2.rlgnc.ip.att.net [12.123.152.110]
 10    56 ms    59 ms    64 ms  cr2.rlgnc.ip.att.net [12.123.152.110]
 11    61 ms    60 ms    57 ms  cr1.wswdc.ip.att.net [12.122.3.170]
 12    56 ms    57 ms    57 ms  gar18.wswdc.ip.att.net [12.122.113.37]
 13    55 ms    55 ms    55 ms  192.205.32.42
 14  204.245.39.42  reports: Destination net unreachable.

Trace complete.

C:\Users\Dr. Mike>

It's interesting though as a quick google shows 204.245.39.42 has been referenced before:

https://forums.eveonline.com/default.aspx?g=posts&t=217995

as well as others. The login screen loads fine and I'm seeing the server up and running there. After clicking play, I get the can't connect error. A quick check with a telnet into one of my servers shows the port to be open at the firewall.

Luckily I'm just here for lunch....

This mostly relocates the problem, and is hugely expensive at the same time.

For the most part, when problems with connectivity develop on the global 'net, they're due to actual link problems like overload or intermittent connectivity or local routing issues rather than problems getting to the IP of the target server (TQ).

This would work if CCP hired leased lines between each major nexus and the TQ cluster, but that's even more expensive.