Äußerst langsame Verbindung zu github.com und ghcr.io
vor 4 Jahren
Hallo,
da ich mich hier im Forum neu angemeldet habe, möchte ich mich zunächst einmal etwas vorstellen.
Ich bin Blacky, ein
- Ehemann und Vater von 2 Kindern
- Besitzer eines Einfamilien-Hauses (Neubau 2014) in der schönen Wetterau (Hessen)
- DevOps Engineer (IT) in einem systemkritischen, großen deutschen Unternehmen (mit einer 7x24 Bereitschaft / Monat)
Ich mache seit Mitte März 2020 Homeoffice und nutze damit meine Internet Verbindung intensiv und dauerhaft.
Darüber hinaus lieben meine Familie und ich das Streamen von FullHD und 4k-Inhalten aus dem Internet (Netflix, Amazon Prime, etc)
Auf Grund meiner Tätigkeit als IT Fachkraft kenne ich mich ein wenig ( ) mit IT und Netzwerktechnik aus.
1 Problembeschreibung
Ich habe das Problem, dass ich sowohl beim Download von github.com
curl -Lo /usr/local/bin/talosctl https://github.com/talos-systems/talos/releases/latest/download/talosctl-$(uname -s | tr "[:upper:]" "[:lower:]")-amd64
als auch beim ziehen von Docker Images (im Grunde auch Dateien) von ghcr.io
time docker pull ghcr.io/talos-systems/talos:v0.8.0
nur auf Übertragungsgeschwindigkeiten im niedrigen zweistelligen KB Bereich komme. Da dieser Aufruf bis zum Ende der Erstellung dieses Postings nicht abgeschlossen werden konnte, kann ich hier auch keine Zeit liefern, kann ich aber gerne nachliefern (falls der Befehl nicht austimed)
2 meine Daten
- Vertrag
MagentaZuhause L mit MagentaTV Plus (100 MBit) - Qualität
gut bis sehr gut, in der Regel erreiche ich hier auch die zu erwartenden Download-Geschwindigkeiten. Latenz ist ebenfalls gut bis sehr gut. - Router
Fritzbox 7590 + per Gigabit-Lan verbundener Fritz Repeater 1750 - Geräte
- MacBook Pro 12 " (2019) - MacOS Big Sur und Catalina
- Dell XPS 13 (2018) - Linux
3 Eingrenzung des Fehlers
Das Problem besteht etwa seit Mitte Dezember, was sich mit mindestens 2 hier im Forum gefundenen und vermeintlich gelösten Problembeschreibungen deckt. (siehe Peering -zu-AWS-unwuerdig-fuer-einen-deutschen- ISP /m-p/4928104?search-action-id=259266655837&search-result-uid=4928104" target="_blank"> Peering zu AWS unwürdig für einen deutschen ISP und Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar )
3.1 Docker Pull aus Cloud
Als Vergleich mal der selbe docker pull Befehl von einer Maschine in der AWS Cloud (ähnliche Geschwindigkeiten erreichen auch Kollegen mit und ohne Telekom-Anschluss privat)
time docker pull ghcr.io/talos-systems/talos:v0.8.0
v0.8.0: Pulling from talos-systems/talos
bdcc44b11bd9: Pull complete
Digest: sha256:d813cf90ce6f57c72df3eb6ca8033a6b2ebaee89b64c3fcb0e2e4d26df4b256b
Status: Downloaded newer image for ghcr.io/talos-systems/talos:v0.8.0
ghcr.io/talos-systems/talos:v0.8.0
docker pull ghcr.io/talos-systems/talos:v0.8.0 0,06s user 0,02s system 0% cpu 10,248 total
Wie man sieht, dauert der Vorgang normal ca 10 Sekunden. Was bei einer Größe von 186 MB ok ist.
docker images | grep talos
ghcr.io/talos-systems/talos v0.8.0 3eaa04e179e4 13 days ago 186MB
3.2 lokaler docker pull von dockerhub
Als zweiter Vergleich mal ein Image mit ähnlicher Größe von dockerhub
time docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
6ec7b7d162b2: Pull complete
cb420a90068e: Pull complete
2766c0bf2b07: Pull complete
e05167b6a99d: Pull complete
70ac9d795e79: Pull complete
Digest: sha256:4cf620a5c81390ee209398ecc18e5fb9dd0f5155cd82adcbae532fec94006fb9
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest
docker pull nginx 0,13s user 0,07s system 2% cpu 9,770 total
docker images | grep nginx
nginx latest ae2feff98a0c 3 weeks ago 133MB
Wie man sieht, braucht hier meine lokale Maschine auch etwa 10 Sekunden. Das ist für 133 MB ok.
3.3 WLAN
Die Testgeräte sind normal mit dem Repeater über ein 5Ghz WLAN verbunden. Also wurde testweise das Linux-Notebook mit der Fritzbox direkt per Lan-Kabel verbunden, mit dem gleichen Ergebnis.
"Github / ghcr.io äußerst langsam, "alles andere" (gestetet mit docker pull von dockerhub, download von Programm-Dateien von verschiedenen Quellen) normal schnell
3.4 Anderer Telekom-Kunde
Um zu checken ob generell Telekom Kunden das Problem haben, hab ich einen Kollegen mit einem WIndows10 Rechner und Telekom Anschluss die gleichen Quellen benutzen lassen. Hier waren die Transferraten seinem Internet Anschluss angemessen
3.5 Fritzbox 7590
Die Fritzbox wurde mehrfach durchgestartet. WLAN und LAN Einstellungen sind auf maximale Leistungsfähigkeit gestellt, es gibt keine Filter, Beschränkungen oder sonst etwas. Da auch alle anderen getesteten Quellen funktionieren (incl. 4k Video Streams), schließe ich die Fritzbox derzeit als Quelle für die Beeinträchtigung aus.
3.6 Traceroute
Hier noch eine traceroute Ausgabe zu ghcr.io:
traceroute ghcr.io
traceroute to ghcr.io (140.82.114.34), 64 hops max, 52 byte packets
1 192.168.178.1 (192.168.178.1) 2.556 ms 1.780 ms 1.560 ms
2 62.155.246.34 (62.155.246.34) 7.525 ms 7.153 ms 7.424 ms
3 217.0.203.10 (217.0.203.10) 9.046 ms 9.145 ms 9.092 ms
4 80.150.170.214 (80.150.170.214) 7.849 ms 23.112 ms 7.691 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 209.66.120.181 (209.66.120.181) 102.966 ms 107.313 ms 114.360 ms
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
Leider konnte der Befehl bis zum Ende der Erstellung dieses Posts nicht abgeschlossen werden.
4. Dringlichkeit
Da unser Firma das Gro unserer IT mittlerer Weile in der AWS betreibt und zu großen Teilen auf modernste OpenSource Produkte setzt, die in unserem Fall häufig auf github gehostet werden, bin ich auf eine ordentliche Verbindung zu github und AWS dienstlich angewiesen. Bis Mitte Dezember konnte ich völlig frei von Verzögerungen Images ziehen, Repositories clonen und puschen und Programme herunterladen.
Falls also jemand noch Ideen zur Problem Lösung hat oder tatsächlich ggf. ein Bandbreiten / Peering Problem zwischen Telekom und x besteht, wäre ich dankbar, wenn versucht würde, mir schnellstmöglich zu helfen.
mfg
Blacky
2018
25
5 Sterne Mitgestalter
vor 4 Jahren
@Zandrael
Ich habe auch mal ein Traceroute auf die Adressen ghcr.io und github.com gemacht, so erst mal keine Auffälligkeiten, außer das eine andere Route als bei deinem Traceroute genommen wird. Bei dir scheint das irgendwie über USA zu gehen?
W:\Temp>tracert ghcr.io
Routenverfolgung zu ghcr.io [140.82.121.33]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms pfSense.localnet [192.168.1.1]
2 4 ms 4 ms 4 ms p3e9bf44a.dip0.t-ipconnect.de [62.155.244.74]
3 7 ms 8 ms 7 ms 62.159.98.206
4 14 ms 13 ms 13 ms 80.157.204.58
5 14 ms 14 ms 14 ms ae21.cr2-fra6.ip4.gtt.net [213.200.116.225]
6 24 ms 24 ms 24 ms 87.119.94.70
7 * * * Zeitüberschreitung der Anforderung.
8 * * * Zeitüberschreitung der Anforderung.
9 14 ms 13 ms 14 ms lb-140-82-121-33-fra.github.com [140.82.121.33]
Ablaufverfolgung beendet.
W:\Temp>tracert github.com
Routenverfolgung zu github.com [140.82.121.3]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms pfSense.localnet [192.168.1.1]
2 4 ms 4 ms 4 ms p3e9bf44a.dip0.t-ipconnect.de [62.155.244.74]
3 7 ms 7 ms 7 ms d-ed5-i.D.DE.NET. DTAG .DE [62.154.43.138]
4 13 ms 15 ms 13 ms 80.157.204.58
5 13 ms 13 ms 14 ms et-0-0-1.cr2-fra6.ip4.gtt.net [213.200.117.138]
6 25 ms 26 ms 26 ms 87.119.94.70
7 * * * Zeitüberschreitung der Anforderung.
8 * * * Zeitüberschreitung der Anforderung.
9 13 ms 13 ms 13 ms lb-140-82-121-3-fra.github.com [140.82.121.3]
Ablaufverfolgung beendet.
Ich nutze auch einen Telekom-Anschluss (Magenta XL).
1
Antwort
von
vor 4 Jahren
von unserer Seite gibt es keine Engpässe in Richtung Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Warum Amazon seinen Datenverkehr von der Ostküste darüber hinaus auch über andere Verkehrswege verschickt, können wir nicht sagen und ist die Entscheidung von Amazon.
Selbstverständlich befinden wir uns mit dem Anbieter in Gesprächen, um eine bessere Lösung für unsere Kunden zu schaffen.
Grüße Detlev K.
1 Sterne Mitglied
vor 4 Jahren
Ich habe die gleichen Probleme mit github. Ich habe auch das gleiche Fritzbox Modell. Auch der Zeitraum der ersten Probleme stimmt überein.
Kann das vielleicht an der Fritzbox liegen? War da nicht mal sogar ein Update im Dezember? Ich weiß leider sonst auch kein Rat mehr. Kann mit Github nicht mehr vernünftig arbeiten.
3
Antwort
von
vor 4 Jahren
Hallo,
bei mir hat der Wechsel auf 1.1.1.1 als dns server auch nicht geholfen, auch wenn ich jetzt vermeintlich andere vlt sogar bessere Routen bekommen.
Aktuell weis ich nicht weiter..
mfg
Blacky
1 Stern Mitgestalter
vor 4 Jahren
Da scheinst du wohl wirklich nur momentan ein Opfer von ungünstigen Peering zu sein, Ich habs eben auch mal laufen lassen über den (miesen) 6000er Anschluss...
3
Antwort
von
vor 4 Jahren
Hi,
zuerst wird gesagt, man ließe uns mit dem Problem, was offensichtlich bei vielen Leuten auftritt, nicht allein, und jetzt kommt die Meldung, dass die Telekom kein Problem hat, was impliziert, dass diese nicht mehr an einer Lösungserarbeitung beteiligt bzw. um eine bemüht ist.
Durch diese Probleme haben wir heute im Zwangshomeoffice mehr als 1 Stunde verschwendet, weil das gleiche Download-Performance Problem bei einem Kollegen aufgetreten ist (auch Telekom-Kunde), der ein simples 19 MB großes helm plugin installieren wollte, was leider (aus Sicht der Problematik) auf github gehostet wird. Am Ende haben wir frustriert aufgegeben, da durch Paketverluste ein Download von 19 MB ( ich wiederhole das, weil es 2020/2021 so völlig unverständlich ist, das sind Größen, die selbst bei ISDN kein Problem waren) nicht abgeschlossen werden konnte!
Github ist übrigens nicht "unser" Anbieter, sondern eine große, wenn nicht die größte Senke für Opensource Quellcode und Software weltweit. Das Problem besteht erst seit Anfang / Mitte Dezember und als einzelner User hat man hier quasi überhaupt keine Perspektive eine Besserung der Situation herbei zu führen. Das ist ungefähr so, als hätte man nur aus dem Telekom-Netz Verbindungsprobleme zu Wikipedia oder Youtube, und die Telekom sagt, "ei, kümmer dich selbst". "ei ja, wie denn?"
Aktuell ist meine Handlungsfähigkeit so stark eingeschränkt, dass ich wirklich darüber nachdenken muss , den Anbieter zu wechseln, da die Homeoffice-Situation noch eine ganze Weile weiter bestehen bleibt und auch darüber hinaus durch Corona sich nachhaltig die Denkweise bzgl. Präsenzarbeitsplätzen verändert.
Warum haben bisher nur Telekom-Nutzer diese Probleme, wenn kein Problem bei der Telekom vorliegt? Ja, nicht alle mir bekannten Telekom-Nutzer haben die Probleme, aber auch das Netz der Telekom (weil groß) wird nicht nur aus einem Netz bestehen. Da ist gut denkbar, dass nur Teile ein Problem haben.
Mit den hier im Forum vorhandenen (min. 3 Threads , mit meinem zusammen) sind genug Informationen, mit deren Hilfe mal die Technik / Fachabteilung eine Analyse fahren könnte. Gern biete ich auch an mich an einer Analyse zu beteiligen. Kommt auf mich zu, lasst mich einen / mehrere Requests machen und sehen was auf der Netzstrecke schief geht.
Aber bei der aktuellen Lage, dh. so wie sich das Problem für mich, für Kollegen und andere Forenteilnehmer hier darstellt, seid ihr als Telekom nicht ganz aus dem Spiel. Bitte nehmt eure Verantwortung als Provider wahr und versorgt uns (gerade jetzt in der Corona- / Homeoffice-Zeit) mit einer Internet Anbindung mit der wir barrierefrei wie Kunden anderer Provider wie Vodafone oder 1&1 auf Dinge im Internet zugreifen können, die heutzutage Gang und Gebe sind, und sorry, github gehört da einfach mit dazu.
Im modernen Enterprise / professionellen Bereich sind Anbieter wie github, aws, gcloud, azure, stackoverflow (
) und dockerhub essentiell wichtig und unerlässlich.
mfg
ein etwas, zugegebener Maßen angefressener Blacky
ps:
Und ja, die Nutzung eines VPNs, mit dem man "so tun muss" als käme man aus einem anderen Netz, damit man "richtrig" geroutet wird, ist für mich sicher als Workaround temporär akzeptabel, jedoch nicht auf Dauer und schon gar nicht professionell (weil Datenschutz etc) zu verantworten. Privat bin ich nach wie vor mit der Telekom zu frieden (auch wenn die Integration von Disney+ im Mediareceiver längst hätte ordentlich, dh, mittels App, abgeschlossen sein sollen), aber professionell / dienstlich bekomme ich langsam ein Problem.
Telekom hilft Team
vor 4 Jahren
wir sind aktuell weiterhin am Thema dran und lassen euch nicht damit allein. Zu diesem Thema haben wir seit einiger Zeit einen Beitrag https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung-hohe-PING-Zeiten/ta-p/4265259 zusammengestellt. Vielleicht erläutert dieser alles ein wenig. Bitte noch um etwas Geduld.
Grüße
Erdogan T.
1
Antwort
von
vor 4 Jahren
Erdogan, ich bin auch DevOps Engineer im Home Office und ich wuerde naechste Woche den Anschluss kuendigen, wenn das nicht besser wird. Ich brauche meinen Anschluss zum Arbeiten.
Warum werde ich ueber Amerika geroutet? Der Durchsatz liegt im Ergebnis bei wenigen Kilobytes pro Sekunde.
Telekom hilft Team
vor 4 Jahren
wir haben Neuigkeiten aus der entsprechenden Fachabteilung erhalten.
Es gibt keine Engpässe in Richtung Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Amazon ist das bekannt. Warum Amazon seinen Datenverkehr von der Ostküste darüber hinaus auch über andere Verkehrswege verschickt, können wir nicht sagen oder kommentieren. Es handelt sich hierbei um die souveräne Entscheidung eines eigenständigen Unternehmens. Für weitere Fragen zu diesem Thema wendet euch bitte an den Anbieter.
Grüße
Erdogan T.
4
Antwort
von
vor 4 Jahren
Guten Morgen,
oh, da hatte ich wohl nicht genau hingeschaut. Jedenfalls ist vor am 8.1. eine neue FritzBox Labor Version rausgekommen, die Download-Geschwindigkeitsprobleme mit einigen Seiten behoben haben sollte. Nach der Installation hab ich leider keine Besserung festgestellt.
Ich erwähne das nur hier, weil es vlt einem anderen möglicher Weise helfen könnte.
mfg
Blacky
2 Sterne Mitglied
vor 4 Jahren
habt Ihr eigentlich "Neu verbinden" versucht?
Ich verwende vor allem github regelmäßig.
Bei mir ist es so, dass ich nur diese drastischen Geschwindigkeitsprobleme habe, wenn mir eine IP im Bereich 84.166.166.* (oder vielleicht auch 84.166.*.*) zugeteilt wurde. Sobald ich nach "Neu verbinden" eine sonst übliche IP aus dem Bereich 217.* oder 93.* bekomme, ist das Problem nicht mehr vorhanden.
Definitiv weiß ich es bei den IPs 84.166.166.253, 84.166.166.81, 84.166.166.46.
Ich weiß noch nicht so lange, dass es an der IP liegt, da ich wie andere auch, das Problem irgendwelchen anderen Gründen zugeschoben hatte, da es erst sporadisch auftrat und sich außer bei Downloads als schweres Hakeln äußert (denn auch Webseiten-Inhalte hoppeln schon stark).
Das erklärt meines Erachtens auch, dass es nicht bei allen Telekom-Usern passiert. Wobei mir unklar ist, wie die Zuteilung erfolgt. Warum bekomme ich seit einiger zeit beinahe jeden Morgen diese IPs? (Zwangstrennung ist ca. 7:50)
Da es so klar an die IP gebunden ist, denke ich eher nicht, dass es generell am Peering liegt. Ich denke eher, dass irgendwas bei den betroffenen Bereichen anders konfiguriert ist. Also bitte Telekom, schaut doch mal nach, wo die Unterschiede liegen.
Mit traceroute habe ich übrigens nicht so wahnsinnig andere Zeiten, daran könnte ich den Unterschied nicht erkennen. ZUmal der ganze untere Teil sowieso aus Sternchen besteht, egal ob es schnell oder langsam geht.
An DSL liegt es definitiv nicht, denn ich kann gleichzeitig von anderen Servern mit voller Geschwindigkeit herunterladen, und das sogar mit fast 60000 bei einer 50000er Leitung. Ein alleiniger Download von github tut's davor und danach auch nicht (im unteren zweistelligen kb/s Bereich), es liegt also nicht an einem parallele Download, der was weiß ich für Wirkung haben könnte (wie man hört, bin ich die Lösungsansätze und später Ausreden der Telekom-Hotline satt, am Ende will man mir immer weismachen, es liegt alles an mir und meinem Router usw. und dann wird einfach aufgelegt, wenn man nicht selbst aufgibt).
Ich habe mir deswegen heute als Workaround einen nodered flow zusammengeklickt, der regelmäßig die externe IP des Routers abfragt ( FB 7530) und bei einer 84.166.* (vorsichtshalber) die Verbindung kappt, d.h. neu verbindet.
Das wiederholt sich so lange, bis die IP nicht mehr aus dem Bereich 84.166.* kommt.
Mal sehen ob es dann funktioniert.
6
Antwort
von
vor 4 Jahren
Der obige Proxy scheint nicht immer zu funktionieren, stattdessen aber dieser:
https://www.hidemyass.com/de-de/proxy
1 Sterne Mitglied
vor einem Jahr
Ich informiere mich grade ob andere anbieter noch Dual-Stack anbieten, bzw zumindest noch eine eigene ipv4 die nicht geshared ist.
Falls dem so ist, bin ich auch raus bei Telekom.
Telekom ist doch schon Teuerer für den Kunden als jeder andere Provider, da muss mann nicht noch versuchen geld mit Peering zu erpressen.
Bei nem anderen anbieter gibts diese Problematik mit ghcr/github und co nicht.
Die ultralangsamen nicht erklärbaren Downloadgeschwindigkeit sind mir schon seit längerem aufgefallen von bestimmten Servern/Seiten.
Einer der gründe warum ich bei Hetzner einen Dedizierten PVE-Server hab den ich als Proxy missbrauchen kann.
Aber das kann nicht die lösung sein, das ich für die Telekom einen Proxy brauche damit ich in normaler geschwindigkeit con Github Downloaden kann...
Das Witzigste ist aber auch das es nicht immer so ist, das ist sowas von random, mal lade ich ohne Proxy normal schnell, mal mit 56k Modem-speed.
Jedenfalls wird die Telekom nur auf eine weise lernen, nur mit massenkündigungen.
MFG
0