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

yeah, DTAG is know for that paid peering, even Level3 had to go to a german court to get enough peering bandwith for the free peering with DTAG. When we see it clear now, DTAG is not willing to do a clean routing to Cloudflare and want to get paid for a direct peering. I think that not conform with german laws.

have you allready thought about talking to german IT press like heise.de about how DTAG act in this case, could bring political pressure, and in this case the DTAG customer paying them to get stable conections… now saying you have to pay to get stable connections to DTAG customers is against the net neutrality…

since I’m using my VPN solution I have a stable connection. :slight_smile:

1 Like

Same here, still issues. some days unplayable without vpn (like dc every few seconds up to 5 minutes) sometimes less worse… (like “only” 1 dc each 1-4 hours) totally random.
was stable until 1st of august (+/- 3 days)
Cloudflare Vpn even worse (couse it keeps dcing EVERYTHING not just eve… without its just eve).

with proton i have no issues… so far… well… the free servers are at prime time some times dying… but … good enough

Did DTAG change something or did ccp stop paying for premium? :stuck_out_tongue:
cant belive atm the load is that high that its causing these issues…

or someone at dtag is a former eve player who wasnt satisfied… who knows

Nothing changed. Still the same problems over the last 2 Months.

It finally looks like this has been resolved about 3 days ago:

We are still waiting for details from Deutsche Telekom on what they changed.

Longer-term view splicing together multiple graphs:

It would be super-interesting to see

  • The traceroute to TQ: tracert tranquility.servers.eveonline.com in a CMD window
  • The Cloudflare colo info: https://eveonline.com/cdn-cgi/trace in a browser

to check if it has changed from when the issues were happening.

ok thought it was a “accident”… did forget yesterday for about an hour to turn vpn on… hadnt any dc in that time… but keept playing with vpn just in case… the ping path didnt look different when i was running pingplotter. - at least i did see the level3 hop… but didnt see any jumping inside the path like before. i will keep it running tomorrow some more and do these 2 think ccp explorer mentioned.

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.