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
Hallo zusammen,
ich hoffe hier kann ich jemanden erreichen, der sich diesem Problem annehmen kann
Ich habe eine Ring Doorbell Pro bei mir daheim verbaut (seit einem Jahr) und nutze auch entsprechend die Ring cloud zum abrufen von den Videos der Doorbell.
Seit min. 4 Tagen besteht folgende Problematik:
Ich kann an mehreren Telekom DSL und Mobilfunkanschlüsen beobachten das beim Versuch Videos aus der Ring Cloud zu laden so gut wie kein Datendurchsatz vorhanden ist. Im selben WiFi an einem Telekom DSL Anschluss sowohl mit iOS als auch Android Geräten reproduziert. Im Aldi Talk Mobilfunknetz sowie Unitymedia Kabelnetz gab es keinerlei Probleme das Video zu schauen/herunterzuladen. Im Telekom Mobilfunknetz selbes Phänomen wie beim DSL. Auch das umstellen des DNS Servers auf den Google DNS brachte keine Lösung des Problems.
Ich habe WAN seitig einen Mitschnitt erzeugt und die Zieladresse scheint ring-untranscoded-videos.s3.amazonaws.com zu sein.
Ein traceroute brachte folgendes zutage:
traceroute ring-untranscoded-videos.s3.amazonaws.com traceroute to s3-1-w.amazonaws.com (52.216.206.139), 64 hops max, 52 byte packets 1 fritz.box (192.168.178.1) 2.307 ms 3.517 ms 3.079 ms 2 62.155.246.18 (62.155.246.18) 8.838 ms 7.352 ms 7.764 ms 3 217.239.46.18 (217.239.46.18) 10.054 ms 10.221 ms 11.109 ms 4 * * ffm-b4-link.telia.net (213.248.93.186) 30.431 ms 5 * ffm-bb3-link.telia.net (62.115.114.88) 123.463 ms 120.049 ms 6 prs-bb4-link.telia.net (62.115.114.98) 114.172 ms 115.294 ms prs-bb3-link.telia.net (62.115.123.13) 119.112 ms 7 ash-bb4-link.telia.net (62.115.112.242) 123.261 ms * * 8 ash-b1-link.telia.net (80.91.248.157) 121.824 ms ash-b1-link.telia.net (62.115.143.79) 115.863 ms ash-b1-link.telia.net (62.115.143.121) 125.419 ms 9 vadata-ic-333118-ash-b1.c.telia.net (62.115.11.183) 118.581 ms * vadata-ic-333119-ash-b1.c.telia.net (213.248.92.171) 119.592 ms 10 * * * 11 52.93.29.18 (52.93.29.18) 137.089 ms 52.93.29.12 (52.93.29.12) 122.374 ms 52.93.29.10 (52.93.29.10) 122.426 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * s3-1-w.amazonaws.com (52.216.206.139) 114.082 ms 115.577 ms
Auch beim pingen gibts verlorene Pakete, wobei dies nicht grundsätzlich unübliches ist.
Interessanterweise war es heute tagsüber völlig in Ordnung (sowohl bei mir, als auch bei einem Kollegen), seit heute abend ~17 Uhr geht wieder nix mehr.
Könnte sich bitte jemand aus der Technik mal anschauen was da los sein kann? Es kann ja nichts generelles mit der Verbindung zu AWS zu tun haben...dann würde das halbe Internet nicht funktionieren
Viele Grüße
Ahmed
28.10.2019 20:42
Ich vermute einen Engpass zwischen Peering Partnern, entweder zw. Telia und DTAG oder Telia und deinem Hoster.
29.10.2019 10:37
29.10.2019 10:47
@TimmS schrieb:
Ich habe das gleiche Problem seit ca. 7 Tagen. Die Videos buffern einfach elendig lange. Desweiteren habe ich Probleme ein paar Webseiten aufzurufen wie z.B. https://robertsspaceindustries.com/
Auch habe ich seit einer Woche Probleme Lobbies zu joinen bei Uplay-Spielen (mein Kollege, welcher auch bei der Telekom ist, hat auch seit einer Woche exakt die gleichen Probleme). Was hat die Telekom hier bitte umgestellt und vergeigt?
Hallo @TimmS,
gut zu wissen das es wirklich mehrere Nutzer betrifft. Weisst du zufällig welche DNS namen bei den Uplay Spielen genutzt werden? Wenn ja kannst du mal traceroute zu diesen laufen lassen? Ich habe mal ein traceroute zu robertsspaceindustries.com
laufen lassen. Je mehr Endpunkte wir finden und die zugehörigen Routen dazu, desto eher kann man vielleicht den kleinsten gemeinsamen Nenner finden (Knotenpunkt).
traceroute: Warning: robertsspaceindustries.com has multiple addresses; using 100.24.130.67 traceroute to robertsspaceindustries.com (100.24.130.67), 64 hops max, 52 byte packets 1 speedport.ip (192.168.2.1) 3.216 ms 3.129 ms 3.810 ms 2 62.155.246.174 (62.155.246.174) 12.622 ms 17.927 ms 13.529 ms 3 62.154.15.158 (62.154.15.158) 14.414 ms 13.494 ms 14.364 ms 4 ffm-b4-link.telia.net (213.248.93.186) 12.967 ms 13.596 ms 14.609 ms 5 ffm-bb3-link.telia.net (62.115.114.88) 116.924 ms ffm-bb2-link.telia.net (62.115.114.90) 118.396 ms 112.011 ms 6 prs-bb3-link.telia.net (62.115.123.13) 113.794 ms 115.036 ms prs-bb4-link.telia.net (62.115.114.98) 134.363 ms 7 ash-bb3-link.telia.net (62.115.122.159) 117.357 ms ash-bb4-link.telia.net (62.115.112.242) 120.256 ms 113.492 ms 8 ash-b1-link.telia.net (213.155.136.39) 112.339 ms 115.760 ms ash-b1-link.telia.net (80.91.248.157) 109.499 ms 9 vadata-ic-157233-ash-bb1.c.telia.net (62.115.9.70) 118.048 ms vadata-ic-333118-ash-b1.c.telia.net (62.115.11.183) 114.690 ms vadata-ic-333120-ash-b1.c.telia.net (62.115.11.249) 172.129 ms 10 * * * 11 * * * 12 52.93.28.206 (52.93.28.206) 137.861 ms 52.93.28.216 (52.93.28.216) 116.302 ms 52.93.28.232 (52.93.28.232) 108.034 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * *^C⏎
29.10.2019 10:50 Zuletzt bearbeitet: 29.10.2019 10:57 durch den Autor
Leider weiß ich nicht welche DNS von Uplay benutzt werden. Ich persönlich habe jedoch meinen umgestellt auf 8.8.8.8 und 1.1.1.1 und ergebnis war leider das gleiche...es hat nicht funktioniert. Ich kann maximal auch einen TraceRoute zu RobertSpace machen, aber dies geht erst heute Abend wenn ich zuhause bin. Aber mir scheint es sehr nach einem Telekom Problem auszusehen, da meine Kollegen im Telekom-Bereich die selben Probleme haben...und das obwohl wir 500 Kilometer auseinander wohnen.
*edit*
Was aber funktioniert hatte, als ich testweise einen VPN benutzt habe. Damit hat es funktioniert. Ist natürlich keine Lösung des Problems.
Siehe auch: https://telekomhilft.telekom.de/t5/Telefonie-Internet/60-80-Paketverlust-zum-Carrier-Telia/td-p/4239...
29.10.2019 18:04
01.11.2019 22:10
Hallo, hat sich bezüglich des Themas noch was getan. Ich habe die letzten 3 Tage mit dem Ring Support ohne Ergebnis gemailt, bis ich hier auf den Beitrag gestossen bin. Zur Zeit gehe ich über LTE oder mit Opera VPN auf Ring.com, um Events abzurufen. Leider bin ich nicht technisch so fit, um den kompletten Zusammenhang zu verstehen, aber Telekom scheint ja schuld zu haben und nicht Ring. Danke im Voraus
02.11.2019 13:19
Aktuell tut sich nicht viel. Betroffen sind alle Verbindungen von Telekom-Anschlüssen (auch Großkundenanschlüsse und T-Mobile) zu Systemen der Amazon Cloud (z.B. RING, GitHub und viele Andere). Ursache scheint ein Fehler oder eine Überlastung zwischen Telekom und Telia zu sein. Eine direkte Verbindung der Telekom zu Amazon gibt es - im Gegensatz zu vielen anderen Anbietern - nicht.
Kleiner Exkurs zur Technik: Im Internet sitzen verschiedene Firmen die eigene Netze betreiben - zum Beispiel eben die Telekom mit ihren Kunden und Amazon mit ihren Rechenzentren. Jedes Netz sollte am Ende zu jedem anderen Netz einen Weg finden. Hierzu nutzt man entweder einen "Internet Exchange", quasi ein großer Switch mit allen wichtigen Anbietern, oder - für noch bessere Leistung - eine direkte Verbindung.
Die hier genannten Verbindungen laufen hier über Frankfurt, vermutlich über den weltweit großten Internet-Exchange DE-CIX. Hier ist die Telekom leider nur mit 20GBit/s Gesamtkapazität vertreten (zum Vergleich: Die rote Kabelkonkurrenz liegt aktuell bei 900GBit/s). Die Telekom argumentiert, dass der DE-CIX unwichtig wäre, da man ja direkte Verbindungen zu wichtigen Netzen bieten würde.
Das ist pinzipiell auch korrekt, allerdings mit einem Haken: In der Branche ist "offenes Peering" üblich: Wenn Amazon und $Internetanbieter merken, dass sie viele Daten austauschen, setzt man sich zusammen, sucht einen Standort an dem beide vertreten sind und steckt da die Netze zusammen. Jeder zahlt dabei für die eigenen Router, der Datenverkehr ist ähnlich einer Flatrate. Haben ja schließlich beide was davon. Die Telekom macht sowas nicht, sondern gibt den Gegenstellen einen Standort vor (vorzugsweise dort, wo die Leitungen zum Standort bei der Telekom gemietet werden müssen) und lässt sich den Traffic bezahlen (Double-Paid-Traffic). Natürlich hat jetzt nicht jeder Anbieter Lust für Datenverkehr zur Telekom ein vielfaches der üblichen Preise zu zahlen, hierdurch gab es z.B. in der Vergangenheit immer wieder Probleme, z.B. was YouTube in deren Anfangsjahren lange Zeit aus dem Telekom-Netz nicht nutzbar. Vermutlich ist es auch hier so, dass Amazon diese Sonderbezahlung abgelehnt hat und es daher über die öffentlichen Austauschpunkte geht, bei denen die Telekom wie erwähnt nur sehr magere Kapazitäten besitzt.
tl;dr: Die Telekom hat absichtlich eher knappe Verbindungen zu allgemeinen Austauschpunkten und empfieht Betreiber von Rechenzentren kostenpflichtige Sonderverbindugnen zu kaufen. Der Kunde schaut in die Röhre.
02.11.2019 22:52
Wow, danke für die ausführliche Erklärung.👍
11.11.2019 11:37
Hallo,
gibt es zu diesem Thema schon weitere Informationen seitens Telekom? Das Problem scheint immer noch zu existieren. Gestern Mittag wieder nur Standbilder beim Abrufen aus der Ring Cloud. Interessant wäre zu wissen ob es sich tatsächlich in diesem Fall um ein Peering-Problem handelt…
Viele Grüße
11.11.2019 11:49
ich befürchte nicht...ich habe mit 4 verschiedenen Personen telefoniert. Die letzte Bearbeiterin hat sogar gesagt, dass nur noch Sie jetzt für mich Ansprechpartner ist und wollte am nächsten Tag nochmal bei mir anrufen...Pustekuchen. Sie hat nie wieder angerufen. Auch wurde mein Ticket einfach geschlossen. Auf meine Nachfrage hieß es, es gab Schwierigkeiten bei der Bearbeitung und es wurde ein neues Ticket dafür gemacht. Details würde ich per E-Mail bekommen. Pustekuchen²...es kam niemals eine E-Mail mit neuer Ticketnummer (wieder von besagter Dame).
Kurzum: Die Telekom ist einfach komplett inkompetent und ignoriert diese Probleme. Die Supporter können nicht helfen und lügenen einen an (Rufe wieder an, Ticket wurde nur neu geöffnet...).
Die Telekom verdient definitiv eine 6 als Schulnote. Das schlimme ist ja, man ist an die Telekom gebunden (zumindestens bei uns weil wir neu gebaut haben und es nur Glasfaser gibt). Ich sehne mich an meine Vodafonezeiten zurück...Mehr Speed für weniger Geld und da hat wenigstens alles funktioniert...Das gute ist, man kann hier im Forum komplett über die Telekom herziehen. Schaut ja eh keiner von denen rein...Armutszeugnis.
14.11.2019 17:09
16.11.2019 08:45
Hallo @Oliver I.
die Empfehlung einen Traceroute zu dem problematisch erreichbaren Server zu machen um die Ursache der Probleme zu erkennen ist leider falsch, da solltet Ihr den Textbaustein bitte dringend anpassen.
Warum?
Im Internet ist asymmetrisches Routing der Normalfall, d.h. während die Anfrage z.B. den Weg Telekom -> Carrier A -> Hoster nehmen kann, kann die Antwort den Rückweg Hoster -> Carrier B -> Telekom nehmen.
Macht man nun den Traceroute zu dem Server des Hosters, dann sieht man evtl. Latenzsprünge ab dem Übergang Carrier A -> Hoster, die jedoch tatsächlich auf eine Überlastung des Rückwegs zwischen Carrier B -> Telekom zurückzuführen sind, denn erst ab dieser Stelle nehmen die Pakete den problematischen Rückweg.
Die Empfehlung sollte also eher lauten, den Traceroute in Lastrichtung zu machen, also vom jeweiligen Server aus zum eigenen Anschluss, bzw. weil das im Normalfall nicht geht, beim jeweiligen Anbieter einen solchen Traceroute anzufordern. Erst damit ist eine sinnvolle Diagnose möglich.
Schöne Grüße
Daniel
18.11.2019 13:51
Hi @dw4817 ,
interessanter Einwurf. Und du magst da technisch durchaus recht haben.
Hm … in den letzten 20ig Jahren haben sich die Peering-Problem allerdings immer in beide Richtungen ausgewirkt und zu mindestens als grobe Eingrenzung der Ursache ist der Test eben doch ausreichend.
Viele Grüße
Alexander T.
18.11.2019 14:11 Zuletzt bearbeitet: 18.11.2019 14:13 durch den Autor
Hallo @Alexander T.
der Traceoute des Hinwegs eignet sich lediglich als Test ob ein Problem existiert, aber ein Rückschluß wo das Problem existiert ist damit nur in (für den Normalbenutzer nicht erkennbaren) seltenen Spezialfällen machbar.
Natürlich ist das Peering-Problem in beiden Richtungen sichtbar, die exakte Stelle des auftretens läßt sich jedoch mit einem Traceroute vom Endkunden zum Zielserver nicht feststellen, sobald zwischen Endkundennetz und Zielservernetz auf mindestens einer Richtung ein anderer Carrier im Spiel ist.
Beispiel:
Wenn ich ein Traceroute von meinem Telekom-VDSL-Anschluss zu meinem Mietserver bei Hetzner mache, dann läuft der Hinweg über AS3320 (Telekom), AS33891 (Core-Backbone) und dann AS24940 (Hetzner). Ab den Hops im AS24940 steigt die Latenz an. Eurem "Textbaustein" nach läge die Ursache am Übergang von AS33891 zu AS24940.
Untersucht man das ganze genauer, stellt sich aber heraus, dass die Ursache an einer Stelle liegt, die in diesem Traceroute garnicht auftaucht. Warum? Ab dem AS24940 nehmen die Antwortpakete einen anderen Rückweg, der im Traceroute nicht sichtbar ist.
Also machen wir einen Traceroutre vom Mietserver zum VDSL-Anschluss, der verläuft nun über AS24940 (Hetzner), AS1299 (Telia) und AS3320 (Telekom), die Latenzen steigen nun ab dem Übergang vom AS1299 in das AS3320 an. Wir haben also je nach Richtung des Traceroutes unterschiedliche Störungsstellen ausgemacht. Welche ist nun die Richtige? Typischerweise diejenige, die in Lastrichtung liegende, also der Übergang von AS1299 zu AS3320, den man beim von Euch empfohlenen Traceroute entgegen der Lastrichtung garnicht sehen würde.
Wir haben also zwei Kandidaten für die Störungsstelle und einen Verdacht (der Kandidat der auf dem Pfad in Lastrichtung liegt). Wie prüfen wir nun, welche von beiden Stellen es tatsächlich ist? Wir machen vom VDSL-Anschluss aus einen Traceroute auf einen Hop vor dem Übergang von AS1299 zu AS3320 im Netz von AS1299 und umgekehrt vom Server aus einen Traceroute auf einen Hop vor dem Übergang vom AS33891 zu AS24940 im Netz von AS33891. Bei einem von beiden treten nun die Probleme auf, beim anderen nicht.
Das Beispiel habe ich der Realität entnommen: Aktuell ist allabendlich der Übergang AS1299 zu AS3320 in Frankfurt überlastet, mit dem von Euch empfohlenen Traceroute ist das aber nicht feststellbar, im Gegenteil führt es den Kunden sogar in die Irre.
Erst mit einem Traceroute in Gegenrichtung und noch richtiger mit den zwei zusätzlichen Traceroutes findet man die eigentliche Störungsstelle.
Schöne Grüße
Daniel
18.11.2019 14:45
Hi @dw4817,
ist alles richtig.
Die Kernaussage die ich treffen möchte ist aber: Lieber Kunde, stelle fest ob das Problem ein Peering-Problem ist und wenn es das ist, dann brauchst du nichts tun, denn die zuständigen Menschen wissen schon längst das was los ist und eine Problembehebung dauert dann leider etwas.
Und für diese Kernaussage ist der Artikel vollkommen ausreichend.
Viele Grüße
Alexander T.
18.11.2019 15:11 Zuletzt bearbeitet: 18.11.2019 15:16 durch den Autor
Hallo @Alexander T.
wenn es nur darum geht, dass ein Peering-Problem diagnostiziert werden soll, dann finde ich aber folgende Sätze im Text falsch bis grob irreführend:
"Laufzeitsprünge hinter diesem Übergang liegen außerhalb des Einflussbereiches der Telekom und deuten auf Leitungsengpässe anderer Provider oder Serverprobleme hin."
"Wo genau es zu Engpässen kommt, kann man im Traceroute am besten daran erkennen, ab welchem Hop (bezeichnet den Weg über einen Router) sich die Laufzeiten signifikant erhöhen."
Unabhängig davon bin ich der Ansicht, dass der Kunde auch bei Peering-Problem durchaus seinem Anbieter Bescheid geben sollte. Sonst könnte beim Anbieter der Eindruck entstehen "das kriegt ja kaum ein Kunde mit, können wir also noch ein paar weitere Monate auf Anschlag laufen lassen". Rein aus der Churn-Rate kann ein Anbieter schlecht erkennen, warum Kunden wechseln.
Stell Dir vor, die Kundschaft eurer niederländischen Tochter T-Mobile Thuis hätte nach dem neulich stattgefundenen Depeering-Stunt (alles nur noch über AS3320, keinerlei Peering mehr in NL) nicht lauthals protestiert... dann wäre der desaströse Zustand dort noch immer so und man wäre nicht zum vorherigen, brauchbaren Peering zurückgerudert.
Schöne Grüße
Daniel
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.