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,
da ich mich hier im Forum neu angemeldet habe, möchte ich mich zunächst einmal etwas vorstellen.
Ich bin Blacky, ein
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
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 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
06.01.2021 16:02 Zuletzt bearbeitet: 06.01.2021 16:03 durch den Autor
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).
06.01.2021 16:13 Zuletzt bearbeitet: 06.01.2021 16:14 durch den Autor
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.
06.01.2021 16:23
Die Fritzbox 7590 hat mit der Firmware 7.20/7.21 Probleme mit bestimmten DSLAM (Nokia und Broadcom) aber das ist eher in Stabilität und weniger in Bandbreite. Hier könnte man einen Versuch mit der 7.24-Labor probieren.
Probieren könnte man man andere DNS-Server (Z.B. 1.1.1.1 oder 9.9.9.9) für die Namensauflösung zu verwenden und sehen ob es damit besser läuft, weil sich ggf. andere Routen ergeben.
06.01.2021 16:29
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...
traceroute to ghcr.io (140.82.121.33), 30 hops max, 60 byte packets
1 _gateway (192.168.178.1) 1.082 ms 1.275 ms 1.446 ms
2 p3e9bf768.dip0.t-ipconnect.de (62.155.247.104) 85.859 ms 85.996 ms 86.013 ms
3 217.5.104.174 (217.5.104.174) 35.621 ms 217.5.104.182 (217.5.104.182) 35.797 ms 35.851 ms
4 62.159.61.230 (62.159.61.230) 38.136 ms 38.360 ms 39.626 ms
5 hbg-bb4-link.ip.twelve99.net (62.115.119.86) 42.087 ms hbg-bb3-link.ip.twelve99.net (62.115.120.70) 42.151 ms hbg-bb4-link.ip.twelve99.net (62.115.119.86) 43.966 ms
6 ffm-bb1-link.ip.twelve99.net (62.115.123.76) 43.903 ms 42.598 ms ffm-bb2-link.ip.twelve99.net (62.115.138.172) 44.802 ms
7 ffm-b1-link.ip.twelve99.net (62.115.116.164) 44.545 ms ffm-b1-link.ip.twelve99.net (62.115.137.165) 49.814 ms ffm-b1-link.ip.twelve99.net (62.115.120.207) 52.599 ms
8 github-ic-350972-ffm-b1.c.telia.net (62.115.182.171) 50.667 ms 49.501 ms 49.299 ms
traceroute to github.com (140.82.121.3), 30 hops max, 60 byte packets
1 _gateway (192.168.178.1) 0.858 ms 1.159 ms 1.609 ms
2 p3e9bf768.dip0.t-ipconnect.de (62.155.247.104) 25.564 ms 25.613 ms 26.188 ms
3 217.5.104.218 (217.5.104.218) 35.943 ms 37.585 ms pd900cbe2.dip0.t-ipconnect.de (217.0.203.226) 37.860 ms
4 62.159.61.230 (62.159.61.230) 39.263 ms 39.351 ms 40.121 ms
5 hbg-bb4-link.ip.twelve99.net (62.115.119.86) 44.831 ms 44.899 ms 45.218 ms
6 ffm-bb2-link.ip.twelve99.net (62.115.138.172) 45.638 ms 44.973 ms ffm-bb1-link.ip.twelve99.net (62.115.123.76) 44.462 ms
7 ffm-b1-link.ip.twelve99.net (62.115.120.215) 45.250 ms ffm-b1-link.ip.twelve99.net (62.115.116.158) 37.067 ms ffm-b1-link.ip.twelve99.net (62.115.120.219) 34.860 ms
8 github-ic-350972-ffm-b1.c.telia.net (62.115.182.171) 34.841 ms 32.803 ms 31.900 ms
06.01.2021 16:56
06.01.2021 18:50
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
06.01.2021 19:23
Das liegt am Telekom <-> Telia Peering in Frankfurt.
Ich habe einen Anschluss bei Ecotel und einen bei Telekom.
Beide laufen über den selben Telia Knoten in Frankfurt.
Beim Telekom Anschluss ist es langsam, bei Ecotelanschluss nicht.
Paketverlust ist laut mtr zwischen Telekom und Telia in Frankfurt.
Ich denke das liegt primär an der Peeringpolitik der DTAG. Die Telekom stellt Forderungen auf die andere Provider nicht bereit sind einzugehen.
Allein, dass ne Verbindung zwischen Telekom und AWS über Telia läuft sagt doch schon vieles aus.. AWS/Amazon und Telekom hatten ja mal ein direktes Peering.
Mögliche Abhilfe:
- VPN nutzen welches in einem Netz beheimatet ist mit dem Telekom und AWS ein gutes Peering haben
- Bei einem anderen Provider Kunde werden, der ein besseres peering mit AWS/Amazon hat.
06.01.2021 21:10
07.01.2021 10:13 Zuletzt bearbeitet: 07.01.2021 11:10 durch den Autor
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.
$ mtr github-production-release-asset-2e65be.s3.amazonaws.com -w -c 1
Start: 2021-01-07T10:12:02+0100
HOST: denkbrett52 Loss% Snt Last Avg Best Wrst StDev
1.|-- speedport.ip 0.0% 1 1.8 1.8 1.8 1.8 0.0
2.|-- p3e9bf2e7.dip0.t-ipconnect.de 0.0% 1 9.2 9.2 9.2 9.2 0.0
3.|-- 217.5.111.118 0.0% 1 16.3 16.3 16.3 16.3 0.0
4.|-- 80.156.162.178 0.0% 1 29.7 29.7 29.7 29.7 0.0
5.|-- if-ae-45-2.tcore1.fr0-frankfurt.as6453.net 0.0% 1 117.0 117.0 117.0 117.0 0.0
6.|-- if-ae-55-2.tcore2.pvu-paris.as6453.net 0.0% 1 120.2 120.2 120.2 120.2 0.0
7.|-- if-ae-49-2.tcore1.pvu-paris.as6453.net 0.0% 1 116.7 116.7 116.7 116.7 0.0
8.|-- if-ae-11-2.tcore1.pye-paris.as6453.net 0.0% 1 114.9 114.9 114.9 114.9 0.0
9.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
10.|-- if-ae-66-2.tcore2.nto-newyork.as6453.net 0.0% 1 118.4 118.4 118.4 118.4 0.0
11.|-- if-ae-12-2.tcore1.n75-newyork.as6453.net 0.0% 1 117.3 117.3 117.3 117.3 0.0
12.|-- 66.110.96.157 0.0% 1 119.3 119.3 119.3 119.3 0.0
13.|-- 52.93.31.39 0.0% 1 105.4 105.4 105.4 105.4 0.0
14.|-- 52.93.4.54 0.0% 1 107.6 107.6 107.6 107.6 0.0
15.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
18.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
20.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
21.|-- 150.222.243.215 0.0% 1 111.6 111.6 111.6 111.6 0.0
22.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
07.01.2021 18:27
07.01.2021 19:34
Bei mir ist das gleiche Problem seit Wochen. Ich kann keine Dateien von den Github-Assets Servern herunterladen. Die Datenrate ist teilweise null(!). Ich bin ziemlich gefrustet, sowohl über AWS, dass man in den USA dafür landet als auch über die Telekom, dass zu solch einem weitverbreiteten Cloud-Anbieter kein vernünftiges Peering besteht...
Ich behelfe mir für Github Downloads mit irgendwelchen Proxy-Anbietern und prüfe danach die Checksum/GPG Signatur.
07.01.2021 20:28 Zuletzt bearbeitet: 07.01.2021 20:35 durch den Autor
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.
08.01.2021 13:15 Zuletzt bearbeitet: 08.01.2021 13:15 durch den Autor
Erstaunlich guter Durchsatz heute!
08.01.2021 20:20
11.01.2021 16:10 Zuletzt bearbeitet: 11.01.2021 16:37 durch den Autor
Das war keine positive Meldung, das war ein Witz. Guck dir doch mal den Screenshot an. Es dauert mehr als eine Minute, die Kapazitaet einer 3,5 Zoll Floppy Diskette runterzuladen ...
12.01.2021 08:39
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
17.01.2021 00:12
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.
17.01.2021 00:22
17.01.2021 00:24
17.01.2021 00:50
das hört sich ja vielversprechend an. werde morgen mal meine ip-bereiche checken. Wenn ich von dir beschriebenne Bereichen liege, versuche ich es mal mit einem Reconnect. ( bzw. generell mal)
Wenn es an IP-Bereichen liegt, liegt der Ball ganz klar bei unserem rosafarbenen Lieblingsprovider.
mfg
Blacky
17.01.2021 21:35
17.01.2021 22:44
18.01.2021 15:21 Zuletzt bearbeitet: 18.01.2021 15:21 durch den Autor
Der obige Proxy scheint nicht immer zu funktionieren, stattdessen aber dieser:
https://www.hidemyass.com/de-de/proxy
18.01.2021 17:32
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.