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,
seit ca. einer Woche habe ich starke Probleme beim Zugriff auf Inhalte von Github / Amazon AWS S3. Es ist nahezu unmöglich größere Dateien herunterzuladen. Ich erreiche lediglich Geschwindigkeiten im einstelligen kb/s Bereich. Aufgefallen ist es mir nach der Neu-Installation meines Desktop Rechners und ich hatte erst vermutet es sei ein lokales Problem mit dem Rechner. Ich habe jedoch heute auch mit 3 weiteren Geräten im lokalen Netz das gleich Problem gehabt. Da das Problem nun an min 3 Tagen in der letzten Woche aufgetreten ist, und ich über z.B. LTE ordentliche Bandbreiten erreiche habe ich nun ein Problem mit dem Anschluss in Verdacht.
Die Generelle Bandbreite des Anschlusses ist i.O., lediglich mit S3 habe ich Probleme. Ich habe in älteren Posts von Problemen mit dem Peering gelesen, konnte dazu allerdings nichts aktuelles finden. Wie kann ich mein Problem lösen?
Gelöst! Gehe zu Lösung.
29.01.2021 14:15
@Thomas_Herrmann schrieb:
Bei mir auch Wirespeed, 11MB/s.
Danke Telekom/AWS/wer auch immer - auch wenn's lange gedauert hat.
@viper.de schrieb:
Bei mir ca. 9 MB/s an einem VDSL100, IP Adresse 91.23.xxx.yyy
@rtel schrieb:
Auf einmal 12.1Mb/sec anstatt zuvor 1-2 Kb. Kann bestätigen, dass es wieder schnell ist. Keine Ahnung, wer was genau gemacht hat, aber auf jeden Fall vielen Dank!
@soupdiver schrieb:
Ich kann von 84.161.x.x auch bestätigen, dass wieder >10MB/s durch die Leitung gehen.
Top!!... danke an die vielen sinnvollen Beiträge hier... und das ganze Gemecker vergessen wir mal
@tm_107 schrieb:
Hier auch wieder ordentliche Downloadgeschwindigkeiten ...
@Jaffi schrieb:
ES FUNZT WIEDER!!! FULLSPEED, DANKE!!! 🚀
@luddinho schrieb:
Auch ich kann von meiner Seite berichten, dass seit heute Nachmittag ca. 16:45 Uhr die Downloadgeschwindigkeit enorm zugenommen hat.
@Thomas_Herrmann @viper.de @rtel @soupdiver @tm_107 @Jaffi @luddinho Danke für die positiven Rückmeldungen und es freut uns, dass die von euch genutzten Dienste, die von Amazon gehostet werden, nun wieder in der gewünschten Geschwindigkeit zur Verfügung stehen. 👍 😊
@luddinho schrieb:Interessieren würde mich dennoch was im Hintergrund geschehen ist was zur Besserung beigetragen hat.
Wie zuvor erwähnt: Von unserer Seite gibt es keine Engpässe bezüglich der Verkehre mit Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Die Verkehrssteuerung obliegt am Ende aber Amazon selbst. Seit Anfang der Woche sehen wir wieder eine optimalere Verkehrsverteilung und sind guter Dinge, das damit die Probleme für unsere Kunden gelöst sind. Auch stehen wir mit Amazon in direktem Kontakt, um solche Vorfälle in Zukunft hoffentlich vermeiden zu können.
Liebe Grüße
Waldemar H.
19.01.2021 20:39 Zuletzt bearbeitet: 24.01.2021 14:52 von Stefan
Das Problem ist noch nicht gelöst!
Der Thread ist nur als "Gelöst" markiert, weil das die einzige Möglichkeit ist, Beiträge anzupinnen.
Es betrifft offenbar AWS-Server an der Ostküste der USA und Dienste wie github die dort gehostet werden.
Das aber nur bei Kunden der Telekom und bei Wiederverkäufern, wahrscheinlich auch bei Providern die Infrastruktur der Telekom nutzen.
Die grundsätzliche Ursache liegt wohl in der Route auf dem Rückweg.
(Posts mit Traceroutes in Hinrichtung nützen deswegen übrigens nichts)
Zur Stellungnahme des Telekom-Teams siehe anderer angepinnter Beitrag.
Außerdem fand ich diesen Beitrag in einem anderen Thread recht klar:
"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."
Die Rückroute geht im langsamen Fall z.B. über Cogent an die Telekom.
Die Anbindung ist wohl suboptimal um es nett zu sagen.
Warum dabei die Geschwindigkeit auf 1/100 bis 1/1000 sinkt ist [für mich] rätselhaft.
Eine Frage ist, ob die Ursachen in firmenpolitischen Zusammenhängen liegen, siehe interessante Links ganz unten.
Workarounds:
Von der IP die man zugewiesen bekommt, hängt offenbar das Routing ab.
Man kann versuchen, durch z.B. "Neu Verbinden" in der Fritzbox oder entsprechendes bei anderen Routern (ohne Trennen des DSL) einen anderen IP-Bereich zu bekommen.
Aber nicht jeder bekommt IPs aus mehreren Bereichen.
Bekannte kritische Bereiche:
79.192.0.0/10 (79.192.0.1 - 79.255.255.254)
80.128.0.0/11 (80.128.0.1 - 80.159.255.254)
84.128.0.0/10 (84.128.0.1 - 84.191.255.254)
87.128.0.0/10 (87.128.0.1 - 87.191.255.254)
91.0.0.0/10 (91.0.0.1 - 91.63.255.254)
93.192.0.0/10 (93.192.0.1 - 93.255.255.254)
...
scheint wieder zu funktionieren:
84.136.0.0 bis 84.191.255.255 (siehe Link unter Entwicklungen)
darunter 84.166.*.* aus eigener Erfahrung
anscheinend unkritisch:
93.* (ausgenommen obiger Teilbereiche)
217.*
...
(weitere bitte posten...wird ergänzt, wenn Zeit ist)
Durch einen Proxy oder ein VPN kann man ebenfalls einen anderen IP-Bereich bekommen und damit auch ein anderes Routing.
(ich denke, der Proxy/VPN darf dann selbst nicht bei der Telekom und in einem schlechten Bereich liegen, z.B. bei einem eigenen VPN-Server und auch nicht auf AWS us-east für die Verbindung zu Dir)
Kleine Zusammenfassung der "Lösungen" in einem älteren Post:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
zusätzlich für einzelne Dateien auch:
"der einfachste Workaround ist
diese URL aufrufen
https://hide.me/en/proxy
und da die eigentliche URL zu github einfügen.
Braucht kein VPN und kostet nichts -
für einzelne Dateien ist das nicht mal ein nennenswerter Mehraufwand - was an dem Problem nichts ändert"
(von Stefan)
Der obige Proxy scheint auch nicht immer zu funktionieren, stattdessen aber dieser:
https://www.hidemyass.com/de-de/proxy
Test der Rückroute:
https://mtr.sh
AWS US-OH Ohio für us-east
AWS US-OR Oregon für us-west zum Vergleich
oben eigene externe IP eintragen und "mtr" wählen
(interessanterweise ist US-VA, das ja auch an der Ostküste liegt mit kurzer Route)
weitere interessante Links/Posts:
Entwicklungen:
84.136.0.0 bis 84.191.255.255
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
Messung:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
(sehr interessant, mag etwas über die Ursachen aussagen)
bzgl. Route:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
bzgl. älterer Peering-Verwicklungen der Telekom:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
eventuelle Gegenargumente:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
zu Rückmeldungen von Amazon:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
Abhandlung der Telekom über Peering-Probleme:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung...
13.01.2021 10:35 Zuletzt bearbeitet: 18.01.2021 11:37 durch den Autor
der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen
oder falls es da Probleme gibt:
https://www.hidemyass.com/de-de/proxy
und da die eigentliche URL zu github einfügen.
Braucht kein VPN und kostet nichts -
Für einzelne Dateien ist das nicht mal ein nennenswerter Mehraufwand - was an dem Problem nichts ändert
17.01.2021 19:01
17.01.2021 20:06
17.01.2021 22:37 Zuletzt bearbeitet: 17.01.2021 22:41 durch den Autor
Wie oft muss eigentlich noch geschrieben werden, dass die traceroutes von euch _ZU_ AWS wertlos sind.Eure Seite der Autobahn Richtung AWS ist frei, ja das wissen wir. Auf dem Rückweg ist aber Stau...
Neueinsteiger finden das alles bei den 450 Posts nicht...
statt der "Lösung", die keine ist, sollte stattdessen eine Zusammenfassung angeheftet werden, wie z.B. diese:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
Wer kann das machen? Ich vermute mal, ich kann es nicht...
Oder vielleicht besser eine Link-Liste einiger Beiträge, wozu dann auch die jetzige "Lösung" gehört, wie auch der andere Beitrag vom Team.
Dann auch dieser:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
aber auch der:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
einfach damit das Thema von allen Seiten beleuchtet ist.
Und sorry, wenn da noch nicht alles dabei ist, ich hab noch weitere 100 Posts zu lesen...
17.01.2021 23:06
@Stefan schrieb:Wenn also irgend eine Webseite auf der Welt aus technischen Gründen ausfällt, dann hast du ein Sonderkündigungsrecht nach setzen einer Nachfrist. Eher nicht.
zu dem Beitrag hast Du soweit ich bisher (bis etwa Beitrag 350) gelesen habe, noch nichts gesagt...
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
der deutet meiner Meinung nach schon auf eine bewusste Reduzierung der Bandbreite hin.
Da fällt übrigens auch das Stichwort Netzneutralität...
Das wiederholte Herunterbeten des Arguments, dass der Vertrag letztlich nur die Leitung vom "Internet" zu meiner Wohnung beinhaltet, mag vielleicht juristisch so sein, ist aber nach meinem Verständnis zu naiv.
Es gehören sicher auch die Anbindung an die Infrastruktur und das geeignete Vorhalten derselben sowie das Peering dazu.
Sonst wäre es ja möglich, die Leitung am Kasten auf der Strasse enden zu lassen.
Natürlich ist die Telekom nicht für die Server verantwortlich, die die Daten erzeugen und auch nicht für das Routing bis zum Telekom-Netz (soweit sie keine Einfluss darauf haben), wohl aber für die Bekanntmachung von Zugängen und auch für passend große Türen.
17.01.2021 23:15
@hg42 schrieb:
Da fällt übrigens auch das Stichwort Netzneutralität...
das Stichwort fällt mehrfach, ändert aber nichts daran dass es falsch ist und lediglich zeigt das nicht verstanden wird was Netzneutralität bedeutet.
17.01.2021 23:19
@hg42 schrieb:
Natürlich ist die Telekom nicht für die Server verantwortlich, die die Daten erzeugen und auch nicht für das Routing bis zum Telekom-Netz (soweit sie keine Einfluss darauf haben), wohl aber für die Bekanntmachung von Zugängen und auch für passend große Türen.
Darum geht es doch, die Tür zur AWS ist nach Aussage der Telekom da und auch groß genug.
Dass passt ja auch dazu, dass es nachweislich nur ein Teil der Telekom Kunden trifft.
Wer nun dafür verantwortlich ist, dass die Daten beim anderen Teil durch den Kriechgang kommen ist genau zu klären.
Ich weiß es nicht und ihr halt auch nicht, ich habe hier nie etwas anderes geschrieben,
Die zitierten Probleme aus der Vergangenheit sind mir bekannt. Und ich kenne auch die kontroversen Diskussionen über die Peering Politik der Telekom. Die Wahrheit dürfte wie oft in der Mitte der Argumente liegen.
18.01.2021 11:04
18.01.2021 11:15
18.01.2021 11:18
ich habe den Workarround mittels Proxy nun als "Lösung" oben angepinnt, mit dem Ziel, dass sie für Neueinstieger für die diese langt einfacher zu finden ist.
18.01.2021 11:29
18.01.2021 11:38 Zuletzt bearbeitet: 18.01.2021 11:38 durch den Autor
dann nutze diesen, habe ich gerade mit deinem Download getestet - hat funktioniert.
Die Alternative habe ich oben auch eingefügt.
https://www.hidemyass.com/de-de/proxy
18.01.2021 13:33
@der_Lutz schrieb:
@hg42 schrieb:
Da fällt übrigens auch das Stichwort Netzneutralität...das Stichwort fällt mehrfach, ändert aber nichts daran dass es falsch ist und lediglich zeigt das nicht verstanden wird was Netzneutralität bedeutet.
ich verstehe schon was Du meinst, aber ich bezweifle mal, dass das Wort so eindeutig definiert ist (nach welchem Standard? DIN? irgendein Gesetz? politisch), dass Du es in diesem Fall einfach so ablehnen kannst.
Ich betrachte es moralisch/sozial/gesellschaftspolitisch...ob das in Rechtsform schon so existiert oder durchgesetzt wird ist mir dabei egal, zumal es sich um Weltpolitik handelt.
Fakt ist doch, dass hier Preis-Politik durch Reduzierung der Bandbreite gegenüber bestimmten Peering-Partnern betrieben wurde (und vermutlich auch noch wird). Man könnte das übrigens auch verschleiern, indem man nur einen Teil der Pakete verlangsamen oder ähnliches, insofern sind Gegenbeispiele kein Gegenbeweis.
aus Wikipedia:
"Netzneutrale Internetdienstanbieter behandeln alle Datenpakete bei der Übertragung gleich, unabhängig von Sender und Empfänger, dem Inhalt der Pakete und der Anwendung, die diese Pakete generiert hat."
und komm mir jetzt nicht mit Wikipedia ist kein Standard...natürlich ebensowenig wie irgendeine andere Definition, aber immerhin in gewisser Weise ausdiskutiert.
Netzneutralität kann man also auf Inhalte beziehen oder auf Quelle und Senke.
Frage 1 ist dabei, ob das Generieren der Pakete nur am Ursprung passiert, oder ob es bei jeder Weiterleitung neu passiert.
Frage 2 ist, ob es bewusst geschieht.
Das bewusste Einschränken eines Partners betrachte ich als Diskriminierung.
Denn selbst wenn es sich dabei nur um das Einschränken einer Zwischenstation handelt (in dem Falle dass man nur den Ursprung als Generator akzeptiert), ist es eine Diskrimierung des gesamten Bereiches hinter dieser Übergabestelle, was im Grunde noch viel schwerer wiegt als nur eine einzelne Quelle. Es ist nicht eindeutig wo man dann die Grenze ziehen soll oder will. Faktisch werden wir in der Nutzung von github und Co. eingeschränkt mit der Aussage, dass die zuviel Verkehr generieren. Es wurde ja auch versucht die Quellen z.B. Youtube direkt abzuschöpfen, was meiner Ansicht nach sehr klar zeigt wie der Hase läuft.
Über die Absichtlichkeit kann man spekulieren. Die oben angeführten Sachverhalte aus der Vergangenheit zeigen aber, dass eine Absicht dahinter lag, es ist zumindest nicht auszuschließen, dass dies immer noch der Fall ist.
Insgesamt sehe ich übrigens das Problem gesellschaftlich auch nicht unbedingt bei der Telekom. Letztlich hat man einen Dienstleister irgendwo in der Welt und möchte ihn als Gesellschaft nutzen. Die Kosten für den Transport müssten also auf die Nutzer umgelegt werden. Wenn das System der Betreiber das nicht leistet, muss man sich fragen, was da falsch läuft.
Ich denke, dass die Telekom hier auf einem zu hohen Ross sitzt. Denn sie profitiert natürlich auch von den Inhalten. Wenn sie den Verkehr bezahlt haben möchte, müsste sie im Gegenzug auch für Inhalte bezahlen, die die Attraktivität von schnellen Anschlüssen bei den Kunden erhöht.
18.01.2021 13:42 Zuletzt bearbeitet: 18.01.2021 13:50 durch den Autor
Darum geht es doch, die Tür zur AWS ist nach Aussage der Telekom da und auch groß genug.Dass passt ja auch dazu, dass es nachweislich nur ein Teil der Telekom Kunden trifft.
gut, eine Tür ist da, eine andere ist aber zu eng...
warum nimmt Amazon nun die falsche Tür?
nach deren Angaben haben sie ja kein Interesse daran, einen langsamen Weg zu nehmen.
Fakt ist wie Du sagst, wir wissen es nicht und können es auch nicht herausfinden, z.B. weil uns auch gar nicht genug Information gegeben wird. Deswegen werden einige detektivisch tätig, um daraus die Ursache zu ermitteln, die man uns so genau nicht sagen möchte.
Übrigens: Fingerpointing betreiben sie nicht?
tun sie eben doch, denn "Amazon ist Schuld, wir können nichts machen" ist doch die Aussage.
Sie haben es ihnen gesagt und lehnen sich anscheinend zurück und warten. Da hätte ich dann doch gerne mal etwas mehr Transparenz...was war denn die Antwort von Amazon? gibt es das Problem nicht? ist es nicht lösbar? nur mit Beteiligung der Telekom? wollen sie nicht? Solange ich das nicht gesagt bekomme, verstehe ich das als Weigerung an dem Problem weiter arbeiten zu wollen. Die Dauer zeigt ja, dass es faktisch wohl auch so läuft. Wie berichtet wurde würden sie das Peering ja anpassen, wenn sie die entsprechenden IP-Bereiche wüssten.
Ich erwarte von einem Provider mit dem "besten Netz" und sowieso von einem der wesentliche Teile unserer Infrastruktur verwaltet, dass bei einem so gewichtigen Problem etwas mehr zur Lösung geschieht, und zwar ungeachtet dessen, wer dafür wieviel Schuld trägt (kein Fingerpointing!). Die Erfahrung zeigt, dass es bei sowas immer an mehreren liegt (z.B. könnte ja Cogent auch daran beteiligt sein). Wenn man sich zurücklehnt und wartet, passiert aber nichts. Aus Kundensicht sieht es jetzt seit geraumer Zeit genau nach Zurücklehnen aus, vielleicht lieg es an fehlender Berichterstattung/Transparenz, vielleicht ist es aber auch einfach so.
Warum hört man hier nichts mehr vom Team?
18.01.2021 13:56
Poste mal die ersten 3 Bytes Deiner IPv4-Adresse (z.B. https://www.wieistmeineip.de/, IPv4 steht oben rechts) - dann schaue ich bei AWS nach über welche Route die Adresse erreicht wird.
kannst Du bitte mal folgende testen?
sicher langsam (zumindest als ich sie hatte):
84.166.166.253
84.166.166.81
84.166.166.46
fraglich (ich hatte an dem Tag keinen Reconnect gemacht, vielleicht hab ich es aber auch nur nicht gerafft oder brauchte nicht von github):
84.166.166.220
vermutlich langsam:
84.166.172.249
sicher schnell:
217.228.111.248
93.233.195.170
18.01.2021 14:05
Bevor jetzt alle ihre Router so lange neu starten, bis eine "passende" IP-Adresse zugewiesen wird:Ein häufiger Re-Sync des Routers führt dank DLM (Dynamic Link Management) dazu, dass die Datenrate über einen längeren Zeitraum (1-2 Wochen) gedrosselt wird - besser ist es daher, nur die logische DSL/PPPoE-Verbindung über das Webinterface des Routers trennen und wieder aufbauen (in der Fritzbox im Menü Internet/OnlineMonitor/Neu Verbinden).
das hört sich nicht 100% eindeutig an...ich sag es nochmal anders:
"Neu Verbinden" in der Fritzbox liefert eine neue IP ohne dabei die darunter liegende DSL-Verbindung neu zu synchronisieren.
Danke für diese Info, denn ich mache letzteres, da besteht also keine Gefahr.
Heute habe ich übrigens 52x eine IP aus dem Bereich 84.166.*.* bekommen, nur die erste war 84.166.166.*
Das scheint mir fast Absicht zu sein. Vielleicht sollte ich das mal erweitern und wieder einen engeren Bereich ablehnen (also 84.166.166.*) und bei 84.166.*.* einen Geschwindigkeitstest machen (z.B. einfach in der wget Antwort "written" und "MB" suchen).
18.01.2021 14:07 Zuletzt bearbeitet: 18.01.2021 14:17 durch den Autor
@hg42 schrieb:
gut, eine Tür ist da, eine andere ist aber zu eng...warum nimmt Amazon nun die falsche Tür?
Das ist genau die Frage.
Ressourcen werden immer dimensoniert, es legt ja auch kein Wasserwerk ein Rohr in dein Haus das 5000l/min liefert - für den Fall der Fälle. Und wenn bei korrekter Nutzung die andere Tür langen würde, wo ist dann das Problem? NE Ahnung was ein Hocheksitungsrouter kostet?
Die Telekom betreibt kein Fingerpointing - genau deswegen wirst du auf den Block der Fragen keine Antwort bekommen.
18.01.2021 14:10 Zuletzt bearbeitet: 18.01.2021 14:10 durch den Autor
@hg42 schrieb:
Heute habe ich übrigens 52x eine IP aus dem Bereich 84.166.*.* bekommen, nur die erste war 84.166.166.*
Das scheint mir fast Absicht zu sein.
Klar, bei jedem Anmeldevorgang poppt bei einem Telekom Mitarbeiter ein Fenster auf an dem er entscheiden kann
"Schnelles Peering" oder "den f... wir jetzt"
18.01.2021 14:50
@hg42 schrieb:
aus Wikipedia:
"Netzneutrale Internetdienstanbieter behandeln alle Datenpakete bei der Übertragung gleich, unabhängig von Sender und Empfänger, dem Inhalt der Pakete und der Anwendung, die diese Pakete generiert hat."
Genau, und wenn alle gleich langsam sind wird die Netzneutralität nicht beeinträchtigt, alles klar.
18.01.2021 15:19
@Stefan schrieb:ich habe den Workarround mittels Proxy nun als "Lösung" oben angepinnt, mit dem Ziel, dass sie für Neueinstieger für die diese langt einfacher zu finden ist.
das ist schon mal besser...allerdings beleuchtet das eben nicht die Sache von mehreren Seiten, so dass man sich immer noch verschaukelt vorkommt, wenn man mit dem Thread anfängt. Ich hatte ja schon Vorschläge gemacht, was da noch verlinkt werden sollte.
Vor allem gehört die Ausaage noch hinein, dass es eben keine richtige Lösung ist und dass die Sache nicht abgehakt ist sondern (laut Auskunft) noch dran gearbeitet wird
18.01.2021 15:21 Zuletzt bearbeitet: 18.01.2021 15:21 durch den Autor
@hg42 schrieb:
allerdings beleuchtet das eben nicht die Sache von mehreren Seiten, so dass man sich immer noch verschaukelt vorkommt, wenn man mit dem Thread anfängt.
Vor allem gehört die Ausaage noch hinein, dass es eben keine richtige Lösung ist und dass die Sache nicht abgehakt ist sondern (laut Auskunft) noch dran gearbeitet wird
Das ist aber auch nicht an mir als Telekom Kunde - wie du auch - dies zu tun
18.01.2021 15:40
@Stefan schrieb:
@hg42 schrieb:
Heute habe ich übrigens 52x eine IP aus dem Bereich 84.166.*.* bekommen, nur die erste war 84.166.166.*
Das scheint mir fast Absicht zu sein.Klar, bei jedem Anmeldevorgang poppt bei einem Telekom Mitarbeiter ein Fenster auf an dem er entscheiden kann
"Schnelles Peering" oder "den f... wir jetzt"
Menno...es ist genauso Absicht, wenn jemand einen bestimmten Algorithmus gewählt oder eingestellt hat.
Das ganze Routing basiert ja auf so etwas...
Es wäre ja sinnvoll, wenn man in kurzer Zeit ein Neu-Verbinden anstößt, dass dann mal ein anderes Netz genommen wird.
Ich denke schon dass es da balancing-Algorithmen usw. gibt.
Damit das klar ist, ich meine damit natürlich nicht, dass jemand mich absichtlich so behandelt.
Mir scheint gewisse Leute hier (ich nenn sie mal die Telekom-Verteidiger, das ist zumindest der Eindruck der entsteht, ob gerechtfertigt oder nicht) sind da ein bisschen zu empfindlich.
Es wird einem hier und da vorgeworfen, etwas Böses zu sagen, wenn man eine vielleicht nicht ganz so 100% durchinformierte Kritik äußert und sie sich vielleicht ein wenig nach Verschwörungstheorie anhört.
Es ist aber nunmal so, dass viele hier vorher mit Call-Center und Co. zu tun hatten. Da kann einem schon mal leicht der Kragen platzen.
Man hangelt sich da eine kleine Ewigkeit von einer angeblichen Lösung zur nächsten, und letztlich sind die meistens der Meinung, das Problem liegt beim Kunden. Irgendwann kommt dann auch, dass man ja einen eigenen Router verwendet.
Wenn man hartnäckig bleibt und sich nicht runterbuttern lässt, dann wird am Ende aufgelegt und die Störung z.B. als behoben markiert.
Man muss auch jedes Mal von vorne anfangen und erst Mal nachweisen, dass das Problem überhaupt am Routing liegt.
Tut mir leid, diese strukturelle Abschottung des Konzerns (egal ob GmbH oder AG oder was...) empfinde ich auch als Gewalt.
Es wäre ja nur als eine Vorgehensweise durchaus möglich, in den Datenbanken github/AWS einzutragen, zusammen mit einem Hinweis, dass es ein gültiges Problem ist und einen Link. Auf meine Störungsmeldung hätte ich eigentlich sogar nur eine E-Mail mit dem Link hier erhalten können, statt mich 30min mit der Hotline rumzuschlagen (zu dem Zeitpunkt wusste ich noch gar nicht, dass es telekomhilft überhaupt gibt, warum wird das nicht leicht zugänglich gemacht, wenn man eine Störung hat?).
18.01.2021 15:48
@hg42 schrieb:
Tut mir leid, diese strukturelle Abschottung des Konzerns (egal ob GmbH oder AG oder was...) empfinde ich auch als Gewalt.
Es wäre ja nur als eine Vorgehensweise durchaus möglich, in den Datenbanken github/AWS einzutragen, zusammen mit einem Hinweis, dass es ein gültiges Problem ist und einen Link. Auf meine Störungsmeldung hätte ich eigentlich sogar nur eine E-Mail mit dem Link hier erhalten können, statt mich 30min mit der Hotline rumzuschlagen (zu dem Zeitpunkt wusste ich noch gar nicht, dass es telekomhilft überhaupt gibt, warum wird das nicht leicht zugänglich gemacht, wenn man eine Störung hat?).
Da kann ich dir nur zustimmen.
Mit der internen Kommunikation hat es das Kommunikationsunternehmen Telekom nicht so. Ist ja nicht nur so dass damit Frust beim Kunden erzeugt wird, durch die Belastung der Call Center mit dieser Problematik werden ja auch Ressourcen verschwendet die in der aktuellen Lage, Shops geschlossen, dringend benötigt werden. Und damit den Frust bei Kunden mit anderen Problemen zusätzlich erhöhen.
18.01.2021 15:52
Genau, und wenn alle gleich langsam sind wird die Netzneutralität nicht beeinträchtigt, alles klar.
tja, es kann sein, dass Neutralität ihren Preis hat, genau wie Demokratie ihren Preis hat (deswegen ist sie z.B. auch anfällig gegen Angriffe von autokratisch organisierten Strukturen, da die nicht erst diskutieren müssen).
Wir reden hier aber von einer Reduktion auf 1/100 bis runter auf 1/1000 nicht nur von 1/2 oder so.
Eigentlich denke ich, dass überhaupt keine Route im Internat heutzutage soooooo langsam sein sollte.
Es kann einfach gar nicht sein, dass ein paar Megabyte 3 Tage dauern soll (was der Auslöser für meine eigenen Nachforschungen war).
Ich bin überzeugt ich kann 10x nach Amerika und zurück routen und wäre immer noch schneller.
Und wir reden hier zudem nicht von einzelnen Fällen sondern einer ganzen (und ich glaube auch sehr großen) Gruppe von Usern, die den Zustand dauerhaft haben. Ich selbst bin ja noch glimpflich davon gekommen, weil ich den IP-Bereich noch wechseln kann und zwei riesige Bereiche habe, wo es gut läuft. Die meisten dieser User werden es noch gar nicht auf solche Problem zurückgeführt haben und lasten es vielleicht der Überlastung des Netzes an oder so...ich wette sonst wäre der Ansturm noch größer.
Das Abblitzen lassen an der Hotline-Front führt vermutlich nicht zu einer Eskalation, weil ja z.B. in meinem Fall die Störung angeblich gelöst wurde und ein Thread wie dieser hier erscheint auch in der Statistik als gelöst...ein vermutlich vorhandenes internes Ticketsystem hat vermutlich den Zustand, Warten auf Amazon...
Folglich wird nichts wirklich neues passieren, befürchte ich.
18.01.2021 15:55
immerhin kannst Du aber einen Beitrag anpinnen...
ich denke wir sollten das hier mal selbst organisieren, weil es das Team ja nicht macht.
Ich hatte ja eine Beitragssammlung vorgeschlagen, das könne wir gerne ergänzen oder drüber diskutieren was da noch reingehört.
Das ist jedenfalls weniger frustrierend für Dich, als jedesmal wieder etwas schon vorhandenes zu einem neuen User sagen zu müssen, was Dich ja offensichtlich aufregt (und was ich irgendwie auch verstehen kann).
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.