Kein Datendurchsatz beim versuch Videos aus der RING cloud zu laden
vor 5 Jahren
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
783
16
vor 5 Jahren
Ich vermute einen Engpass zwischen Peering Partnern, entweder zw. Telia und DTAG oder Telia und deinem Hoster.
0
vor 5 Jahren
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?
14
Antwort
von
vor 5 Jahren
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
Antwort
von
vor 5 Jahren
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.
Antwort
von
vor 5 Jahren
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
Uneingeloggter Nutzer
Antwort
von
Uneingeloggter Nutzer
Frage
von