crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
27.03.2020 21:23
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):
..so über Vodafon zur selben Adresse:
Könnte es sein, dass es ein Peering-Problem zwischen Telekom und AmazonCloud gibt?
Beste Grüße Marcel
27.03.2020 21:34
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.
27.03.2020 21:37
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.
28.03.2020 09:10
30.03.2020 18:01 Zuletzt bearbeitet: 30.03.2020 18:26 durch den Autor
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:
via Telekom anderer AWS-Dienst im Firmenumfeld:
30.03.2020 19:04
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.
30.03.2020 19:25
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! 😀
Zurück zu vorheriger IP und zum alten Verhalten über Level3 😣
30.03.2020 20:11
30.03.2020 21:43 Zuletzt bearbeitet: 30.03.2020 21:44 durch den Autor
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
31.03.2020 15:27
03.04.2020 14:22 Zuletzt bearbeitet: 03.04.2020 15:50 durch den Autor
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
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.