AW: Kein Datendurchsatz beim versuch Videos aus der RING cloud zu laden

[#1]

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

[#2]

Ich vermute einen Engpass zwischen Peering Partnern, entweder zw. Telia und DTAG oder Telia und deinem Hoster.

[#3]

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?

[#4]

---

@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⏎

[#5]

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...

[#6]

So, ich habe nun auch nochmal SpaceRobert getracert:

Routenverfolgung zu robertsspaceindustries.com [100.24.130.67]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 1 ms 1 ms 1 ms 62.155.243.110
3 7 ms 7 ms 7 ms f-ed12-i.F.DE.NET.DTAG.DE [62.154.3.101]
4 22 ms 22 ms 23 ms ffm-b4-link.telia.net [213.248.93.186]
5 116 ms 116 ms 116 ms ffm-bb3-link.telia.net [62.115.114.88]
6 117 ms 117 ms 117 ms prs-bb3-link.telia.net [62.115.123.13]
7 99 ms 100 ms 99 ms ash-bb4-link.telia.net [62.115.112.242]
8 116 ms 115 ms 115 ms ash-b1-link.telia.net [62.115.143.121]
9 113 ms 113 ms 113 ms vadata-ic-333121-ash-b1.c.telia.net [213.248.68.39]
10 * * * Zeitüberschreitung der Anforderung.
11 * * * Zeitüberschreitung der Anforderung.
12 * 113 ms * 52.93.28.252
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 ^C

[#7]

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

[#8]

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.

[#9]

Wow, danke für die ausführliche Erklärung.👍

[#10]

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]

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.

[#12]

Hallo zusammen,

der Datenaustausch zwischen den Netzen einzelner Internet-Serviceprovider erfolgt über Internet-Knoten. Dieser Zusammenschluss der Netze nennt sich Peering. Die Knotenpunkte haben eine begrenzte Bandbreite. In Abhängigkeit vom Datenverkehr und der verfügbaren Bandbreite an einem Knotenpunkt kann es zu Engpässen im Datenverkehr von einem Internet-Serviceprovider zu einem anderen kommen. So können unterschiedliche Downloadraten oder Antwortzeiten zu einem Dienst zu unterschiedlichen Tageszeiten entstehen, wenn der Datenverkehr über einen Internet-Knoten geführt wird.

Kommt es aufgrund von Überlastsituationen zu Engpässen bei Übergängen zu Providern, über die der Server erreicht werden muss, wird sich die Ping-Laufzeit verschlechtern, da Pakete am Netzübergang zum anderen Provider in einer Queue (Warteschlange) sequentiell abgearbeitet werden müssen. In einem solchen Fall sind wir bestrebt, mit dem jeweiligen Netzbetreiber eine Aufrüstung der Verbindungen zu erreichen. Eine einseitige Lösung allein durch die Telekom ist in einem solchen Fall nicht möglich. Lediglich das Umrouten des Verkehrs kann ggf. zu einer temporären Entschärfung der Situation führen. Kundenindividuelle Routenwechsel sind technisch nicht umsetzbar.

Bevor von einem Peeringproblem ausgegangen werden kann, sollten lokale Fehler wie gestörte DSL-Verbindungen oder Fehler im Heimnetzwerk (fehlerhafte Verkabelung, gestörtes WLAN, defektes Endgerät) ausgeschlossen werden.


Mögliche Fehlerbilder:
•Verlangsamter Seitenaufbau beim Abruf bestimmter Webseiten
•Störungen beim Abruf bestimmter Video- und Audiostreams (Tonaussetzer, Bildruckler, Verpixelungen, Abbrüche)(Achtung nicht bei Fernseh- oder VoD-Streams bei einem Entertainanschluß)
•Schlechte Performance bei bestimmten Gaming-Anwendungen (verspätete Reaktion auf Aktionen, Verbindungsabbrüche) - Lange Pinglaufzeiten zu bestimmten, nicht direkt an das Telekom-Netz angeschlossene Server (Richtwerte: innerhalb Deutschlands ca.30-70ms, Nordamerika Ostküste ca.120ms, Westküste ca.200ms). Bei extremer Überlast auf Peeringverbindungen können darüber hinaus auch Paketverluste auftreten
•Schlechte Downloadraten beim Dateidownload von bestimmten Servern bis hin zu Downloadabbrüchen

Wann können diese Symptome auf ein Problem einer Peeringverbindung zurückgeführt werden?
•Die o.g. Störungen treten nicht bei jeglicher Internetkommunikation, sondern nur bei bestimmten Zielen oder Anwendungen und auch nur zu bestimmten Zeiten auf.
•Die Fehler treten nicht einmalig, sondern regelmäßig über mehrere Tage/Wochen (evtl. nur zu bestimmten Zeitenwie z.B. 18-21 Uhr) auf.
•Peeringprobleme haben eine hohe Wirkbreite, daher kommt es in diesem Fall zu einer Häufung ähnlicher Probleme bei mehreren Kunden in gleichen Zeiträumen.
Möglichkeiten zur Analyse bzw. weiteren Eingrenzung:
Einen Traceroute zu dem betroffenen Server starten. Ist im Traceroute ein signifikanter Laufzeitsprung beim Übergang vom Telekom-Backbone zum Peering-Partner (erkennbar am aufgelösten Hostnamen oder Wechsel von IP-Adressbereichen) zu beobachten, deutet dies auf einen Engpass bzw. Performanceprobleme auf dieser Verbindung hin. Laufzeitsprünge hinter diesem Übergang liegen außerhalb des Einflussbereiches der Telekom und deuten auf Leitungsengpässe anderer Provider oder Serverprobleme hin.

Traceroutebeispiel mit Laufzeitsprung auf Peeringübergang:

C:\tracert www.cogentco.com
Routenverfolgung zu cogentco.com [38.100.128.10] über maximal 30 Abschnitte:
1 [1 ms [1 ms [1 ms speedport.ip [192.168.2.1]
2 19 ms 19 ms 19 ms 217.0.119.148
3 19 ms 19 ms 19 ms 217.0.86.86
4 20 ms 20 ms 20 ms f-ea1.F.DE.net.DTAG.DE [62.154.18.22]
5 465 ms 463 ms 464 ms po2-0.core01.fra01.atlas.cogentco.com [212.20.159.38]
6 465 ms 465 ms 465 ms po1-1.core01.fra03.atlas.cogentco.com [130.117.1.197]
7 466 ms 465 ms 482 ms te2-8.ccr01.fra03.atlas.cogentco.com [130.117.1.30]
8 465 ms 464 ms 466 ms te3-3.mpd01.fra03.atlas.cogentco.com [130.117.1.53]
9 466 ms 462 ms 461 ms cogentco.com [38.100.128.10]

Ablaufverfolgung beendet.

Traceroutebeispiel ohne Laufzeitsprung auf Peeringübergang:

C:\tracert youtube.de
Routenverfolgung zu youtube.l.google.com [208.117.236.69] über maximal 30 Abschnitte:
1 [1 ms [1 ms [1 ms speedport.ip [192.168.2.1]
2 19 ms 19 ms 19 ms 217.0.119.148
3 19 ms 19 ms 19 ms 217.0.86.86
4 20 ms 20 ms 20 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.161]
5 20 ms 21 ms 20 ms te-4-4.car2.Frankfurt1.Level3.net [4.68.110.253]
6 29 ms 20 ms 32 ms vlan99.csw4.Frankfurt1.Level3.net [4.68.23.254]
7 21 ms 20 ms 20 ms ae-92-92.ebr2.Frankfurt1.Level3.net [4.69.140.29]
8 29 ms 35 ms 35 ms ae-2-2.ebr1.Dusseldorf1.Level3.net [4.69.132.137]
9 32 ms 35 ms 35 ms ae-48-108.ebr2.Dusseldorf1.Level3.net [4.69.141.90]
10 33 ms 35 ms 35 ms ae-44.ebr1.Amsterdam1.Level3.net [4.69.141.74]
11 28 ms 32 ms 35 ms ae-46-106.ebr2.Amsterdam1.Level3.net [4.69.141.98]
12 46 ms 35 ms 36 ms ae-2.ebr2.London1.Level3.net [4.69.132.133]
13 105 ms 105 ms 105 ms ae-41-41.ebr1.NewYork1.Level3.net [4.69.137.66]
14 115 ms 108 ms 107 ms ae-71-71.csw2.NewYork1.Level3.net [4.69.134.70]
15 105 ms 105 ms 105 ms ae-24-79.car4.NewYork1.Level3.net [4.68.16.70]
16 110 ms 111 ms 111 ms GOOGLE-INC.car4.NewYork1.Level3.net [4.78.166.246]
17 118 ms 118 ms 118 ms 10.33.128.1
18 126 ms 126 ms 126 ms 10.33.254.170
19 182 ms 182 ms 180 ms 10.33.254.121
20 181 ms 183 ms 183 ms 10.33.254.130
21 184 ms 184 ms 184 ms 10.33.176.74
22 185 ms 185 ms 185 ms youtube.com [208.117.236.69]

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. Oft ist die Engstelle der Punkt (Hop), ab dem die Daten vom Netz der Deutschen Telekom an einen Partner übergeben werden oder dahinter. In den Beispielen sieht man, dass am 4. Hop(x.DTAG.DE) die Antwortzeiten noch gering sind und sich erst später, außerhalb unseres Einflussbereiches, erhöhen.

Viele Grüße
Oliver I.

[#13]

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

[#14]

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.

[#15]

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

[#16]

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.

[#17]

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