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

Hallo zusammen,

wir untersuchen gerade die Verbindungsprobleme, die in letzter Zeit manche Spieler in Deutschland betreffen, vornehmlich Kunden der Deutschen Telekom AG.

Wenn bei euch seit dem 1. oder 2. August gehäuft Verbindungsunterbrechungen auftreten und euer Anbieter die Deutsche Telekom AG ist, dann erstellt bitte ein Support-Ticket. Lest bitte den Rest dieses Posts, um herauszufinden, wie ihr die Informationen bekommt, die im Ticket enthalten sein müssen.

Eins vorweg: Bitte postet die Informationen NICHT als Antwort in diesem Thread, da sie persönliche Daten enthalten. Erstellt stattdessen Support-Tickets, wie oben erwähnt. Zudem ist es wichtig, dass ihr eure Beschwerden über die Netzwerkinstabilität in diesem Forumsthread der Deutschen Telekom AG postet.

Im Ticket muss eine sogenannte Traceroute enthalten sein: Hier erfahrt ihr, wie ihr Traceroute-Informationen erhaltet.

Es ist möglich, dass wir je nach Fall bei euch rückfragen, um weitere Informationen zu erhalten.

Falls ihr über das nötige IT-Wissen verfügt, wäre es hilfreich, wenn ihr uns stattdessen diese tracert schickt.

Wenn ihr in Deutschland spielt und seit Anfang August öfter Verbindungsprobleme habt, meldet euch bitte trotzdem bei uns, auch wenn euer Anbieter nicht die DTAG ist.

Noch einmal: Bitte postet die Informationen NICHT als Antwort in diesem Thread, da sie persönliche Daten enthalten.

Lest bitte auch diesen Post von @CCP_Explorer über Cloudflare-VPNs. Wenn ihr eure Verbindungsprobleme mithilfe dieses VPNs lösen konntet, würden wir gerne eine Traceroute mit dem aktiven VPN sehen, um die verschiedenen Netzwerkpfade nachverfolgen zu können.

Dieses Problem kann nicht durch einen Patch behoben oder generell von unserer Seite aus gelöst werden. Die Verantwortung für die Problembehebung liegt bei der DTAG, Cloudflare und möglicherweise auch Level3, da Level3 in Frankfurt auch in Traces auftaucht, die uns zugeschickt wurden.

Danke für eure Problemberichte und eure Geduld, während wir das Problem weiter untersuchen.


Hello everyone,

We are looking into the connectivity issues which have recently started affecting certain players in Germany, mainly customers of Deutsche Telekom AG.

If your ISP is Deutsche Telekom AG and you’ve been experiencing more disconnects since 1 - 2 August, then please create a support ticket. Be sure to read the rest of this post to find out how to obtain the information we would like you to include in the ticket.

First off: Please DO NOT post any of your details as a reply in this thread as they will contain private information. Instead provide them via a support ticket as mentioned previously. It is also important that you add your complaint to this Deutsche Telekom AG forum thread about your network route instability.

The information we’d like to see in your ticket is called a Traceroute: How to obtain Traceroute information.

We may follow up with you to gather further information on a case-by-case basis.

If you’re especially confident in your computer skills, please send us this tracert instead.

If you are playing from Germany and have been experiencing disconnects since the beginning of August then we still want to hear from you, even if your ISP is not DTAG.

Again, please DO NOT post these details as a reply in this thread as they will contain private information.

Please also see this post from @CCP_Explorer about Cloudflare VPNs. If you have successfully resolved the connection issues using this VPN, then we would want a traceroute with the VPN active to be able to see the different network paths as well.

This issue can’t be fixed in a patch and can’t be fixed on our side. This needs to be fixed by DTAG and Cloudflare, possibly with Level3’s involvement since we have seen Level3 in Frankfurt in traces that have been sent to us.

Thank you for your reports and ongoing patience while we look into this.

4 Likes

What we are initially looking for is basic debug information so that Deutsche Telekom and Cloudflare can investigate this issue:

  • Your geographical location, your ISP details, and other relevant information about where and how you connect to the internet. If there are any patterns to the disconnects, please let us know as well.
  • The network path from your computer to Tranquility: Run tracert tranquility.servers.eveonline.com from a Command-Line Window, save the output in a text file and send us.
  • Your network details and how you connect to Cloudflare: In https://web.ccpgamescdn.com/aws/community/eve_network_diagnostics_v6.zip then you will find a file called eve-network-diagnostics v6.ps1, which is a Windows PowerShell Script. Run this script and send us the output file. We are mostly interested in the top two sections in that file.

In addition to posting in the Deutsche Telekom AG forum thread on this issue, if you contact DTAG’s technical support directly then you can refer the support person to their trouble ticket IM0002013917.

For more advanced debug information, please see @CCP_Convict’s original post above with the alternative advanced traceroute and Cloudflare WARP details.

1 Like

CCP-Forscher

Wir suchen zunächst nach grundlegenden Debug-Informationen, damit die Deutsche Telekom und Cloudflare dieses Problem untersuchen können:

Ihren geografischen Standort, Ihre ISP-Details und andere relevante Informationen darüber, wo und wie Sie sich mit dem Internet verbinden. Falls es irgendwelche Muster bei den Verbindungsabbrüchen gibt, teilen Sie uns dies bitte ebenfalls mit.
Der Netzwerkpfad von Ihrem Computer zu Tranquility: Führen Sie tracert tranquility.servers.eveonline.com in einem Befehlszeilenfenster aus, speichern Sie die Ausgabe in einer Textdatei und senden Sie sie uns.
Ihre Netzwerkdetails und wie Sie sich mit Cloudflare verbinden: Unter https://web.ccpgamescdn.com/aws/community/eve_network_diagnostics_v6.zip finden Sie eine Datei namens eve-network-diagnostics v6.ps1, ein Windows PowerShell Script. Führen Sie dieses Skript aus und senden Sie uns die Ausgabedatei. Wir sind vor allem an den ersten beiden Abschnitten in dieser Datei interessiert.

Wenn Sie sich direkt an den technischen Support der DTAG wenden, können Sie nicht nur im Forumsthread der Deutschen Telekom AG zu diesem Problem posten, sondern auch auf das Trouble Ticket IM0002013917 verweisen.

Übersetzt mit DeepL Translate: The world's most accurate translator (kostenlose Version)

1 Like

ok thanks for the information.
Its just a shame it effects -at least at me- again just eve online and nothing else…
so… weird?

Did collect all requested Information and add it into the ticket (nearly over read that it shouldn´t be posted here…)

and… couse i was bored anyway (and didnt feel like login in after getting annoyed yesterday a lot with dcs…) i had time to try some stuff out and collected some additional Data and hope maybe something of that helps… ( i have no idea about it and my english is gross… but well who knows…)

I am a coustomer of 1&1 in south germany, but as nearly all isp which are avaible outside of Cities, it uses the DTAG infrastructure… so kinda DTAG customer.

No Issues on any other Game (a couple of other mmorpgs and stuff like WoT or DayZ)

At Eve, it kinda started to get that bad at me at 2nd of August… but… didnt note it down couse… its eve… sometimes dcs happens so i ignored it as good as i can for the first few days and was stuck playing stellaris a bit anyway… so could be have started even a bit earlyer…

the DCs only happen at me the first second after starting a client up to 5 minutes till than… if i get pass that “timer” i can play for hours without any issue.

If started multiple accounts/clients at the same time 20-70% of all clients will get a DC, the others will just work fine… And its Totally Random and different on every try.

(Btw it was the first time in 10 Years i had DCs inside the Char selection Screen… i mean while playing happens sometimes really rare, sometimes -when ddos happened or big changes etc… - some more while playing… but that was a bit strange…and couldnt remember to happen before… )

I launched a lot of times my accounts and wrote down the numbers of Disconnects:

Without VPN: 86 out of 180 Times i had a DC in the first 5 Minutes. (49 times Afternoon, 37 early morning)

With VPN : 16 out of 180 Times i had a DC in the first 5 Minutes. (most right after i did set the vpn up, and a few couse cloudflare vpn thingy lost connection to Colocation-Center 2 Times at the afternoon, and one connection lost to the colocation-center in the morning)

Without VPN on Sisi:
0 out of 90 Times i had a dc on Sisi…
(didnt bother to get it to 180 Trys and didnt try it with vpn)

So… till -whoever needs to do it- its fixed, i have 4 Options:

1: use vpn, i lose more than 60% of my speed so maybe no Netflix while playing… , and maybe when all do it now it dcs itself :smiley: but its a good option.
2: Only Play on Sisi till its fixed
3: try my luck and if i get in for more than 5 minutes, i should never log off again
4: keep playing other games

Hope that somehow helps, fly safe
and sry for my english ;3

1 Like

Hello,
I’ve been experiencing this problem since around start of August and had opened ticket 1900029 on the 7th, and I think I’ve provided all that was asked, including the tracert.

I’ve since started using a home-rolled Tailscale VPN via my own Hetzner VPS when playing EVE and the problems have vanished, so at the moment I don’t see the need to either open another ticket or provide the same debug info, unless I am specifically asked to. This solution works for me although it’s not great, so this is just one solution + ticket number for reference. Gonna look at that DTAG thread now.

1 Like

Hi ho, same problem here, I’ve playing with my iMac, it’s not just a windows-problem.

1 Like

I’ve opened Ticket 1906048 with tracert Information. If i can help any further please let me know. It is really annoying.
Like most others i get the Disconnects right after login at or before the Character Selection screen.
When i bypass the Character Screen there is high chance the Client gets disconnected within the first 5 Minutes of gameplay, often just 2 out of 3 Clients.
After 5-10 Minutes i usually don’t get any more disconnects.

1 Like

I have already created a ticket (1899364) two weeks ago. Since I started using VPN, I have not experienced any connection problems.

I’m glad to hear that many of your have been able to resolve or mitigate the issue using a VPN; that builds a case that the underlying root cause is somewhere on the regular network path from your home network to Cloudflare.

had the issue today a few times even with the cloudflare warp thing…
but i did see always if i had issues it was on Colocation-Center MUC (Munich?) . a bit later it did switch to FRA (Frankfurt?) by itself and the DCs did end.

But i have not really any idea about vpn, its just the only thing i did see changeing in the vpn software.

guess i will check for another free vpn just to be sure and try it there too.
But didnt play so much… couse i dont trust it atm really.

And, just to point it out one more time, i never had any dc on Sisi even without vpn… just saying.

1 Like

MUC is Münich and FRA is Frankfurt. Interesting to hear that the disconnects might be linked to a DTAG network route to Münich. Have you been able to get a traceroute while it is connected to MUC?

Tranquility and Singularity are not in the same country, not on the same network, not with the same hosting or network providers, and are protected by different DDoS protections.

For a good connection to TQ then ISPs need to provide a high-quality network connection and a stable network route to a nearby Cloudflare colo.

Can you do us a favour, please, and update that ticket with a traceroute with VPN on and with VPN off?

Can you do us a favour, please, and update that ticket with a traceroute with VPN on and with VPN off?

Updatet Ticket 1906048 with up to date tracert and EVE-diag*.txt

When i use Cloudfare WARP it disconnects me randomly from Internet, so this is not a solution for me.

i think i did add one to my Ticket already (Ticket: 1906064) .
I did add a few runs with the powershell script. and i did edit 3 runs and added to the file name "without vpn, with vpn and With VPN - but colocation-center disconect midtest.
(and i did run the batch file for hours by mistake couse i forgot to turn it off…, even with switching between with and without vpn, feel free to check it if it helps…)

i will make a few new one with and without vpn and with both Colocation-Center.
Or do you prefer just running the batch file for a few minutes instead of the powershell thing?

Edit: before i was just checking the behavior of dcing with just connecting and stay logged in etc.
after i tryed to actually play with vpn on for longer… cloudflare disconnects quite a few times per hour - or better said, seems to switch between MUC and FRA and back without me beeing able to intervene- which disconnects at least eve , and some times (if it tooks longer) everything else too… like discord, youtube etc…which is even more annoying than “just” dcing eve. at the same time, the ping isnt good… and not stable, and i “only” get 60mbit down and 20 mbit upload out of my 250/40.

so for now, i blame cloudflare and try an alternative vpn for now.
If it works better i will run the ping stuff there too and add it to the ticket.

Added followup ticket 1907421 with the logs attached.

Yes, running the batch file commands continuously in the background and then on disconnect try and see if the traceroute changed at the same time (scroll through the traceroutes and see if the last few ones are the same or not).

Very interesting, but this network route instability will indeed disconnect EVE. If your connection starts in MUC, when it changes to FRA then the stateful network equipment in FRA will have no details of you and needs to reset the connection.

We have learned that Deutsche Telekom doesn’t have any direct peering with Cloudflare. This issue is then more likely with Deutsche Telekom as they switch between different routes to Cloudflare (hopping across the networks of different companies that have direct peering) or with the carrier(s) that Deutsche Telekom uses.

Furthermore, we have seen these types of issues before and they can be resolved but can only be resolved by the ISP, which is Deutsche Telekom in this case. First and foremost because they control their network routes but also because they are paying their carriers and therefore have contractual leverage.

Sorry i did mean i blame the Cloudflares VPN Software behavior for now. did mean the switching :smiley:

Tryed it now with proton.
Couse its free i was limitied to use netherland/ japan and usa, but Netherlands worked fast and stable from my location for a few hours now.

Added my ticket (1906064) a 10 Minutes Pathplotter Log with 239 pings for each vpn variation with proton and cloudflare (MUC and FRA each a seperate log) and without vpn.

hope it helps, i dont understand it. i only see quite a lot packet loss on a level3.net hop and the last cloudflare hop without vpn,

and a lot of packet loss on the cloudflare-ion.cdn77.com hop with proton (which somehow kept beeing stable anyway, seems proton was skipping the clourflare hop after a few trys )

with cloudflare vpn… you see perfectly synced packet losses… 100% loss every nearly perfect 3 Minutes and 30ish seconds (when it initially connects to MUC, on FRA just ping spikes, but not a single packet loss.

– i mean thats what i -someone without any knowlege see watching the log

didnt see any changes at the ips, only a hop dissapearing some times. - but that should be already in the previous sended logs.

so i guess my job is done, i stick with proton for now, hope the best, and hope… who or whatever… get fixed some time soon… feels a bit strange i need to use vpn just to avoid such problems xD.

but thanks for your help and for trying.
fly safe all ^^

Thanks for all the details; happy to hear that Proton VPN is working as a work-around for now. Connecting via Netherlands (most likely Amsterdam) is a good choice anyway since it’s on the route to London, where TQ is, and it is a big network hub. What the VPN does in this case is just to reroute your network traffic away from the problematic area, which appears to be somewhere in München.

2 Likes