20220819 - Verbindungsprobleme (Deutschland) / Connection Issues (Germany)

Today routing didnt change:
Before and after downtime:

Start: 2022-10-27T10:04:06+0200
HOST:                                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.0.1                                                   0.0%    10    1.0   1.8   1.0   6.0   1.6
  2. AS3320   62.156.244.48                                                 0.0%    10   10.0  11.3   9.0  22.0   3.8
  3. AS3320   62.156.247.170                                                0.0%    10   12.0  12.8  11.0  27.0   5.0
  4. AS3320   f-ed14-i.F.DE.NET.DTAG.DE (62.159.99.138)                     0.0%    10   14.0  19.6  14.0  55.0  13.3
  5. AS3320   f-ed14-i.F.DE.NET.DTAG.DE (62.159.99.138)                     0.0%    10   13.0  14.1  13.0  19.0   1.9
  6. AS3320   80.156.162.178                                                0.0%    10   12.0  13.8  12.0  17.0   1.7
  7. AS6453   if-ae-54-2.tcore1.fr0-frankfurt.as6453.net (195.219.219.72)  70.0%    10   13.0  14.0  13.0  15.0   1.0
  8. AS6453   195.219.148.122                                               0.0%    10   13.0  14.7  13.0  24.0   3.5
  9. AS13335  162.158.84.53                                                 0.0%    10   13.0  13.5  12.0  17.0   1.4
 10. AS13335  172.65.201.188                                                0.0%    10   13.0  13.3  12.0  15.0   1.1


Start: 2022-10-27T22:08:06+0200
HOST:                                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    10.0.0.9                                                      0.0%   100    0.0   0.0   0.0   0.0   0.0
  2. AS???    192.168.0.1                                                   0.0%   100    0.0   0.0   0.0   0.0   0.0
  3. AS3320   62.156.244.48                                                 0.0%   100    8.0  12.3   8.0  70.0   9.7
  4. AS3320   62.156.247.170                                                0.0%   100    9.0   9.6   9.0  28.0   2.2
  5. AS3320   f-ed14-i.f.de.net.dtag.de (62.159.99.138)                     0.0%   100   12.0  12.5  12.0  28.0   1.7
  6. AS3320   f-ed14-i.f.de.net.dtag.de (62.159.99.138)                     0.0%   100   12.0  12.3  11.0  31.0   2.2
  7. AS3320   80.156.162.178                                                0.0%   100   12.0  12.0  11.0  25.0   2.5
  8. AS6453   if-ae-54-2.tcore1.fr0-frankfurt.as6453.net (195.219.219.72)  75.0%   100   12.0  12.2  11.0  14.0   0.6
  9. AS6453   195.219.148.122                                               0.0%   100   13.0  13.2  11.0  47.0   4.3
 10. AS13335  162.158.84.53                                                 0.0%   100   18.0  15.5  11.0  44.0   7.2
 11. AS13335  172.65.201.188                                                0.0%   100   11.0  11.4  11.0  24.0   1.5

When I had disconnects the routing was via AS6762, AS2914, or AS6453, flapping between them or just over saturated links.

AS6453 works today obviously, the route when it did not work was for example:

Start: 2021-06-06T20:21:13+0200
HOST:                                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    mikrotik.kk.local (10.0.0.9)                                  0.0%  1000    0.0   0.0   0.0   1.0   0.0
  2. AS???    192.168.0.1                                                   0.0%  1000    0.0   0.0   0.0   1.0   0.2
  3. AS3320   62.156.244.48                                                 0.0%  1000    8.0   9.2   8.0  64.0   5.5
  4. AS3320   62.156.247.170                                                0.0%  1000    9.0   9.0   9.0  14.0   0.5
  5. AS3320   217.5.113.70                                                  0.0%  1000   12.0 188.9  11.0 4629. 529.5
  6. AS3320   217.5.113.70                                                  0.0%  1000   12.0  91.7  11.0 2823. 323.7
  7. AS3320   80.156.162.178                                                0.0%  1000   12.0  11.6  11.0  41.0   2.5
  8. AS6453   if-ae-54-2.tcore1.fr0-frankfurt.as6453.net (195.219.219.72)   4.3%  1000   20.0  20.0  19.0  35.0   0.7
  9. AS6453   if-ae-55-2.tcore2.pvu-paris.as6453.net (80.231.245.6)         0.0%  1000   25.0  25.5  24.0  59.0   3.0
 10. AS6453   if-ae-49-2.tcore1.pvu-paris.as6453.net (80.231.153.20)        5.7%  1000   25.0  25.2  24.0  44.0   1.7
 11. AS6453   if-ae-11-2.tcore1.pye-paris.as6453.net (80.231.153.50)        0.0%  1000   20.0  20.1  19.0  57.0   3.2
 12. AS6453   80.231.154.14                                                11.6%  1000   51.0  58.5  48.0 186.0  20.8
 13. AS13335  172.65.201.188                                               10.1%  1000   56.0  55.3  53.0  74.0   1.2

Looking at metrics in the past day then this is probably back to being broken.

The issue is clearly solvable, however, as the temporary reprieve demonstrated where some capacity on the congested links was freed up. It’s just that Deutsche Telekom and Cloudflare need to work together, e.g. on any of the solutions we here at CCP have proposed.

We continue to discuss this matter with the parties involved.

1 Like

Yeah I can confirm that I left the client running for a bit longer yesterday and had no Issues, will keep the VPN off and see if it stays this way.

1 Like

still 1% loss for me:
WinMTR_8nMsbyuWcc

looks like the level3 node is down entirely.

Lets hope it will stay dead… hadnt any issue today even without vpn in a couple of hours of playtime…
but i still avoid abyss for some time… xP

1 Like

apparently we’re being routed through a dedicated CLOUDFLARE node in Düssedorf to TQ now. It was Frankfurt before. Hopefully this issue is fixed now once for all.
WinMTR_6sIGC08iwV

1 Like

And now it’s back to not being broken.

1 Like

That would be most welcome news if Deutsche Telekom and Cloudflare resolved this issue; a direct reciprocal peering is what we at CCP first and foremost suggested. This here still looks like it’s via Level3/Lumen but hopefully a more stable and less congested path.

1 Like

I think I’ll continue using my ProtonVPN wireguard setup (tunnelling only EVE client). It’s just so stable that it even survives my daily IP reset (why DT, WHY?). I don’t trust DT until they show that things are working for a few months.

1 Like

havent had any disconnects over the last 2 days, no VPN.

1 Like

Also confirming that I’ve been online for an hour and did not get disconnected (disconnect in the first minute while the problem persisted). Today is the first day I tried it without the VPN, let’s hope it stays that way.

1 Like

Another confirm, connection is stable again for approx. 2 weeks now - no VPN whatsoever needed. Would be very interesting to document any results/changes. Any feedback from Level3/DT received?

Problem seems to be back (West of Germany), can’t even get to the char select screen at all. Launcher takes a long time to update account status too. Firing up VPN fixes it immediately. Hope it is temporary.

i can confirm that, hard connection problems today, connection losses, and times with heavy inputlag …

yeah had the same issue that day (south germany) started somewhere at evening… kicked me out of all accounts and didnt let me log in for quite a while… maybe 1 hour. turn on the vpn did fix it and next day all was stable again at me without vpn… after that no problems yet.
so i blame the the freezeing temperature of -15°C or temporaly bs at cloudflare nodes in my region. (only game effected was again just eve online, everything and every online game else did still work perfect)
but at least it wasnt again for month so i am fine :smiley:

merry christmas and lag free days to all :smiley:

and we’re back. 60-80% packet loss atm. aside from black screens and game not responding to anything, im not facing an “real” disconnect.
atm not even station trading is an option

Hi, have the same problem .
and it is the routing to CLOUDFLARE . edge6 . Duesseldorf1 . Level3 . net again:
tracert tranquility . servers . eveonline . com

Started: 15 . 02 . 2023 19:33:36,19

Routenverfolgung zu d638e439e07f413c97200d057e5ebd05 . pacloudflare . com [172 . 65 . 201 . 188]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms speedport . ip [192 . 168 . 1 . 1]
2 8 ms 9 ms 8 ms p3e9bf456 . dip0 . t-ipconnect . de [62 . 155 . 244 . 86]
3 22 ms 11 ms 11 ms d-ed5-i . D . DE . NET . DTAG . DE [217 . 0 . 192 . 6]
4 11 ms 17 ms 11 ms d-ed5-i . D . DE . NET . DTAG . DE [217 . 0 . 192 . 6]
5 11 ms 11 ms * 4 . 68 . 71 . 113
6 20 ms * 15 ms CLOUDFLARE . edge6 . Dusseldorf1 . Level3 . net [62 . 67 . 22 . 246]
7 * 17 ms * 172 . 65 . 201 . 188
8 15 ms 14 ms * 172 . 65 . 201 . 188
9 14 ms 13 ms * 172 . 65 . 201 . 188
10 13 ms 13 ms 13 ms 172 . 65 . 201 . 188

Ablaufverfolgung beendet .
Completed: 15 . 02 . 2023 19:34:05,41

I can’t stress enough that CCP didn’t do anything to fix the issues, except to complain repeatedly (and bitterly) to Deutsche Telekom for weeks, both directly and through our internal and external network partners and our carriers. Eventually Deutsche Telekom fixed the issue. If the issue is back then Deutsche Telekom has to fix it again. Please contact them, refer them to the previous incident, and ask that they look into the matter.

again massive connection problems with DTAG

4.68.71.113 is again Level 3