BGP Flaps, Long-lived TCP Connections

Gelöst

Hallo,

 

seit ca. 4 Wochen hab ich regelmäßige Abbrüche beim Online-Spiel "EVE Online". Nach einigen Tests teilte mir der EVE Support folgendes mit:

"EVE Online requires a stable connection suitable for long-lived TCP connections. Which means no re-routing or BGP flaps."

Tatsächlich brechen diese TCP Verbindungen willkürlich nach wenigen Minuten einfach mal ab, das dürfte sich neben EVE auch z.B. auf SIP Verbindungen auswirken.

 

Das Thema BGP Flaps ist natürlich ein weites Feld und erfordert Menschen, die (1) wirklich Ahnung von der Materie haben und (2) den Willen, die Ursache zu finden und nicht nur alle Router zu resetten und zu denken, dass jetzt alles wieder gut ist. Hier können Router an ihre Speichergrenzen stoßen, MTUs irgendwo falsch gesetzt sein und 100 andere Dinge. Das Problem könnte auch bei einem Peer liegen, die Route geht über z.B. Level3:

 

> tracert tranquility.servers.eveonline.com

Routenverfolgung zu d638e439e07f413c97200d057e5ebd05.pacloudflare.com [172.65.201.188]
über maximal 30 Hops:

1 1 ms <1 ms <1 ms fritz.box [x.x.x.x]
2 10 ms 8 ms 8 ms x.dip0.t-ipconnect.de [x.x.x.x]
3 20 ms 20 ms 19 ms 217.5.110.150
4 27 ms 26 ms 27 ms 4.68.71.113
5 * 21 ms 19 ms ae2.3216.ear4.Frankfurt1.level3.net [4.69.210.66]
6 20 ms 19 ms 19 ms 195.122.183.210
7 20 ms 20 ms 19 ms 172.70.244.3
8 19 ms 18 ms 18 ms 172.65.201.188

 

Passende Lektüre:

https://de.wikipedia.org/wiki/Border_Gateway_Protocol#Route_Flap

https://routingcraft.net/how-to-troubleshoot-routing-protocols-session-flaps-part-1/

https://archive.nanog.org/meetings/nanog29/presentations/smith.pdf

https://cs.gmu.edu/~eoster/2019-795/2019-795-papers/BGP%20Anomaly%20Detection%20Techniques%20Survey....

 

Frage ist - wie bekommt man das an einen kompetenten Telekom-Support kommuniziert? Der telefonische Support will alles mögliche bei mir fixen, das Kabel auf dem Grundstück austauschen, die Telefondose - den Router hab ich angeblich zu schnell nach dem Ausschalten wieder eingeschaltet, etc pp. Es ist unmöglich zu vermitteln, was hier wirklich das Problem ist.

 

Wie man sieht, hat EVE Online nicht am eigenen "Peer" gespart, der traceroute endet nämlich bei einem Cloudflare server. "Gefixt" hab ich es daher dank anderer findiger Gamer mit dem Tool WARP von Cloudflare: https://1.1.1.1/
Das dabei hergestellte VPN kommt entweder mit den Flaps zurecht oder der falsch konfigurierte Router/Peer wird umgangen, da die Telekom ihr Cloudflare-Gate vielleicht woanders hat.

 

Hoffe dennoch, dass die Info mal bei der richtigen Abteilung landet und ernst genommen wird.

 

Grüße!

3 AKZEPTIERTE LÖSUNGEN
Lösung

Seit ca. 2 Wochen scheint das Problem nun endlich erstmal gelöst zu sein. Keine Rückmeldung bisher von DT, Level3 oder Cloudflare - aber hoffe mal, das Problem wurde tatsächlich behoben und ist nicht nur zufällig durch einen Router-Neustart o.ä. gelöst worden.

Lösung in ursprünglichem Beitrag anzeigen  

Lösung
Telekom hilft Team

Hello again,


heute gibt es schon weitere Neuigkeiten zu dem Thema.
Es wurden die Netzübergänge überprüft, es konnte an diesen aber keine Ursache für das Verhalten gefunden werden. Auch besteht vonseiten der Telekom keine Möglichkeit, auf die Steuerung dieser Einfluss zu nehmen.
Das Thema muss jetzt weiter zwischen EVE Online und Cloudfare geklärt werden.
Ich hoffe, dass hier bald eine Klärung erfolgen kann, damit EVE Online ohne Abbrüche gespielt werden kann.


Gruß Ingo F.

Lösung in ursprünglichem Beitrag anzeigen  

Lösung
Telekom hilft Team

Hallo in die Runde,

 

wir haben uns im Hintergrund einmal informiert und uns wurde mitgeteilt, dass hier schon ein Austausch zwischen EVE Online und der Telekom stattfindet, um diesem Verhalten auf den Grund zu gehen.

Uns wurde kein zeitlicher Ansatz genannt und auch keine weiteren technischen Details, aber das Thema ist bekannt und in Bearbeitung. Daher werde ich diesen Beitrag auch als Lösung markieren, damit andere User sehen können, dass dieses Thema schon an den richtigen Stellen platziert ist.

 

Euch noch einen schönen Abend.

 

Gruß Ingo F.

Lösung in ursprünglichem Beitrag anzeigen  

Ist halt kein Telekom Problem ... die nutzen das Peering was der Anbieter vorgibt. 

Level3 kann halt nen Problem sein, da die neben ner super ausgebauten Autobahn zum Telekom Netz auch ne billige Schotterpiste haben. 

 

Du kannst paar Pingplotter Traces machen und posten aber das Ergebnis wird sich nicht ändern.

Wenn dein Anschluss störungsfrei ist, wars das. 

Was außerhalb des Telekom Netzes passiert interessiert die Telekom nicht.

 

Kannst dir nur nen VPN Dienstleister holen und dir nen anderes Peering besorgen. 

Mhm, naja, der EVE support hat mir mitgeteilt, dass das Problem in Deutschland offenbar momentan tatsächlich nur Kunden der Deutschen Telekom betrifft und die DT angeblich auch in manchen Support-Anfragen schon erklärt hat, dass sie "aware" sind, aber noch keine Aussage über Korrektur-Zeitraum treffen können. Andere ISPs mögen andere Peers oder DECIX nutzen, klar...

 

Es sollte aber schon im Interesse der Telekom sein, das Problem anzugehen, denn langlebige TCP Verbindungen werden auch genutzt z.B. von IMAP, WebSockets, SIP, FTP, SSH, etc. Das mag eine Weile nicht auffallen - aber es kann genauso gut auch richtig eskalieren, z.B. keine störungsfreie Business Telefonie mehr.

Telekom ist nen Tier-1 Provider ... wenn CCP den größten Kundenstamm in Europa (das Telekom AS ist auch für deren Konzerneinheiten in den anderen Ländern da) erreichen will, müssen se halt bissel Geld in die Hand nehmen. 

 

Im Telekom Netz ist alles fein. CCP bzw. deren Provider muss schauen, was se da in deren Peering Bereich so treiben bzw. bestellen.

tranquility.servers.eveonline.com.png

Kann dir als Gamer nur raten, besorg dir nen VPN. (hier im Beispiel Surfshark)

tranquility.servers.eveonline.com2.png

Das Telekom Netz ist genial .. aber es gibt halt immer welche, denen der Kundenstamm egal ist und man auf ein günstiges Peering setzen. 

Gelöschter Nutzer

@CyberSW  schrieb:

Telekom ist nen Tier-1 Provider ... wenn CCP den größten Kundenstamm in Europa (das Telekom AS ist auch für deren Konzerneinheiten in den anderen Ländern da) erreichen will, müssen se halt bissel Geld in die Hand nehmen. 

 

Im Telekom Netz ist alles fein. CCP bzw. deren Provider muss schauen, was se da in deren Peering Bereich so treiben bzw. bestellen.

tranquility.servers.eveonline.com.png

Kann dir als Gamer nur raten, besorg dir nen VPN.

tranquility.servers.eveonline.com2.png

Das Telekom Netz ist genial .. aber es gibt halt immer welche, denen der Kundenstamm egal ist und man auf ein günstiges Peering setzen. 


Genau selbiges lief auch bei EA ab als ich dort gearbeitet habe Fröhlich Kunden abspeisen das es an deren Provider liegt Fröhlich 

Der macht blos nichts, Gaming ist kein Bestandteil des Vertrages, Internet und Telefonie ist störungsfrei nutzbar. Wenn ich dann lese das Kabel getauscht werden sollen schwillt mit der Kamm. Warum? Weshalb? Weil der Anbieter des Spiels sich nen fetten Geldbeutel machen will ?

@Gelöschter Nutzer  schrieb:
Wenn ich dann lese das Kabel getauscht werden sollen schwillt mit der Kamm. Warum? Weshalb? Weil der Anbieter des Spiels sich nen fetten Geldbeutel machen will ?

Naja das ist eher so nen Wissensthema .

Man ist ja froh, wenn die Leute den Layer 1 und 2 verstehen .. evtl. noch Layer 3. 

Aber vom Layer 4 und BGP werden die wenigsten was gehört haben, weil es auch nichts für den 1st und eigentlich auch nicht für nen 2nd Level Support ist. 

 

Das sind Aufgaben im Kernnetz ... und praktisch sprechen die Peering-Partner ja auch mit einander. Ist wie beim Mobilfunk, da bekommt es der Anbieter ja auch von allein mit, wenn die Antennen spinnen o. ausgelastet sind. Die Frage ist nur, was mit dem Wissen gemacht wird.

 

Wenn du jemanden der sich nur um L1 und L2 kümmert kommst und sagst, dass da was an der Verbindung zu langsam oder instabil ist, kommt der halt erstmal auf die Kabelidee. xD 

Richtig, danke. Und um es nochmal kurz zu sortieren - ich möchte wirklich nur das Thema adressieren und nicht tot reden bitte Fröhlich

 

- CCP nutzt cloudflare - wie man sieht. Ich sehe da jetzt kein "Sparen". BGP Flaps treten an den Routern zwischen den AS auf. Da der trace recht kurz ist, kann das eigtl. nur im Netz der DT oder zum 1. Peer, imho Level3 sein. Und zum Internet gehört auch Gaming, genau wie alle anderen Dienste, die long-lived TCP connections nutzen. Noch herrscht Netzneutralität. Möchte den Autofahrer erleben, dem die Karre alle 10 km abstirbt und der damit zufrieden ist, dass der Hersteller sagt: "Alle anderen fahren schließlich nur Kurzstrecke".

 

- Hier geht es ja nicht um Ping Zeiten.  Dass ein Level3 Router mal nicht auf meinen ICMP Ping antwortet, verüble ich ihm nicht, ist schließlich nicht wichtig. Pingplotter etc. zeigt keine Probleme mit BGP flaps. Dafür bräuchte man eben long-lived connections. Und die brechen dann halt einfach nur zusammen, mehr gibt es dabei von außen nicht zu beobachten. Das BGP Debugging kann nur von fachkundigem Personal an den Routern selbst erfolgen.

 

- Unser Kabel am Grundstück soll ruhig mal getauscht werden, denn spätestens seit sie meinem Nachbarn eine 250MBit Leitung aufgeschwatzt haben, während ich weiterhin die 100MBit nutze, stößt der alte verrostete Klingeldraht bei uns halt hochfrequenztechnisch an seine Grenzen. Das Thema haben wir seit Jahren und wenn einer der Techniker tatsächlich mal 200g Kupfer neu verlegt, hab ich nix dagegen. Schließlich hat der Telekom-Lobbyismus erfolgreich Glasfaser verhindert, dann müssen sie eben jahrelang den alten Kram supporten.

 

@F1osen  schrieb:
Tatsächlich brechen diese TCP Verbindungen willkürlich nach wenigen Minuten einfach mal ab

TCP-Verbindungen brechen nicht einfach ab.

Schon mal einen Netzwerktrace erstellt?

 

@F1osen  schrieb:
ich möchte wirklich nur das Thema adressieren

Brauchst du nicht, interessiert niemanden was außerhalb des Telekom Netzes passiert. 

Cloudflare gibt es von Schieberegler ganz links bis Schieberegler ganz rechts alles. 

Links sind die kleinen Preise, rechts sind die großen Preise. 

 

Genauso kannst es auch bei Level3 und Co bekommen. 

@wari1957  schrieb:

TCP-Verbindungen brechen nicht einfach ab.

Schon mal einen Netzwerktrace erstellt?

TCP Verbindungen brechen eben sehr wohl ab, wenn die Router Blödsinn machen. Packet drops durch BGP Flaps, MTU Blackholes, etc. - genau darum geht es in diesem Thread Fröhlich
Netzwerktrace? Das, was ich im 1. Beitrag gepostet habe? Ja

 

@CyberSW  schrieb:

Cloudflare gibt es von Schieberegler ganz links bis Schieberegler ganz rechts alles. 

Links sind die kleinen Preise, rechts sind die großen Preise. 

CCP dürfte bei Cloudflare den Schieberegler relativ weit rechts haben:
https://www.cloudflare.com/de-de/case-studies/ccp-games/

@F1osen  schrieb:
TCP Verbindungen brechen eben sehr wohl ab, wenn die Router Blödsinn machen. Packet drops durch BGP Flaps, MTU Blackholes, etc. - genau darum geht is in diesem Thread

Dafür werden die Pakete dann halt wiederholt.

Ich würde eher vermuten, daß ein überlasteter Spieleserver ein RST sendet.

 

 

@F1osen  schrieb:
Netzwerktrace? Das, was ich im 1. Beitrag gepostet habe? Ja

Das ist kein Netzwerktrace.

Schon mal WireShark benutzt?

 

@wari1957  schrieb:

Dafür werden die Pakete dann halt wiederholt.

Ich würde eher vermuten, daß ein überlasteter Spieleserver ein RST sendet.

Klar, TCP Pakete sollten anders als bei UDP neu versandt werden, richtig. Aber in diesem Fall wird eine offene TCP connection - die auf keepalives angewiesen ist - nicht bedient, weil die Pakete im Nirvana verschwinden bis die offene Verbindung eben dropped. Meist fällt das nicht auf, weil dann eben auf höherem OSI-Level, notfalls App layer, die Verbindung wieder geöffnet wird, z.B. bei IMAP. Das ist ja auch null zeitkritisch.

 

@wari1957  schrieb:

Das ist kein Netzwerktrace.

Schon mal WireShark benutzt?

Ah, jetzt verstanden. Wireshark würde mich auf meiner Seite auch nicht weiterbringen, weil ich eben nur den Drop sehe - im besten Fall. Wie gesagt - mit WARP VPN z.B. ist alles tadellos, d.h. das Problem entsteht bei einem BGP Router irgendwo zwischen meinem Einwahlpunkt und dem Cloudflare gate, vermutlich Telekom oder Level3. Ich hab aber auch noch keinen Tag investiert, bis ich in WS auf die richtige TCP Verbindung filtere, die dann irgendwann dropped.

@F1osen  schrieb:
Wireshark würde mich auf meiner Seite auch nicht weiterbringe

Na wenn du meinst ...

 

@F1osen  schrieb:
Ich hab aber auch noch keinen Tag investiert, bis ich in WS auf die richtige TCP Verbindung filtere, die dann irgendwann dropped

anders wirst du aber nicht rausfinden, warum die Verbindung "gedropped" wird. Eben deswegen:

 

@wari1957  schrieb:
daß ein überlasteter Spieleserver ein RST sendet

würdest du diese mit Wireshark finden zusammen mit allen PSH/ACK direkt vorher, wäre das ganze Thema mit dem Routing nämlich schon erledigt.

 

@F1osen  schrieb:
weil die Pakete im Nirvana verschwinden bis die offene Verbindung eben dropped

Das würdest du widerrum ebenso mit Wireshark sehen, ob dies wirklich so ist. Dann dürften keine ACKs mehr kommen und jede Menge Retransmissions zu sehen sein. Wobei dann trotzdem nicht klar ist, ob es der Hinweg, oder der Rückweg ist, welcher nicht mehr läuft.

Abgesehen davon das es kein "drop" bei TCP-Connections gibt ... diese werden entweder beendet (FIN), resetted (RST) oder timen einfach aus.

 

Dazu ist es bei "long lived" TCP-Connections (was für ein Buzzword, es sind stinknormale TCP-Verbindungen) vollkommen egal ob sich dabei zwischendurch die Route ändert, davon bekommen die Pakete gar nichts mit.

 

PS.: Beispiel für ein RST direkt vom Spiele-Server Fröhlich

https://telekomhilft.telekom.de/t5/Telefonie-Internet/TCP-Reset-Pakete-vom-LEVEL3-Server-warum-und-w...

Es ist schon richtig, dass man mit etwas Mühe diesen "Drop" an sich sehen könnte. In dem eingangs verlinkten Artikel sind ja auch die - von mir vermuteten - möglichen Ergebnisse schon beschrieben, samt Trace:
https://routingcraft.net/how-to-troubleshoot-routing-protocols-session-flaps-part-1/#BGP

 

Aber solange ich dadurch nicht herausbekomme, welcher Hop genau die Ursache ist, und ich diesen Router nicht debuggen kann, bzw. den Support dafür nicht ansprechen kann, was bringt es? Meine Hoffnung wäre ja, dass ein Telekom-Mitarbeiter hier sich der Sache tatsächlich mal annimmt.

 

Wie gesagt, nochmal - mit dem Cloudflare WARP VPN lande ich laut traceroute direkt bei dem Cloudflare Server, der auch am Ende des traceroutes über die Telekom/Level3 Server steht - und dann ist die Verbindung tadellos.

@F1osen  schrieb:
was bringt es?

Es bringt soviel, das du erstmal beweisen könntest, das es tatsächlich ein Problem in dieser Richtung sein könnte. Es wäre für Dich schlicht ein Argument. Ohne Mitschnitt ist es doch eher nur eine Vermutung. Seh es für Dich als Beweis, das es eben KEIN Reset der Gegenseite wegen Überlastung ist.

 

@F1osen  schrieb:
Meine Hoffnung wäre ja, dass ein Telekom-Mitarbeiter hier sich der Sache tatsächlich mal annimmt.

Also einfach eine "Vermutung" raushauen und andere die Arbeit machen lassen? Wenn du an die Experten ran willst, musst selber aber auch erstmal was liefern.

@F1osen  schrieb:
Nach einigen Tests

Bescheidene Frage ... was wurde denn da an Tests vollzogen?

@RoadrunnerDD  schrieb:
Bescheidene Frage ... was wurde denn da an Tests vollzogen?

Der EVE Support hatte mich z.B. ein Powershell script ausführen lassen. Das werde ich hier jetzt nicht anhängen, weil nicht mein geistiges Eigentum, aber es nutzt:

- Test-Connection

- Test-NetConnection f. traceroutes und tcp connections

- ping mit verschiedenen paketgrößen (mtu test)

@RoadrunnerDD  schrieb:
Seh es für Dich als Beweis, das es eben KEIN Reset der Gegenseite wegen Überlastung ist.

Warum sollte denn ein TCP RST schon ein Beweis sein, dass der Gaming Server überlastet ist? Ich hab daraus einfach keinerlei Info, was genau bei den Hops zwischendrin passiert.
Der Peer ist an der Stelle nicht direkt der Game cluster, sondern ein Cloudflare server, der - ich wiederhole mich - auch bei Nutzung des VPNs der gleiche Peer ist und dann tadellos funktioniert. Wir sprechen hier von einem etablierten MMO mit bald 20 Jahren Erfahrung nicht nur in Spieleentwicklung, sondern auch Connectivity. Wenn DoS-Attacken oder andere Störungen waren, ist CCP sehr offen damit umgegangen. Hier ist das Problem aber offenbar auf Kunden der DT beschränkt - und tritt auch zur entspanntesten Gaming-Zeit auf, eigtl. haben wir gerade AUTZ.

Was sollten mir denn nun die PSH, ACK Pakete sonst noch erzählen?

 

Der TTL ist einmal 57, einmal 58 - wenn ich das richtig sehe, wäre die Antwort mglw. von Level3 oder einem Cloudflare server - oder doch dem Router, der nie antwortet?

tracert tranquility.servers.eveonline.com

Routenverfolgung zu d638e439e07f413c97200d057e5ebd05.pacloudflare.com [172.65.201.188]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms fritz.box [x.x.x.x]
2 9 ms 8 ms 8 ms x.dip0.t-ipconnect.de [x.x.x.x]
3 21 ms 20 ms 19 ms 217.5.110.150
4 35 ms 26 ms 46 ms 4.68.71.113
5 * * * Zeitüberschreitung der Anforderung.
6 21 ms 19 ms 19 ms 195.122.183.210 https://www.findip-address.com/195.122.183.210
7 21 ms 20 ms 20 ms 172.70.244.3 https://www.findip-address.com/172.70.244.3
8 20 ms 18 ms 18 ms 172.65.201.188

 

Ich habe übrigens jetzt auch über den täglich geplanten Server-Neustart mitgeschnitten, selbst da kommen saubere FINs.

@F1osen  schrieb:
selbst da kommen saubere FINs.

Ich sehe da nur einen Reset.

 

@wari1957  schrieb:
Ich sehe da nur einen Reset.

Die beiden Screenshots waren von 2 verschiedenen Drops (ich hab 4 game clients gleichzeitig geöffnet, 2 wurden irgendwann geschlossen). Anbei noch die FINs für den Restart um 11:00 UTC.

@F1osen  schrieb:
Der TTL ist einmal 57, einmal 58 - wenn ich das richtig sehe, wäre die Antwort mglw. von Level3 oder einem Cloudflare server

Das zumindest siehst du falsch. Das RST-Paket mit TTL 57 entspricht genau deiner gezeigten Route. TTL 64 (vermutlich) minus der gezeigten 7 Zwischenstation sind 57 (die 8.Station ist der Sender, darf nicht mitgezählt werden). Somit kommt der RST vom Server selbst. Jetzt ist die große Frage warum ... wo der Grund aber so natürlich im Client-seitigen Trace nicht zu sehen ist. Eine Variante wäre, dass die Keep-Alive ACKs nicht zum Server durch kommen und er daher das RST sendet. Vielleicht gibts ja doch irgendwo einen Hopp welcher diese Pakete fehlerhafter Weise verwirft...

 

@F1osen  schrieb:
oder doch dem Router, der nie antwortet?

Es gibt genug Router im Netz, welche generell nicht auf ICMPs von irgendwo antworten. Warum auch, sie haben besseres zu tun

So viele Hops kommen ja gar nicht in Frage glücklicherweise - und die meisten sind noch im DT Netz. Wenn wir jetzt mal davon ausgehen, dass CCP und Cloudflare ihr Handwerk verstehen und das also nicht irgendein privat betriebener Mindcraft Server in Sibirien ist, dann gehe ich weiter davon aus, dass die DT oder Level3 hier irgendwo ein Problem haben.
Auf meiner Seite sehe ich eben keine Chance, mehr Infos zu liefern - außer ich fang jetzt an, passende Dienste auf Hosts zu suchen, die ähnliche Routen laufen und das gleiche oder eben kein Problem kriegen, Ausschlußverfahren.

@RoadrunnerDD  schrieb:
wo der Grund aber so natürlich im Client-seitigen Trace nicht zu sehen ist

Ich muss mal noch ein bisschen korrigieren (hab gar nicht so genau auf die Ports und Sequenznummern geschaut - sprich deine 4 clients ignoriert):

Im ersten Trace (2022-08-17 12_53_07-_Ethernet.png) sieht man eindeutig das Keep-Alive-Retry (2x Seq=321738) und das zugehörige RST mit Seq=321739

Heißt also: Dieser Keep Alive wurde neu gesendet, weil (vermutlich) verloren gegangen - und auch dieser Versuch kam nicht durch, weil RST vom Server direkt folgt. Richtig? Damit wären wir wieder beim Ausgangspost..

@F1osen  schrieb:
Damit wären wir wieder beim Ausgangspost

Allerdings gibts jetzt etwas schwarz auf weiß, vorher nur hätte/sollte/könnte.