Deutsche Universitäten zur Prime-Time schlecht erreichbar (Paketverlust und Latenz ins DFN)
vor 6 Jahren
Hallo,
aktuell habe ich seit mehreren Tagen am Abend mit Paketverlust, hoher Latenz und extrem niedriger Downloadrate zu kämpfen. Während das das letzte Mal „nur“ bei Reddit und Imgur auftrat, ist dieses mal das X-WIN-Netz des DFN betroffen, über welches nahezu allen deutschen Forschungseinrichtungen angeschlossen sind.
Ich merke das vor allem dadurch, dass ich von zu Hause einige Dienste meiner Hochschule nicht sinnvoll nutzen kann (insb. Dienste wie die zentrale Dateiablage, wo größere Datenmengen ausgetauscht werden). Das sollte bei einer 100 MBit/s-Leitung aber eigentlich kein Problem sein und war es bisher auch nicht. Tagsüber geht es übrigens auch.
ping (10% Paketverlust):
PING www.tu-chemnitz.de(www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8)) 56 data bytes 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=1 ttl=52 time=69.1 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=2 ttl=52 time=71.5 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=3 ttl=52 time=69.2 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=4 ttl=52 time=71.8 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=5 ttl=52 time=69.9 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=6 ttl=52 time=70.7 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=7 ttl=52 time=68.6 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=10 ttl=52 time=71.2 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=11 ttl=52 time=71.2 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=12 ttl=52 time=71.1 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=13 ttl=52 time=70.1 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=14 ttl=52 time=71.7 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=15 ttl=52 time=72.1 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=16 ttl=52 time=70.7 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=17 ttl=52 time=71.7 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=18 ttl=52 time=70.0 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=19 ttl=52 time=69.1 ms 64 bytes from www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8): icmp_seq=20 ttl=52 time=70.2 ms --- www.tu-chemnitz.de ping statistics --- 20 packets transmitted, 18 received, 10% packet loss, time 19057ms rtt min/avg/max/mdev = 68.608/70.595/72.124/1.086 ms
Traceroute:
traceroute -6 -I www.tu-chemnitz.de traceroute to www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8), 30 hops max, 80 byte packets 1 gate.lan (2003:f4:e3e7:4b14:2099:d2ff:fe7b:xxxx) 0.499 ms 0.507 ms 0.505 ms 2 2003:0:8705:9000::1 (2003:0:8705:9000::1) 2.912 ms 2.933 ms 2.932 ms 3 * * * 4 2003:0:1403:c001::2 (2003:0:1403:c001::2) 25.005 ms 25.020 ms 25.018 ms 5 hbg-bb4-v6.telia.net (2001:2000:3019:6e::1) 58.089 ms 58.101 ms 58.101 ms 6 ffm-bb4-v6.telia.net (2001:2000:3019:6a::1) 58.100 ms 57.020 ms 57.597 ms 7 ffm-b12-v6.telia.net (2001:2000:3018:4a::1) 56.735 ms 56.002 ms 56.003 ms 8 * * * 9 * * * 10 cr-lap1-be7.x-win.dfn.de (2001:638:c:c019::2) 64.173 ms 64.194 ms 64.194 ms 11 kr-che35-3.x-win.dfn.de (2001:638:c:a0b3::2) 29.117 ms 28.555 ms 28.796 ms 12 2001:638:911:11::1 (2001:638:911:11::1) 69.017 ms 69.113 ms 69.123 ms 13 2001:638:911:16::3 (2001:638:911:16::3) 29.011 ms 29.203 ms 29.215 ms 14 www.tu-chemnitz.de (2001:638:911:b0c:134:109:226:8) 68.715 ms 68.684 ms 68.732 ms
Grottige Download-Geschwindigkeit über IPv6 und IPv4 (TU Chemnitz bzw. TU Dresden):
# wget http://ftp.tu-chemnitz.de/pub/linux/ubuntu-cdimage/releases/19.04/release/ubuntu-19.04-server-arm64.iso -O /dev/null --2019-07-09 18:17:55-- http://ftp.tu-chemnitz.de/pub/linux/ubuntu-cdimage/releases/19.04/release/ubuntu-19.04-server-arm64.iso Auflösen des Hostnamens »ftp.tu-chemnitz.de (ftp.tu-chemnitz.de)« … 2001:638:911:b0e:134:109:228:1, 134.109.228.1 Verbindungsaufbau zu ftp.tu-chemnitz.de (ftp.tu-chemnitz.de)|2001:638:911:b0e:134:109:228:1|:80 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK Länge: 788998144 (752M) [application/octet-stream] Wird in »»/dev/null«« gespeichert. /dev/null 0%[ ] 1,44M 49,8KB/s eta 3h 19m
# wget http://debian.inf.tu-dresden.de/debian-cd/10.0.0/amd64/iso-cd/debian-10.0.0-amd64-xfce-CD-1.iso -O /dev/null
--2019-07-09 18:23:46-- http://debian.inf.tu-dresden.de/debian-cd/10.0.0/amd64/iso-cd/debian-10.0.0-amd64-xfce-CD-1.iso
Auflösen des Hostnamens »debian.inf.tu-dresden.de (debian.inf.tu-dresden.de)« … 141.76.2.4
Verbindungsaufbau zu debian.inf.tu-dresden.de (debian.inf.tu-dresden.de)|141.76.2.4|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 672137216 (641M) [application/x-iso9660-image]
Wird in »»/dev/null«« gespeichert.
/dev/null 0%[ ] 1,52M 48,7KB/s eta 2h 46m
Meine Leitung:
100 MBit/s FTTH
Im übrigen betrifft das diverse Unis, vermutlich das gesamte Deutsche Forschungsnetz. Die Störung habe ich bei der Telekom schon gemeldet. Die Frage ist jetzt halt, ob das nur regional auftritt, oder ob die Telekom mal wieder nicht genug Peering -Kapazität bei Telia in Hamburg bereitstellt.
Potentiell relevant: Peering -Probleme-mit-Telia-und/m-p/3947378" target="_blank">https://telekomhilft.telekom.de/t5/Telefonie-Internet/Package-loss-zur-Prime-Zeit- Peering -Probleme-mit-Telia-und/m-p/3947378
2100
28
Das könnte Ihnen auch weiterhelfen
vor 5 Jahren
602
0
5
vor 2 Jahren
2254
0
5
vor 9 Jahren
11423
2
1
vor 2 Jahren
in
379
0
1
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 6 Jahren
Ich vermute mal ist wieder das alt bekannte Telia problem, da ich es auch bei anderen Seiten festgestellt habe, die aus dem Telia Netz kommen ^^v
0
vor 6 Jahren
kommt es aufgrund von Überlastsituationen zu Engpässen bei Übergängen zu Providern, wird sich die Ping-Laufzeit verschlechtern, da Pakete am Übergang zum anderen Provider in einer Warteschlange nacheinander abgearbeitet werden.
In einem solchen Fall versuchen wir mit dem jeweiligen Netzbetreiber eine Aufrüstung der Verbindungen zu erreichen. Eine einseitige Lösung allein durch die Telekom ist hier nicht möglich. Nur durch das Umrouten des Verkehrs kann es ggf. zu einer zeitweiligen Verbesserung der Situation kommen.
Individuelle Routenwechsel sind technisch nicht machbar.
Grüße Detlev K.
26
Antwort
von
vor 6 Jahren
@Detlev K."versuchen wir mit dem jeweiligen Netzbetreiber eine Aufrüstung der Verbindungen zu erreichen" – so kann man das auch schön reden. Den Kunden eine in den Abendstunden kaum nutzbare Leitung für um die 50 € verkaufen und dann die Schuld auf andere abwältzen. Sorry, so langsam ist das echt nur noch dreist, was die Telekom hier abzieht.
Die Probleme sind bei allen Usern die gleichen und die Praxis der Telekom ist hinreichend bekannt: Es werden die Kapazitäten für das Peering knapp gehalten, um dann erhöhte Preise zu verlangen: Peering -Problemen-2390214.html" target="_blank" rel="noopener nofollow noreferrer">https://www.heise.de/newsticker/meldung/Netzneutralitaet-Backbone-Betreiber-Level-3-aeussert-sich-zu- Peering -Problemen-2390214.html
Das ist eine bewusste Aushöhlung der Netzneutralität.
Auch ich habe das Problem gemeldet, nur um dann erstmal die üblichen (durchaus netten – also nichts gegen die Person selbst) Laien am Telefon zu haben, die mit Peering /Routing nichts anfangen konnten, nur grob das Prinzip eines VPN verstanden haben und am Ende (sinnloserweise) nach dem Routertyp zu fragen, nur um dann abermals auf dem Schlauch zu stehen (Ubiquity ist eine Firma? Sie haben ein extra Modem vorm Router?). Weshalb muss ich (als auch nur interessierter Laie, der bei einem Anruf auch nicht alle Infos sofort parat hat) da erstmal Basics erklären? Nach Rücksprache mit dem Techniker, kam man dann doch auf die Idee, dass ich Protokolle/Screenshots von den entsprechenden Problemen (bzw. der traceroute-Ergebnisse) anfertigen soll.
Ja super, nun muss ich wieder Aufwand betreiben für ein Problem, das längst bekannt und selbst von der Telekom provoziert wurde ... Es nervt nur noch.
Antwort
von
vor 6 Jahren
Meine gemeldete Störung ist natürlich auch versandet und das Supportticket geschlossen, ohne dass das Problem behoben wurde.
Aktuell sind verschiedene deutsche Universitäten für mich wieder kaum zu erreichen. Downloads von FTP-Servern verschiedener Universitäten krebsen mit 30 KB/s vor sich hin. Das schlimmste ist aber, dass ich dadurch am Telekom-Anschluss defacto keinen Zugriff auf für meine Arbeit relevante Forschungsdaten mehr habe.
Die Telekom sabotiert mit ihrem Peering -Verhalten damit aktuell die gesamte deutsche Forschungs- und Universitätslandschaft.
Mir ist kein anderer Internetprovider bekannt, der so ein dermaßen schlechtes Netz bzw. mieses Peering hat, wie die Telekom. Vor ein paar Monaten noch war es Fastly, aktuell ist es das Deutsche Forschungsnetz (ein gemeinnütziger Verein ohne kommerzielle Interessen und mit beschränkten finanziellen Mitteln). Ich bin mittlerweile auf 180 wegen diesen ständigen Schikanen und künstlichen Engpässen im Netz.
Ihr könnt euch sicher sein, dass ich aktiv Kunden von euch fern halte und jedem von eurem schlechten Peering erzähle. Ich selbst bin leider glasfasergeschädigt - sobald bei mir vor Ort im Glasfasernetz ein anderer Anbieter aktiv wird, bin ich auch sofort weg euch!
Uneingeloggter Nutzer
Antwort
von
Uneingeloggter Nutzer
Frage
von