Verbindung zu Universitäten während Corona / Homeoffice nicht benutzbar

[#1]

Das Thema ist bekannt, die Telekom nimmt nicht am Peering mit dem Deutschen Forschungsnetz teil und deshalb ist die Verbindung für Telekom-Kunden zu deutschen Universitäten eine Katastrophe. Bei mir sind es gerade über Telia 29 kB/s bei 20% Paketverlust! Jeder der sich mit dem Thema befasst, merkt, dass ist weder ein technisches Problem noch bedarf es massiver langfristiger Investitionen. Es ist reine Politik. Für die technischen Details verweise ich auf dieses Thema.

Ich hoffe, dass heute jedem die gesellschaftlichen Konsequenzen klar werden. Jetzt wo das Internet so wahnsinnig wichtig ist uns zu verbinden. Stattdessen werden Studenten, Personal in der Lehre und Forschende massiv daran gehindert mit ihrer Hochschule in Kontakt zu bleiben, weiter zu lernen, zu lehren und zu forschen.

In den Medien wird diskutiert Netflix zu drosseln damit das Internet wichtigere Sachen machen kann, aber keine Sorge, zu Netflix sagt mein Speedtest 81 Mb/s - mehr als das hundertfache als zu meiner Uni. Ich kann parallel drei 4k Videos schauen, aber das Aufrufen der Corona-Info-Seite meiner Uni wird zur Qual. An produktives Arbeiten nachdem ich meine Tochter ins Bett gebracht habe ist nicht zu denken.

Ich appelliere an jeden der das hier liest, der nur einen Hauch von Einfluss hat. Setzt euch jetzt dafür ein dieses Problem zu lösen und wirklich Deutschland zu verbinden. Jetzt ist keine Zeit für Spielchen zur Profitmaximierung. Die Gesellschaft wird nicht so schnell vergessen welche Rolle die Unternehmen jetzt spielen. Es ist klar, dass das kurzfristig eine Herausforderung ist aber auch an den Unis sind die Admins und Netzer unentwegt im Einsatz um kurzfristig unkonventionelle Lösungen zu schaffen und ich bin überzeugt, dass auch bei der Telekom viele gute Leute arbeiten die hier eine Lösung finden können!

[#2 · Accepted solution]

Hallo zusammen!

Kurzes Update: Wir sind mit dem DFN einig geworden und berücksichtigen dabei sowohl die aktuelle Situation als auch den Umstand von Forschung & Lehre bei unseren Konditionen und stellen dafür entsprechende Kapazitäten zur Verfügung.

Liebe Grüße

Waldemar H.

[#3]

---

@direx  schrieb:
Man könnte sich jetzt natürlich fragen, warum hier der DFN-Verein nicht schon eher vielleicht auch mal auf politischer Seite um Hilfe gerufen hat. 

---

Genau das ist es.

Die derzeitige Situation hat ja nicht die Probleme beschert sondern nur offensichtlicher gemacht.

Das betrifft ja nicht nur das DFN, hier sind generell Weichen zu stellen und zukunftsorientierte Maßnahmen notwendig. Ich befürchte nur dass unsere Bundesregierung hier wie immer agiert und es keine greifbaren Ergebnisse gibt. Lieber werden die Netzbetreiber mit der nächsten Versteigerung gemolken statt die Gelder in die Infrastruktur zu investieren.

[#4]

---

@direx  schrieb:
Und Netflix und Twitch peeren glaube ich mit so ziemlich jedem, der nicht bei drei auf dem Baum ist.

Wenn es gratis/wirtschaftlich ist, sollen sie doch ruhig peeren. Es haben ja alle Seiten was davon (was die Telekom offenbar nicht verstanden hat).

---

Dass ein Peering mit Netflix und Twitch das DFN nichts kostet glaube ich nicht. Mag sein, dass sie denen nichts bezahlen. Aber da zum Peering immer zwei gehören muss das DFN da auch ein Interface/Gateway bereitstellen. Und der Videotraffic benötigt Kapazität im Backbone.

Dass Studenten im Wohnheim sich die Videos übers DFN reinziehen können - gut, wenn das zu Zeiten passiert wo sie nicht in Konflikt geraten mit solchen Leuten, die das DFN zu Forschungszwecken nutzen... aber ich als DFN würde in der Corona-Situation vermutlich Prioritäten setzen und zuerst mal die Verbindungen zu Netflix und Twitch sperren wenn es irgendwo Performanceprobleme gibt und testen ob/wieviel das hilft.

---

@direx  schrieb:

Dafür gibt es ja die CIXe und für Wald-und-Wiesen-ISPs halt die Global Upstreams. Vodafone ist hervorragend an DE-CIX, BCIX und eCIX angebunden. Warum sollten die dann noch direkt peeren (gut, machen sie ja jetzt mit Unity Media).

---

Direkt ist immer besser als Thromboning. Quasi Anwendung der Dreiecksungleichung im IT-Bereich.

[#5]

---

Dass Studenten im Wohnheim sich die Videos übers DFN reinziehen können - gut, wenn das zu Zeiten passiert wo sie nicht in Konflikt geraten mit solchen Leuten, die das DFN zu Forschungszwecken nutzen... aber ich als DFN würde in der Corona-Situation vermutlich Prioritäten setzen und zuerst mal die Verbindungen zu Netflix und Twitch sperren wenn es irgendwo Performanceprobleme gibt und testen ob/wieviel das hilft.

---

Das DFN verfolgt intern in etwa(!) den Ansatz "Sobald eine Leitung in Spitzenzeiten zu 3/4 ausgelastet ist, wird proaktiv erweitert", zumindest was das Kernnetz betrifft. Dieser sog. "Supercore" besteht derzeit aus 8 Knoten, die untereinander mit je 2x 100GBit-Verbindungen in einer Art Ring verbunden sind (ich glaube eine Ausbau auf 4x100 GBit ist geplant und vielleicht auch schon teils umgesetzt). Sieht man in der oben verlinkten Foliensammlung auf den Folien 12 und 13. Die weiteren Knoten des "erweiterten Kernnetzes" sind dann mit meist 100 Gig angebunden.

Da muss schon einiges passieren, damit dort Engpässe auftreten. Laut Aussage des DFN gab es bisher keine Engpässe, weder im DFN selbst noch an den direkten Aussenanbindungen, und sollten welche auftreten, wird halt erweitert. Die Technik dazu liegt als Reserve auf Lager und wartet nur darauf, zum Einsatz zu kommen. Sicher ist es nicht soviel, das man den Supercore auf einen Schlag verdoppelt oder so, aber es reicht locker, um an Engstellen schnell zusätzliche Kapazität zu schaffen.

Bei der "Telekom-DFN-Problematik" war es bisher so, daß die Übergänge von Telia und/oder CenturyLink zur Telekom überlastet waren. Da hätten diese beiden Provider ausbauen müssen, was ihnen aber entweder zu teuer war oder die Telekom es nicht wollte (oder auch beides, da gibt es verschiedene Aussagen, die sich nur schwer überprüfen lassen).

Die Verbindungen zu Netflix & Co bzw. der Traffic beeinflusst also nicht die Verbindungen zur Telekom (zumindest solange die Leitungen intern dick genug sind), weil sie über ganz andere Peerings laufen.

Davon trennen muss man allerdings die Anbindungen der einzelnen Einrichtungen zum DFN hin, für welche die Einrichtungen selbst die Verantwortung tragen - sowohl in der Ausgestaltung der dort verfügbaren Bandbreite als in einer Priorisierung des Traffics (sofern nötig). Wenn eine Hochschule meint, sie komme mit 1 GBit aus und lässt dann 1000 Studenten im Wohnheim ungebremst ans Netz, wird es eng. Dafür kann dann aber das DFN nix. Aber um diesen Fall gehts hier ja auch nicht.

[#6]

Seit heute scheint die Direktverbindung zwischen DFN und Telekom aktiv zu sein, die Route geht direkt von der Telekom ins DFN über ohne den bisherigen Umweg über Telia. Schauen wir mal, ob das Besserung bringt.

[#7]

Das sind ja gute Nachrichten. Laut meinen Logs läuft seit 9:00 die IPv4-Konnektivität direkt über die DTAG, IPv6 seit ca. 12:30. Bei mir sind es jetzt dadurch 3 Hops weniger. 😁

Was mich aber etwas wundert ist, dass ich noch immer eine relativ hohe Latenz habe:

• Latenz vorher über Telia (IPv6): zwischen 23 und 55 ms, teilweise auch hoher Packet Loss
• Latenz aktuell (Peering direkt, IPv6): 23 ms

Für eine Glasfaserleitung halte ich diese Latenz für ziemlich hoch. Zu anderen Seiten (Google, Heise, ...) habe ich einstellige Werte. Aber gegenüber der vorherigen Situation ist das schon Meckern auf hohem Niveau. Fühlt sich halt an wie eine DSL-Latenz 😂

Wir werden sehen, ob die Konnektivität jetzt flutscht. IPv6 bei Telia war z.B. gestern zwischen 10:00 und 23:00 extrem gestört, ich hoffe, dass solche Zustände jetzt der Vergangenheit angehören.

[#8]

@direx 

welche IP pingst du den mit der Latenz von 23ms

[#9]

@Stefan Habe es mit www.uni-leipzig.de versucht (regional nah an mir dran). Habe allerdings auch schon 13 ms Latenz zum ersten XWin-Knoten (cr-erl2-be8.x-win.dfn.de). Also 13 ms Latenz allein im Telekomnetz und dann nochmal 10 ms innerhalb des DFN.

Im Vergleich zum vorherigen Zustand nehme ich natürlich die Latenz gern in Kauf, aber etwas verwunderlich finde ich es schon. Zu YouTube habe ich aber auch 18 ms Latenz (spielt dort ja überhaupt keine Rolle). So schlecht scheint der Wert demnach auch nicht zu sein. Mich hatte halt gewundert, wie andere Webseiten wie Heise oder die Webseite der Stadtverwaltung einstellige Werte schaffen. Egal.

Achja, bin natürlich verkabelt.

PS: Deine 2ms beim Speedtest  (laut deiner Signatur) sind mal ne Ansage 🤣

[#10]

zur

uni Frankfurt 4ms

uni berlin 14 ms

uni Hamburg 15ms

uni Leipzig geht aktuell über be3186.ccr41.fra03.atlas.cogentco.com mit 12ms bis zum Ziel

[#11]

Danke, das sind wirklich sehr ordentliche FTTH-Latenzen. Du erreichst deinen X-Win-Knoten (kr-fra174-20.x-win.dfn.de) doppelt so schnell wie ich meinen (cr-erl2-be8.x-win.dfn.de). Wenn du im Raum Frankfurt wohnst, bist du vermutlich einfach mit recht kurzen Leitungen an die ganzen relevanten Knoten angeschlossen.

Nunja, man kann nicht alles haben. Immerhin kann ich das DFN jetzt vernünftig erreichen. Die verfügbare Peak-Bandbreite ins DFN variiert zwar auch relativ stark (habe teilweise nur 70 Mbit/s am 100 Mbit/s FTTH-Anschluss), aber das ist allemal besser als vorher.

[#12]

die ganzen Werte waren übrigens im Wlan gemessen, denke 1-2 ms sind da noch über lan drin

[#13]

---

@Stefan  schrieb:

die ganzen Werte waren übrigens im Wlan gemessen, denke 1-2 ms sind da noch über lan drin

---

Neeeeiiiiiinnnnnn... Sag doch sowas nicht. Jetzt bin ich wieder frustriert. 😲

Ich bin mit meinen Latenzen ja generell nicht so zufrieden, weil die nur selten besser sind, als am DSL-Anschluss vorher (dank der Peering-Problematik teilweise ja sogar deutlich schlechter). Kein Wunder, dass die ganzen Kiddies mich bei PUBG ständig erwischen. Die Telekom hat wohl eine für mich sehr nachteilige Netzarchitektur/Topologie. Ich wäre gespannt, wie es bei anderen Anbietern bei mir aussähe. Leider kommt aus dem Glas im Keller nur magentafarbenes Licht, sonst wäre ich eh schon längst weg. 😣

Aber okay, wir schweifen ab. Hat nix mehr mit dem DFN zu tun.

[#14]

trotzdem noch mal über LAN, weiß mich nun interessiert hat.

C:\Users\Administrator>ping www.uni-leibzig.de

Ping wird ausgeführt für www.uni-leibzig.de [185.53.178.50] mit 32 Bytes Daten:
Antwort von 185.53.178.50: Bytes=32 Zeit=8ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=8ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=7ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=7ms TTL=59

Ping-Statistik für 185.53.178.50:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 7ms, Maximum = 8ms, Mittelwert = 7ms

C:\Users\Administrator>ping www.uni-frankfurt.de

Ping wird ausgeführt für www-a10.uni-frankfurt.de [141.2.37.41] mit 32 Bytes Daten:
Antwort von 141.2.37.41: Bytes=32 Zeit=2ms TTL=56
Antwort von 141.2.37.41: Bytes=32 Zeit=2ms TTL=56
Antwort von 141.2.37.41: Bytes=32 Zeit=2ms TTL=56
Antwort von 141.2.37.41: Bytes=32 Zeit=2ms TTL=56

Ping-Statistik für 141.2.37.41:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 2ms, Maximum = 2ms, Mittelwert = 2ms

C:\Users\Administrator>ping www.uni-hamburg.de

Ping wird ausgeführt für www-fiona.rrz.uni-hamburg.de [134.100.36.5] mit 32 Bytes Daten:
Antwort von 134.100.36.5: Bytes=32 Zeit=11ms TTL=247
Antwort von 134.100.36.5: Bytes=32 Zeit=11ms TTL=247
Antwort von 134.100.36.5: Bytes=32 Zeit=11ms TTL=247
Antwort von 134.100.36.5: Bytes=32 Zeit=11ms TTL=247

Ping-Statistik für 134.100.36.5:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 11ms, Maximum = 11ms, Mittelwert = 11ms

[#15]

---

@Stefan  schrieb:

trotzdem noch mal über LAN, weiß mich nun interessiert hat.

C:\Users\Administrator>ping www.uni-leibzig.de

Ping wird ausgeführt für www.uni-leibzig.de [185.53.178.50] mit 32 Bytes Daten:
Antwort von 185.53.178.50: Bytes=32 Zeit=8ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=8ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=7ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=7ms TTL=59

---

Der ist gut !

[#16]

---

@Dilbert-MD  schrieb:

---

@Stefan  schrieb:

trotzdem noch mal über LAN, weiß mich nun interessiert hat.

C:\Users\Administrator>ping www.uni-leibzig.de

Ping wird ausgeführt für www.uni-leibzig.de [185.53.178.50] mit 32 Bytes Daten:
Antwort von 185.53.178.50: Bytes=32 Zeit=8ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=8ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=7ms TTL=59
Antwort von 185.53.178.50: Bytes=32 Zeit=7ms TTL=59

---

Der ist gut !

---

Ja, das ist wirklich gut - geht aber auch nicht ins DFN :). Leipzig mit P, dann misst man die Latenz zum DFN. Jetzt weiß ich auch, was @Stefan mit cogentco.com meinte (Typo). Aber selbst mit der richtigen Uni Leipzig hat Stefan vermutlich in seinem WLAN nur die halbe Latenz dessen, was ich per LAN-Kabel bekomme.

[#17]

das war natürlich etwas peinlich 🥴

Wenn man Leipzig richtig schreibt, dann ist auch meine Route sehr viel langsamer als zu den anderen Unis

Allerdings resultiert das aus dem Wins - wäre fast mal interessant da nachzufragen.

C:>tracert www.uni-leipzig.de

Routenverfolgung zu www.uni-leipzig.de [139.18.16.133]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  router.xx.de [192.168.5.254]
  2     2 ms     3 ms     1 ms  62.155.246.70
  3     3 ms     2 ms     2 ms  217.0.203.30
  4     2 ms     2 ms     2 ms  80.150.169.190
  5     6 ms     6 ms     6 ms  cr-erl2-be8.x-win.dfn.de [188.1.144.221]
  6    16 ms    16 ms    16 ms  cr-tub2-be10.x-win.dfn.de [188.1.146.210]
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9    22 ms    22 ms    22 ms  augate-if.rz.uni-leipzig.de [139.18.122.81]
 10    22 ms    21 ms    21 ms  prod.uni-leipzig.de [139.18.16.133]

Ablaufverfolgung beendet.

[#18]

Ahh, jetzt stehe ich doch gar nicht mehr so schlecht da

Und krass, zur Uni-Frankfurt komme ich auch in nur 8-9ms. Zur TU Chemnitz hingegen brauche ich sogar 27 ms per IPv4 (absoluter Negativrekord). IPv6 ist etwas schneller in letztem Fall.

Mein letzter Hop im Telekom-Netz ist 80.150.169.190, genau wie bei @Stefan. Ich würde vermuten, dass der in Frankfurt steht. Mein Traffic läuft dann quasi 2x quer durch die Republik (erst (vermutlich) nach Frankfurt, dann nach Erlangen, dann nach Berlin und dann erst wieder zurück in meine Region). Das sieht tatsächlich nach einem sehr suboptimalen Routing im DFN aus. Schaut man sich die X-Win-Topologie mal an, ist der Weg aber leider nicht verwunderlich. Nur die Latenz erscheint mir trotzdem etwas hoch, aber naja.