Extremer TCP Packet loss & retransmissions ab nachmittags im peering zu AWS

Hallo Team,

 

da es für Störungsmeldungen keine Möglichkeit gibt, dieses Thema sinnvoll zu adressieren, möchte ich hier fragen.

 

Seit zwei Tagen habe ich über meinen Telekom-Anschluss ab nachmittags/abends extreme Probleme mit der Verbindung zu Authentifizierungs-Servern von PinOne, die laut IP locators in der Amazon Cloud liegen. Im Home Office arbeite ich über VPN. Aber der Traffic zu Cloud und Internetsiensten geht nicht über Ping. Ich konnte inzwischen eindeutig eingrenzen, das es weder an VPN, Firmennetzwerk, Laptop, Netzwerkkarte, OS liegt.

Stattdessen kann man zweifelsfrei zeigen, dass das Problem nur auftaucht, wenn ich statt über Fritz.box=>LAN/WLAN=>TelekomDSL gehe. Bei ansosnten exakt identischen Bedingungen über Vodafon-Hotspot taucht das Problem nicht auf.

In Wireshark kann man erkennen, dass im Vodafon-Pfad über Thelia die TCP-Kommunikation zum PingOne Server  52.34.194.98 ohne Probleme verläuft, während der gleiche Traffic im Telekom-Pfad zu 60-80% TCP retransmissions und damaged packages hervorruft.

 

Wegen dieses Problems, kommt die Multifaktorauthentifizierung oft erst nach 5Minuten oder aber einfach gar nicht mehr zustande, was extrem problematisch ist.

 

Pfad Telekom:

Routenverfolgung zu authall.idaas.pingone.com [52.34.194.98]
über maximal 30 Hops:

1 1 ms <1 ms 1 ms fritz.box [192.168.178.1]
2 8 ms 6 ms 6 ms 62.155.240.20
3 7 ms 7 ms 6 ms 217.239.55.22
4 6 ms 6 ms 5 ms 217.239.55.22
5 90 ms 90 ms 94 ms lag-10.edge4.Berlin1.Level3.net [4.68.73.5]
6 * * * Zeitüberschreitung der Anforderung.
7 215 ms 202 ms 202 ms 4.16.168.34
8 * * 191 ms 52.95.54.88
9 * * 251 ms 52.95.54.93
10 * * * Zeitüberschreitung der Anforderung.
11 * * 201 ms 54.239.44.34
12 * 271 ms * 54.239.44.119
13 * * * Zeitüberschreitung der Anforderung.
14 249 ms * * 52.93.14.162
15 283 ms * * 52.93.14.143
16 312 ms 306 ms * 52.93.14.142
17 * * 237 ms 52.93.14.175
18 212 ms 225 ms 304 ms 52.93.240.105
19 * * * Zeitüberschreitung der Anforderung.
20 * * * Zeitüberschreitung der Anforderung. =>abgebrochen

 

Pfad Vodafon:

Routenverfolgung zu authall.idaas.pingone.com [52.34.194.98]
über maximal 30 Hops:

1 1 ms 1 ms 1 ms 192.168.43.1
2 * * * Zeitüberschreitung der Anforderung.
3 38 ms 36 ms 33 ms 10.218.161.60
4 35 ms 35 ms 30 ms 10.218.163.137
5 32 ms 34 ms 35 ms 10.218.162.26
6 41 ms 39 ms 42 ms 145.254.2.215
7 * * * Zeitüberschreitung der Anforderung.
8 54 ms 47 ms 51 ms ae9-100-xcr1.hac.cw.net [195.89.99.1]
9 65 ms 66 ms 61 ms hbg-b1-link.telia.net [62.115.9.133]
10 345 ms 407 ms 408 ms hbg-bb3-link.telia.net [213.155.135.82]
11 383 ms 239 ms 370 ms ldn-bb3-link.telia.net [80.91.249.10]
12 350 ms 434 ms 191 ms nyk-bb2-link.telia.net [62.115.113.20]
13 191 ms 342 ms 204 ms sjo-b21-link.telia.net [62.115.119.229]
14 194 ms 393 ms 407 ms a100row-ic-300117-sjo-b21.c.telia.net [213.248.87.118]
15 297 ms 216 ms 205 ms 54.240.242.72
16 231 ms 284 ms 325 ms 54.240.242.81
17 * * * Zeitüberschreitung der Anforderung.
18 357 ms 407 ms 209 ms 52.93.130.2
19 * * * Zeitüberschreitung der Anforderung.
20 380 ms 407 ms 408 ms 52.93.12.80
21 374 ms 217 ms 393 ms 52.93.12.69
22 342 ms 407 ms 408 ms 52.93.12.32
23 229 ms 271 ms 211 ms 52.93.246.129
24 256 ms 409 ms 409 ms 52.93.246.39
25 * * * Zeitüberschreitung der Anforderung.
26 * * * Zeitüberschreitung der Anforderung. =>abgebrochen

 

Aus dem Firmennetz (über VPN und dann von innen wieder raus) ist der Pfad noch anders und hat auch keine Probleme.

 

So sieht der Traffic über Telekom zu der Adresse aus (Ausschnitt):

elfulus_1-1585340468222.png

..so über Vodafon zur selben Adresse:

elfulus_2-1585340505855.png

Könnte es sein, dass es ein Peering-Problem zwischen Telekom und AmazonCloud gibt?

 

Beste Grüße Marcel

 

 

@elfulus 

Probier ein MTR mit sehr vielen Paketen und schau ob dort (und wo) Paketverluste auftreten.

 

Davon mal abgesehen ist aktuell das Peering zu so einigen Anbietern stark ausgelastet. AWS ansich kann darunter gehören, denn das kann nicht im eigenen Telekomnetz stehen (im Gegensatz zu sämtlichen Streaming Diensten).

Die Community hier liegt aber auch auf AWS und da habe ich (momentan) keine Probleme.

@FelixKruemel 

@elfulus 

 

Ja, die ThC liegt auch in der AWS, allerdings habe ich seit 2 Tagen Peeringprobleme zur AWS und damit auch zur ThC, ich kann aber sagen, dass man dran ist.

 

Telekom hilft Team
Hallo @elfulus,

vielen Dank für die ausführlichen Beschreibungen.
Normalerweise würde ich jetzt diesen Link: https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung... als Lösung für dieses Problem nehmen.
Jedoch ist natürlich auch mit bewusst, dass dieser vor allem aufgrund der aktuellen Situation nicht wirklich weiterhilft bzw. überhaupt relevant ist.
Wie @Mächschen bereits sagte, sind die Probleme bekannt und wir sind an der Lösung dran.
Bis dahin muss ich leider um weitere Geduld und Verständnis bitten.

Viele Grüße und bleibt gesund.
Nico B.

Hallo Nico et.al,

 

das Problem taucht jeden Tag auf, bezieht sich aber ausschließlich auf das Peering über Level3. Es gibt andere unserer work from home user, die zwar bei Telekom sind, aber über Telia laufen. Die funktionieren etwas besser aber inzwischen haben sie das gleiche Problem und man kann auch dort oft kaum noch die Services in AWS nutzen (in diesem Fall z.B. wichtiger Authentifizierungs-Server).

 

Bei meinen Versuchen über das Vodafone-Netz (Handy als Hotspot) =>Telia läuft das wesentlich besser (gar kein Loss). Man kann also nicht pauschal sagen, dass die stärkere Auslastung des Netzes wegen Covid19/HomeOffice/Streaming etc. das alles erklären würde. Hier liegt m.E. relativ sicher ein Peering-Thema zwischen Telekom und AWS US area cloud vor, dass scheinbar immer über intermediate backbone provider läuft. Ich dachte, AWS sei direkt mit Telekom gepeert, aber vielleicht nur in Europa?

 

Kann der andere Teilnehmer (AWS) darüber entscheiden, über welche Route er in das DTAG-Netz kommt? Liegt, dass vielleicht auch etwas an double pay entrance fees für schnelle Zugänge zur DTAG?

 

Wie kann man es dann überhaupt adressieren? Ich versuche das gerade firmenintern (Großkonzern) über die Provider, aber mir scheint, dass dies womöglich ein ewiges Ping-Pong zwischen den verschiedenen Backbone Providern auf dem Rücken bereits für die Infrastruktur zahlender Kunden ist. Liege ich da falsch?

 

Beste Grüße... elfulus

 

Stand 30.3.2020 17:45Uhr

Via Telekom=>Level3:

elfulus_0-1585583677964.png

elfulus_1-1585583706848.png

 

via Telekom anderer AWS-Dienst im Firmenumfeld:

elfulus_2-1585583735676.pngelfulus_3-1585583748341.png

 

 

@elfulus 

Da der Engpass außerhalb des Telekom Netzwerkes liegt (Peering Level3 -- AWS) kann man hier wenig machen.

 

Warum nutzt man Server in den USA, bei Servern in Deutschland ist die Verbindung in der Regel besser.

 

Update:

vor ca. 20-30 Minuten gab es plötzlich eine andere IP für die Gegenstelle (same location auch AWS). Das hat kurzzeitig zu einem anderen Routing über Telia geführt=>packet loss dort Null!! Leider änderte sich die Adresse wieder zurück und seit dem läuft es wieder über Level3 mit den gleichen Problemen. Keine Ahnung, ob das nun temporär verändertes Load Balancing oder ein Versuch der Authentifizierungs-Firma (auch adressiert) oder der Telekom war.

 

Plötzlich andere Ziel IP=> alles gut über Telia! 😀

elfulus_0-1585588599722.png

elfulus_1-1585588609175.png

Zurück zu vorheriger IP und zum alten Verhalten über Level3 😣

elfulus_2-1585588863899.png

elfulus_3-1585588979606.png

 

 

 

 

@elfulus 

Die Telekom beeinflusst den Zielhost nicht.

 

Hallo Mächsen,

 

mir ist klar, dass die Telekom nicht den Zielhost ändert 😉. Wenn aber Routing-Pfade geändert werden, dann könnte sich ein Pfadkosten-optimierter Net Load Balancer auf der anderen Seite einen besser gelegenen Zielhost suchen. Insofern könnte es auch mit willentlich geänderten Routen zu tun haben (wenn auch unwahrscheinlich).

Ich würde auch die Aussage unterstützen, dass Bottlenecks zwischen Level3 und AWS kein Telekom-Thema sind. Habe das auch so zu den Providern der Zielhost-Services reflektiert. Allerdings bleibt für mich offen, ob sich etwaige "double pay" Einstiegskosten von AWS Europe in das DTAG AS auf deren Entscheidung auswirkt, lieber den Weg über AWS US=>Intermediate Tier1 (Level3/Telia/etc.)=>DTAG AS zu wählen. Anders kann ich mir nicht vorstellen, dass ein Dienst der in AWS mehrere load balanced in den Kontinenten hat, ausgerechnet den Weg US Server node=>AWS=>US=>Level3/Telia=>EU=>DTAG=>EU Client wählt statt EU Serve node=>AWS EU=>DTAG=>EU Client. Es sei denn, der Anbieter eines globalen Authentifizierungsdienstes hat seine Nodes nur in US aber nicht in EU.

 

Bester Gruß vom elfulus

  •  
Telekom hilft Team
Hallo @elfulus,

die Telekom hat mit allen großen Anbietern Absprachen und schaltet entsprechende Kapazitäten. Allerdings können wir nicht beeinflussen, wenn einige wenige dieser Betreiber ihre Verkehre so steuern, dass es zu Engpässen und damit verbundenen Störungen auch bei unseren Kunden kommen kann. An einer Kapazitätserweiterung wird mit dem Anbieter bereits gearbeitet.


Grüße Detlev K.

Inzwischen habe ich einen veritablen Überblick darüber, wo die Probleme auftauchen und wo nicht. Ich habe aus ganz Europa und Deutschland 20-30 IT-User Rückmeldungen inklusive Trace und Packet Loss Daten.

 

Die beschriebene Route zu AWS via Level3 wird scheinbar ausschließlich bei der Telekom im Raum Berlin advertised. Fast alle anderen User haben entweder Vodafon/Kabeldeutschland mit Telia-Routen oder auch Telekom aber trotzdem über Telia als Tier1-IP-Hop. Diese Routen sind zwar meistens deutlich länger (wesentlich mehr Hops als von Berlin über Level3) und langsamer (Responsezeiten) haben aber keinen oder sehr geringen Packet Loss. Interessanterweise gibt es noch einen User in Brandenburg, der über DNS.net auch direkt über Level3 läuft. Allerdings ist dies ein anderer Entry&Exit point bei Level3 und diese Verbindung ist zwar langsamer aber ohne Packet Loss.

 

Es scheint also sehr spezifisch um ein Routen-Advertisement im Bereich Telekom für den Raum Berlin zu gehen🤔.

Ich weiß nicht, ob man da an unserem Ende irgendwas feilen kann, würde aber gern verstehen, ob die Routenmetrik auch Bandwidth mit einbezieht, oder nur streng Pfadlängen-orientiert bzw. kommerziell beeinflusst ist?

 

Wenigstens habe ich mir inzwischen eine Umgehungslösung geschaffen, in dem ich diese Art Web-Traffic nur noch über das VPN ins Firmennetzwerk leite, in dem ich die Proxy-Autoconfig (die Internet-Traffic zum lokalen ISP schickt) abschalte und einen Ausgangsproxy aus dem Firmennetzwerk in USA manuell im Browser konfiguriert habe. Dann muss man aber auch immer im VPN sein, oder den Proxy hin-und her schalten.

 

Gruß vom elfulus