Selfnet Blog

Dec 16, 2018

Die Selfnet-Firewalls und ihre Grenzen

Selfnet verwendet zwei Server für Firewall und NAT. In den letzten Tagen war die Internetanbindung durch diese Firewalls immer wieder mal etwas wackelig. Wir haben mal tief reingeschaut, was diese beiden Server machen, wo Bottlenecks sein könnten, und wie wir mögliche Performanceprobleme lösen können.

Wir wollen hier mal aufschreiben, was die Server machen, welche Probleme wir gefunden haben, und wie es weitergeht. Es wird also sehr technisch und detailiert!

perf top flame graph, verschmälert, illustrativ

Server als Firewall?

Bei Selfnet gibt es für alle User IPv4 und IPv6 Adressen. Bei IPv4 werden intern Adressen aus einem privaten Bereich pro Zimmer oder WLAN-Client vergeben. Jedes Mitglied hat eine öffentliche IPv4-Adresse. Es muss also eine Umsetzung, sprich Network Address Translation (NAT) passieren. Die Konfiguration für das NAT, für Portforwardings und für die IPv6-Firewall wird aus einer Datenbank generiert.

NAT und Firewall halten große Tabellen mit states der einzelnen Verbindungen. Grundsätzlich lässt sich das gut mit Servern machen. Die Last wird auf alle CPU-Kerne verteilt, für die Firewallregeln und state Tabellen ist im RAM genug Platz.

Topologie des Core-Netzwerks

Selfnet Core Netztopologie

Die Firewalls sind im Netzwerk zwischen den Border-Routern (Uplink zum BelWü) und den Core-Routern in Vahingen eingebaut und firewallen damit ganz Selfnet. Um Redundanz für Ausfälle zu haben sind es zwei Stück. Eines macht primär IPv4 und eines macht primär IPv6. Beide synchronisieren die states mittels conntrackd, sodass ein Failover sehr wenig Impact hat.

Wo ist das Problem?

In den letzten Wochen haben sich mehrere Leute gemeldet und über hohe Round-Trip Times (RTT) geklagt. Die meisten davon sind Gamer, denen "ein hoher Ping" natürlich keinen Spaß macht. An manchen Abenden stieg die RTT über 300ms, was die Internetanbindung deutlich beeinträchtigt.

Durch hohe RTT dauern zum Beispiel TCP Handshakes länger, weshalb Websites langsamer laden, und der Datendurchsatz zum Beispiel bei TCP sinkt deutlich.

Intern war dieses Problem nicht sichtbar, nur vom/zum restlichen Internet. Zusätzlich waren hohe Latenzen im Spiel, was auf die Firewall schließen lässt. Die Router und Switche haben üblicherweise keine großen Buffer und können in unserem Fall maximal ca. 200ms RTT induzieren.

Was passiert da?

Das Leben eines IP-Paketes, das durch unsere Firewall geht ist... kompliziert.

Es landet erstmal im Receive Buffer der Netzwerkkarte und wird in eine Queue (max. 128, bei uns 16 wegen 16 CPU Threads) gesteckt. Die Karte löst einen Interrupt aus, damit die Pakete in der Queue vom System abgearbeitet werden. Dann kommt der Linux Kernel dran und arbeitet die Pakete in einem Soft-IRQ im Kernel-Space ab.

Packet Flow in Netfilter and General Networking

Packet Flow in Netfilter: jedes Paket durchläuft viele Stationen, an denen es geprüft, geroutet, verändert, getaggt oder genattet wird. Grafik von Jan Engelhardt, CC-BY-SA-3.0

Zunächst schaut conntrack nach, ob es zu einer Verbindung gehört, die schon bekannt ist. Dafür hält es eine Hashmap mit allen bekannten Verbindungen, macht darin einen Lookup und taggt das Paket zum Beispiel mit "established". Das ist wichtig, weil man damit ermöglichen kann, dass ein User von innen heraus eine Verbindung öffnen kann (z.B. zu einer Website), aber keine Verbindung von außen geöffnet werden kann, ohne dass der User das will. Eine klassische Stateful Firewall eben.

Danach kommen iptables Regeln, konkret Mangle und NAT. Hier gibt es Chains für jeden User, die z.B. eine User-ID an das Paket taggen und NAT machen, sofern die Regel oder conntrack das erlauben. Falls ein neuer Eintrag in conntrack entsteht, wird dieser mittels conntrackd auch auf die andere Firewall synchornisiert, sodass wir ein hot-standby haben. Die Regeln des iptables werden aus der User- und Netzdatenbank alle paar Minuten autogeneriert.

Wenn das alles geschafft ist, werden die User-IDs noch verwendet, um Traffic-Accounting (Info für den User) und um Traffic Shaping zu machen. Das Shaping greift eigentlich nur in zwei Fällen: entweder, wenn der Internetuplink an der Lastgrenze sein sollte. Dann wird versucht, die User mit viel Traffic zu bremsen, damit nicht ein paar wenige "bad guys" das Netz ausbremsen können. Oder ein User hat z.B. einen Testzugang, dann shapen wir aktuell auf ein paar MBit/s.

Scale

Derzeit (Dezember 2018) enthält die conntrack Tabelle zu Spitzenzeiten gut 200k Verbindugen. Auf der Primär-Firewall für IPv4 lasten dann gut 5 GBit/s (nach Innen) und 1 GBit/s (nach Außen) Traffic mit insgesamt knapp 700k Packets per Second (PPS).

Das Rule-Set für iptables ist rund 40MB groß und enthält 1,6 Mio. Regeln.

Bemerkenswert ist dabei, dass die beiden Firewall-Server mittlerweile seit über 8 Jahren im Einsatz sind und ursprünglich für ca. 2500 Selfnet-User konzipiert waren. Mittlerweile hat sich diese Zahl mehr als verdoppelt und die Server sind doch etwas in die Jahre gekommen.

Die Frage ist: Würde neue Hardware das Problem lösen? Trotz des Alters der Server sind diese technisch nicht schlecht: jeder hat 2 CPUs mit insgesamt 8 physischen Kernen, die bei 2,4 GHz takten. Wenn man sich Moore's Law anschaut, würde man in 8 Jahren einen Faktor 32 in der CPU-Leistung erwarten. Tatsächlich ist man im wirtschaftlich sinnvollen Bereich eher bei einem Faktor von 4 bis 8. Wie viele Jahre würden neue Firewall-Server halten, bis wir wieder an Grenzen stoßen?

Also was tun?

Eine Option wäre, potentere Hardware zu kaufen. Alternativ lassen sich vielleicht Optimierungen finden, die nochmal ein paar Prozent rausquetschen. Oder wir bauen Features aus, die nicht zwingend benötigt werden, bzw. lagern diese auf andere Systeme aus. Hm.

Ursachenforschung

Um informierte Entscheidungen zu treffen, wollen wir einmal ganz tief in die Firewalls reinschauen. Wo genau werden CPU-Zyklen verbraten? Gibts Features, die wir nicht (mehr) brauchen? Was wären die Anforderungen an neue Hardware?

Also: Was passiert bei einer Lastspitze? Offensichtlich ist schonmal: die RTT steigt, der Traffic sinkt, bzw. kommt im Mittel an eine Grenze. Gleichzeitig zeigt uns das Monitoring: die CPUs arbeiten weniger Interrupts pro Sekunde ab, befinden sich aber zu fast 100% im Interrupt-Handling. Die Load ist in diesen Momenten ungefär bei 8, was der Anzahl der cores (nicht Threads) entspricht. Die CPU Kerne peaken kurzzeitig bei 100% Last, sind im Mittel aber bei ca. 50% Idle bzw. 50% Soft-IRQ. Vermutlich ist Hyperthreading hier nicht hilfreich.

Plot der Interrupts pro Sekunde und der Anteiligen CPU-Zeit in Interrupts

Interrupts: bearbeitete Interrupts pro Sekunde (oben, gelb) und Anteil an Interrupts der CPU-Zeit pro Core (unten)

Wir schließen daraus, dass die CPU-Cores ab einem gewissen Punkt die Pakete in einer Queue nicht mehr schnell genug abarbeiten können und deshalb länger in einem Interrupt bleiben. Prinzipiell bedeutet das weniger Context Switches und weniger Cache Flushes, was ein kleines bisschen Geschwindigkeit bringt, allerdings gibt es offenbar trotzdem den Punkt, wo die Queues sehr groß werden und dadurch hohe RTTs entstehen. Da sich das Gesamtsystem (inkl. der Clients) gewissermaßen selbst regelt, haben wir praktisch keine Packet Drops.

Warum dauert das in den Interrupts denn so lange?!

Praktisch unsere gesamte Packet Processing Pipeline findet im Kernel statt. Mit dem Tool perf top kann man gut sehen, in welchen Threads der Kernel sich am meisten aufhält. Wir haben vorher die CPU Taktfrequenz aufs Maximum festgenagelt. Damit sind die Zahlen ein guter Anhaltspunkt für die tatsächliche Hardwareauslastung.

Output von perf top - iptables braucht am meisten CPU Zyklen

Output von perf top: Zeigt die Kernelfunktionen, die die meisten CPU-Zyklen verheizen

Die beiden größten Zyklenfresser sind der Durchlauf des großen iptables Regelwerks und die tc shaper mit je ca. 15-20%, je nach Last. Nochmal gut 6% gehen für die Netzwerkkartentreiber ixgbe drauf und conntrack (inklusive seiner Funktion tcp_packet) macht nur ca. 4-5% aus. Dazu kommt noch ein bisschen Interrupt-Handling.

Zur Analyze einer hohen CPU Auslast sind FlameGraphs ein nützliche Darstellung. Mit einem "kurzen" 4-Zeiler kann damit ein Diagramm erzeugt werden, dass in der horizontalen Achse die verbrauchte CPU-Zeit und in der vertikalen Achse den Kernel-Funktionsnamen darstellt.

perf record -g -a; &
sleep 60;
kill %;
perf script | stackcollapse-perf.pl | sed -r "s/.*;(__do_softirq;.*)/\\1/;t;d" | flamegraph.pl > do_softirq.svg;

Da hier die Auslastung innerhalb des Linux-Soft-IRQ-Handler untersucht werden soll, werden nur Events betrachtet, die auf der Funktion __do_softirq aufbauen dargestellt.

Flame Graph für __do_softirq

FlameGraph für perf von __do_softirq

Wenn man diesen Graphen von unten analysiert, sieht man wie über verschiedene Wege fast immer in der Funktion ixgbe_poll des Intel-Netzwerktreibers landet. Diese Wege stellen interne Details des Soft-IRQ-Handlers da, die aber keine Auswirkung auf uns haben. Deswegen können wir diesen Graphen vereinfachen, indem ixgbe_poll als Basis verwendet wird.

Flame Graph für __do_softirq

FlameGraph für perf von ixgbe_poll

Hier sind wir an der Basis unseres Netzwerkstacks angekommen. Leider können wir auf dieser Ebene nicht viel optimieren, aber wenn wir die einzelnen Türme vergleichen, fallen Ähnlichkeiten auf. Diese Türme scheinen alle auf nf_iterate zu basieren, weshalb wir hier nochmals reinzoomen.

Flame Graph für __do_softirq

FlameGraph für perf von nf_iterate

Dieser Graph scheint nun die CPU-Last der einzelnen Pakete zu sein. Die Blöcke lassen sich recht gut dem oben gezeigten "Packet Flow in Netfilter" Diagram zuordnen. Hier sieht man schön, wie conntrack in etwa auf 10% des Aufwands kommt (inkl der iptables/nat Tabellen). Die Brigde kommt auf etwa 3%, die iptables Regeln so auf 7% und das NAT auf ebenfalls 7%. Die größten zwei Brocken mit über 50% verstecken sich hinter der Funktion __dev_queue_xmit (source).

Flame Graph für __do_softirq

FlameGraph für perf von dev_queue_xmit

Hier handelt es sich um den Traffic-Shaper. Hier fallen zwei Probleme direkt auf: Die Funktion fw_classify (source) verwendet 18% der Ressourcen des Shapers, um bereits markierte Verbindungen neu einzugruppieren. Das ist viel zu viel. Diese Funktion schafft es damit mit 7% der gesamten CPU-Zeit auf den dritten Platz vom Output von perf top. Grund dafür sind unsere derzeit gut 24.000 Shaperklassen. Der Kernel hat eine Hashtable, um die richtige Shaperklasse zuzuordnen. Allerdings ist die Größe der Hashtable nicht dynamisch, oder konfigurierbar, sondern auf 256 hardcoded.

Zusätzlich verschwendet die Funktion _raw_spin_lock (via inline __dev_xmit_skb) 40% der Ressourcen des Shapers. Spinlocks werden in der Multi-Core-Programmierung verwendet, um exklusive Funktionen zu synchronisieren, die nicht gleichzeitig ausgeführt werden dürfen. Aber das heißt leider, dass der Shaper nicht über mehrere CPU-Kerne skaliert und nur neue Hardware kaufen hier nichts helfen wird. Wir haben hier also eine Kombination aus einem (effektiv) single-threaded Shaper pro Interface-Queue, der viel zu Aufwändig eine Klassifikation der Pakete durchführt. Die teuren Funktionen des Traffic-Shapers (fw_classify, htb_enqueue, htb_dequeue und htb_lookup_leaf) laufen lasten wegen den Spinlocks unserer Vermutung nach ca. zwei CPU-Threads aus. Sie liegen aktuell bei ca. 170% CPU-Zeit eines Threads. Wir sind damit nah an der Leistungsgrenze und treffen hier auf das wohl kritischste Bottleneck. Auch neue Hardware mit mehr Cores bzw. Threads würde dieses Problem nicht lösen!

Die einfache Lösung ist das Abschalten der Shaper. Eine bessere Lösung ist es, den Shaper an allen Stellen zu umgehen, wo es möglich ist. Ein CPU Kern müsste für die Shaper aller Testzugänge mehr als ausreichen. Die beste Lösung jedoch wäre ein Shaper, der über mehrere Kerne skaliert. Leider scheint es da noch nichts zu geben, also bliebe nur selber schreiben, oder Linux/Netfilter/Intel-Entwickler dazu überreden... Wir fänden einen "TC Multiqueue-HTB Shaper" sehr hilfreich.

Parameter Tuning

IRQ-Mapping: Die Interrupts der Queues sollen auf alle CPU-Kerne gleichmäßig verteilt sein, damit sich alle an der Last beteiligen. Standardmäßig ist das offenbar nicht der Fall, weil so ein Linux-Rechner ja auch andere Dinge zu tun haben kann. Wir haben dafür ein Script, das einen Interrupt fest auf einen Core mappt. Man muss dafür Pakete wie irqbalance deinstallieren, sonst kommt das in die Quere. Das haben wir aber schon immer, da gibt's nix zu optimieren.

Hashtable Size: Für so eine Firewall muss man conntrack_max (die maximale Anzahl von getrackten Verbindungen) hochdrehen. Auch die conntrack_hashsize sollte erhöht werden. Bisher hatten wir 64k Buckets. Bei 200k Verbindungen sorgt das dafür, dass zunächst eine Suche in der Hashmap läuft und dann noch in einer Linked-List gesucht werden muss, weil in jedem Bucket mehrere Verbindungen liegen. Wir haben den Wert nun auf 1M erhöht, d.h. jede Verbindung sollte direkt über die Hashmap gefunden werden. Da die jetzt nicht mehr in den CPU Cache passt, haben wir gleich viele Cache Misses wie vorher, dafür ist der Lookup effizienter. Ersparnis: rund 1% CPU Zeit.

State-Sync: Der Service conntrackd synchonisiert die States mit der jeweils anderen Firewall über einen separaten 1G Link. Abschalten dieses Services ist eine Option, spart aber auch nur rund 1% CPU Zeit. Dafür wird aus dem hot-standby ein cold-standby. Lohnt sich also nicht.

Timeouts: Eine Verbindung, die ohne weitere Pakete Abbricht (z.B. weil er Client einfach ausgeht) wird in der Firewall weiter gehalten. Standardmäßig werden solche Einträge erst nach 5 Tagen gelöscht. Bei uns sind derzeit 12 Stunden eingestellt. Man könnte aber noch aggressivere Werte, z.B. eine Stunde, oder 30min verwenden. Wieviel das ausmachen kann, zeigt der Plot:

Plot der Anzahl der Verbindungen über ihre verbleibende Zeit im Tracking Plot der Anzahl der Verbindungen über ihre verbleibende Zeit im Tracking, Zoom auf kurzlebige Verbindungen

Plot der Anzahl der Verbindungen über ihre verbleibende Zeit im Tracking - an der linken Seite sieht man, dass viele Verbindungen bald gelöscht werden (z.B. wegen kurzen Timeouts bei UDP, oder weil sie geschlossen wurden), die grüne Linie sind aktive TCP Verbindungen

Wie man an dem eher horizontalen Teil der grünen Linie sieht, sind nur vergleichsweise wenige Verbindungen in einem langen Established Timeout offen. Würde man die Timeouts kleiner setzen, würde sich die grüne Linie nach links verschieben. Bei 1 Stunde statt 12 Stunden, würden knapp 10% gespart werden. Die 12 Stunden sind also ein sinnvoller Wert. Auch eine Stunde wäre wohl brauchbar, aber deutlich darunter (z.B. 5 bis 10 Minuten) würde schon Probleme bringen, weil Verbindungen rausfallen, die gar keine Leichen sind. Da die Verbindungen bis zu ca. 30-60min ungefähr linear abnehmen, deutet das darauf hin, dass Verbindungen älter als 30-60 Minuten fast nie wieder aufgenommen werden, sondern nach 12 Stunden timeouten. Diese aggressiver zu löschen würde auch bei Portscans oder Angriffen helfen.

Shaper: Die Shaper sind für uns nicht kritisch. Wenn wir sie abschalten, ist das schlimmste, was passiert, dass die Testzugänge nicht mehr gedrosselt sind. Aber vielleicht wollen wir das Shaping ja eh irgendwann abschaffen?

Plot der CPU Auslastung

CPU-Auslastung: Last durch Soft-IRQ in Lila. Idle in Dunkelblau. Die rote Linie markiert die Abschaltung der Shaper.

Man sieht ganz deutlich, wie viel die Shaper ausmachen! Im Plot sieht man rund 20% mehr freie CPU Zeit. Zusätzlich gibts in den iptables Regeln noch Einträge, die Pakete flaggen, die nachher von den Shapern bearbeitet werden. Der Teil würde zusätzlich wegfallen, d.h. eine weitere kleine Einsparung bringen.

Firewallregeln: Unsere Firewallregeln werden autogeneriert. Die Templates und Scripte dafür sind eigentlich schon recht weitgehend optimiert. Beispielsweise sind die Regeln pro externe Adresse und pro Netzbereich in Chains aggregiert, sodass iptables nicht bei jedem Paket durch alle 1,6 Millionen Regeln laufen muss, sondern z.B. nach 10 Regeln in die Chain für den passenden Netzbereich abbiegt, nach weiteren 20 Regeln zur passenden User-Chain abbiegt und dort nurnoch wenige Regeln hat. Wir haben uns das angeschaut und Optimierungspotential gefunden. Beispielsweise wurde früher Traffic zur Uni Stuttgart separat gezählt. Das passiert heute nicht mehr, aber die Regeln dafür sind prinzipiell noch vorhanden. Auch die Markierungen für die Shaper können ggf. zukünftig abgeschafft werden. Außerdem hilft es, ganz oben in der FORWARD Chain die bereits akzeptierten (und damit in conntrack bekannten) Verbindungen direkt zu akzeptieren, damit die Regeln nicht durchlaufen werden müssen:

-A FORWARD -m state --state ESTABLISHED -j ACCEPT

Wir haben diese Optimierungen in den Firewallregeln direkt umgesetzt, um die aktuellen Probleme schnell zu lösen. Diese winzigen Änderungen bringen direkt einen großen Performancegewinn, wie man in dem Vergleich sieht:

CPU-Last durch Interrupts vor den Optimierungen CPU-Last durch Interrupts nach den Optimierungen

CPU-Auslastung durch Soft-Interrupts (unten) vor und nach den Optimierungen in den Firewallregeln. Auslastung (Traffic-Level) waren an beiden Tagen vergleichbar.

Solange die CPU nicht mehr komplett in Interrupts feststeckt, bzw. das TC Lock nicht mehr Zeit benötigt, als es hat, werden mehr Pakete abgearbeitet, als rein kommen. Damit baut sich keine Queue auf, und es gibt keine Probleme. Das Problem ist also vorerst (kurzzeitig) gelöst.

Wie geht's weiter?

Wir können mit einigen Optimierungen ca. 20-30% CPU Last einsparen. Das wäre die Hälfte der aktuellen Spitzenlast. Damit wäre kurzfristig wieder ein gutes Stück Kapazität auf den Firewalls vorhanden.

Offloading von mehr Arbeit in die Netzwerkkarte (z.B. mit XDP und eBPF) könnte auch nochmal einen guten Performance-Boost geben.

Zu guter letzt: Neue Hardware muss her. Die alten Firewalls haben treue Dienste geleistet, aber sind jetzt 8 Jahre alt. Mit neuer Hardware kann die Leistung nochmal deutlich gesteigert werden. Wo genau dieser Faktor liegt, hängt von sehr vielen Parametern ab. Wir schätzen aber, dass mindestens Faktor 4-10 bezahlbar sein sollte. Bei einer Hardwarebeschaffung wird auch auch der Schritt in Richtung 100 Gigabit interessant.

Wir werden vermutlich über die Weihnachtsfeiertage und zwischen den Jahren weiter an der Performance schrauben, aber parallel dazu auch die Beschaffung neuer Hardware planen. Wir werden berichten.

Dieser Beitrag wurde von Markus Wick und Sebastian Neuner verfasst.

Dec 01, 2018

Anbindung Studentendorf Ludwigsburg und Zukunft

Die Wohnheime im Montessoriweg, Pestalozziweg, Peter-Eichert-Str. und das Wohnhaus der Finanzen sind jetzt über Glasfaser angebunden!

Traffic Graph nach Glasfaseranbindung noch verhalten und im Schnitt ~150Mbps (max. ~1Gbps) Auslastung.

Screenshot: Traffic Graph nach Glasfaseranbindung noch verhalten und im Schnitt ~150Mbps (max. ~1Gbps) Auslastung zwischen Donnerstag 29.11.2018 kurz vor 16 Uhr bis am nächsten Tag um ca. 13 Uhr.

Vorgestern Abend (Donnerstag) haben wir die neu verlegte Glasfaser zur Pädagogischen Hochschule in Betrieb genommen. Seitdem ist auch die bisherige Anbindung über die Funkbrücke nicht mehr aktiv. Unsere eigenen Tests bestätigen, dass die Anbindung mit 10 Gigabit (full-duplex; also in beide Richtungen gleichzeitig) voll funktionsfähig ist.

Bis jetzt haben wir schon einiges an positiven Rückmeldungen bekommen. Sollten Fragen bestehen oder die Geschwindigkeit bei euch an der Netzwerkdose im Zimmer nicht ankommen, bitte kurz eine E-Mail an support@selfnet.de schicken. Wir kümmern uns dann darum. :-)

Speedtest Vergleich vor und nach Anbindung über Glasfaser getestet an einem Laptop das mit einem Netzwerkkabel in einem Zimmer an der Netzwerkdose angeschlossen ist - davor: Download 1,17 Mbps / Upload 0,02 Mbps / Ping 1516,88 ms / Jitter 2800,93 ms - danach: Download 989,28 Mbps / Upload 925,43 Mbps / Ping 1,76 ms / Jitter 0,31 ms

Screenshots: Vergleich Speedtest vom Landeshochschulnetz vor und nach der Anbindung durch die Glasfaser.

Odyssee zur Glasfaseranbindung

Foto: Eine von 3 Reparaturstellen des Leerrohrs.

Nachdem erst Anfang November klar war, dass mit der Umsetzung der Glasfaseranbindung begonnen werden kann, blieben nur wenige Wochen für die notwendigen Bauanträge und Arbeiten bei Tiefbau, Kabelzug, Verkabelung und Anschluss. Denn am 01. Dezember wird das bestehende Internet abgeschaltet.

All dies wäre in dieser kurzen Zeit nicht ohne die tatkräftige Unterstützung der Mitarbeiter der Pädagogischen Hochschule, des Landeshochschulnetzes, des Studierendenwerk Stuttgart und den motivierten Mitarbeitern der beteiligten Baufirmen und Elektriker möglich gewesen!

In der vorletzten Novemberwoche gab es noch eine unerwartete Verzögerung, da ein bestehendes Leerrohr unter der Straße an mehreren Stellen starke Biegungen (90°) hatte. Das hat Probleme beim Einziehen der Rohrteiler und Kabel verursacht und das Leerrohr musste an den betroffenen Stellen zunächst freigelegt werden.

Netzaufbau innerhalb des Studentendorfs und Wohnhaus der Finanzen

Foto des Core Routers im Studentendorf Ludwigsburg (Juniper EX4600) und 2 Access Switchen (Juniper EX3300) unterhalb eines Glasfaser Patchpanels.

Auch wollen wir uns natürlich bei allen ehrenamtlich tätigen Mitgliedern bedanken, die im letzten halben Jahr unermüdlich das neue Netz innerhalb des Studentendorfs aufgebaut haben.

Insgesamt wurden in den Kellerräumen von 18 Gebäuden 34 Switche verbaut. Alle Switche sind mit einem zentralen Switch und zusätzlich in einem Ring untereinander mit Glasfaser verbunden. Die Switche wurden mit über 866 Kabeln auf die Patchpanel in den Kellern gesteckt, welche über Cat7-Verlegekabel mit den Netzwerkdosen in den Zimmern verbunden ist.

Zukünftiger Ausbau und Redundanz

tl;dr: Aktuell gibt es eine Verbindung. Das wird bald auf zwei Verbindungen erweitert, sodass wir besser von möglichen Ausfällen geschützt sind.

Neuer ODF (Optical Distribution Frame) / Glasfaserverteiler im Blockheizkraftwerk der PH

Das Studentendorf ist per Glasfaser mit der Pädagogischen Hochschule auf der anderen Seite der Gleise verbunden und dort an das Landeshochschulnetz angeschlossen, über welches die Verbindung nach Stuttgart zu unserem Netz realisiert wird.

In der Pädagogischen Hochschule finden aktuell noch Sanierungsarbeiten statt, nach deren Abschluss im Frühjahr 2019 es möglich sein wird eine zweite Verbindung herzustellen. Das wird die Ausfallsicherheit der Anbindung des Studentendorfs erhöhen. Unsere Switche arbeiten mit dynamischem Routing welches automatisch auf die funktionierende Verbindung wechselt, sollte dann eine der beiden Verbindungen ausfallen.

Foto von Medienkonverter (Juniper EX2300 Switch) in der PH mit dem ein Multimode Faserpaar und ein Singlemode Faserpaar verbunden ist.

Derzeit muss innerhalb der Pädagogischen Hochschule noch mit einem Medienkonverter auf einen anderen Typ Glasfaser umgesetzt werden. Sobald die zweite Glasfaserverbindung dazu kommt wird auch die alte Verbindung innerhalb der PH auf einen einheitlichen Typ Glasfaser umgezogen. Der Medienkonverter, der bei einem Stromausfall ebenfalls betroffen wäre, wird dann wegfallen.

Im besten Fall bekommen also nur die ehrenamtlich tätigen Mitglieder den Ausfall einer Optik oder einer Anbindung per Warnmeldung unseres Monitoring Systems mit. Der Zugang zum Netz bleibt weiterhin gewährleistet und wir können uns in Ruhe um die defekte Komponente kümmern ohne panisch aus der Vorlesung zu flüchten. ;-)

Sonderfall Wohnhaus der Finanzen

Im Gegensatz zum Studentendorf - in dem das Studierendenwerk Stuttgart im letzten halben Jahr Netzwerkkabel zu jedem Zimmer verlegen hat lassen - gab es im Wohnhaus der Finanzen schon eine bestehende Netzwerkverkabelung bis in die Zimmer.

Als vor vielen Jahren die Netzwerkverkabelung im Wohnhaus der Finanzen aufgebaut wurde, entschied man sich, jedes Netzwerkkabel an zwei Netzwerkbuchsen in den Zimmern anzuschließen: Für Telefon und Internet. Obwohl es schon lange kein Telefon mehr in den Zimmern gibt, bedeutet das, dass aktuell nur 4 von 8 Adern an jeder der beiden Netzwerkbuchsen angeschlossen sind.

Über 8 Adern werden Daten mit bis zu 1 Gigabit (also 1000 Mbps) übertragen. Verwendet man nur die Hälfte der Adern, wird daraus ein Zehntel, also 100 Mbps. Bis zur nächsten Sanierung stehen in diesem Wohnheim also nur 100 Mbps Bandbreite pro Zimmer zur Verfügung.

Auch WLAN wird dort erst nach der nächsten Sanierung zur Verfügung stehen, wenn die dafür notwendigen Kabel eingebaut sind.

Wermutstropfen: Anders als vor der Umstellung ist also nicht mehr der Hausanschluss zum Internet der Engpass, sondern die Netzwerkdosen. Zudem ist die Geschwindigkeitsangabe natürlich "full-duplex". Upload- und Download-Geschwindigkeit sind also gleich und können auch gleichzeitig abgerufen werden, wenn der Server auf der anderen Seite dies leisten kann. :-)

Unsere Mitglieder im Wohnheim der Finanzen können natürlich - wie alle anderen Mitglieder - gerne auch in allen anderen Wohnheimen und Orten, in denen es verfügbar ist das Selfnet-WLAN nutzen. Zum Beispiel gibt es um die Schütte herum outdoor Selfnet-WLAN. :-)

Genaueres zur Verfügbarkeit des Selfnet-WLANs und den notwendigen Einstellungen ist auf unserer Webseite:

Wie man an der Netzwerkdose im Wohnheimzimmer einen eigenen WLAN-Router einrichtet, ist zusätzlich in einem Router HowTo beschrieben. Bei Fragen oder Problemen helfen wir natürlich gerne bei der Konfiguration des Geräts.

Wie ihr seht, liegt zwischen der Netzwerkdose in eurem Zimmer und dem Internet viel interessante Technik.

Wir freuen uns immer über interessierte, engagierte Mitglieder, die den Verein unterstützen.

Ob das jetzt durch ehrenamtliche Mitarbeit oder Nutzung des Zugangs zum Wohnheimnetz ist, ist natürlich jedem selbst überlassen.

Wer Lust hat mitzuhelfen - sei es in der Öffentlichkeitsarbeit, Mitgliedersupport, Projekten, Veranstaltungen, Finanzen, Entwicklung oder Betrieb und Administration - ist herzlich eingeladen eine unserer Sprechstunden besuchen.

Foto von Backbone-Router des Landeshochschulnetzes an der PH Ludwigsburg mit unserer neuen Glasfaseranbindung Foto einer der neu verbauten Netzwerkdosen in einem Zimmer im Studentendorf.

Fotos: Nahaufnahme Backbone-Router des BelWü mit unserer Cyan-farbenen Glasfaseranbindung. :-) // Eine der neu verbauten Netzwerkdosen in einem Zimmer im Studentendorf.

Nov 23, 2018

Status der Anbindung Studentendorf Ludwigsburg und Wohnhaus der Finanzen

Seit etwa 2 Jahren besteht die Planung, die Wohnheime Studentendorf Ludwigsburg und das Wohnhaus der Finanzen an das von Selfnet e.V. betriebene Wohnheimsnetz anzubinden. Nachdem Ende 2017 klar war, dass es auch in Ludwigsburg Studierende gibt, die sich für eine solche Anbindung ehrenamtlich engagieren wollen, haben wir Anfang 2018 mit den Vorbereitungen begonnen.

Foto des Core Routers im Studentendorf Ludwigsburg (Juniper EX4600) und 2 Access Switchen (Juniper EX3300) unterhalb eines Glasfaser Patchpanels.

Neben der Beschaffung von Netzwerkhardware (Switche, Router, Optiken, ...) musste auch die Anbindung sichergestellt werden. Das Landeshochschulnetz von Baden-Württemberg (BelWü) stellt uns an der Pädagogischen Hochschule kostengünstig eine Anbindung mit Transit zum restlichen Wohnheimsnetz von Selfnet zur Verfügung. Die notwendigen Abstimmungen waren innerhalb weniger Tage abgeschlossen.

Das Verlegen der Glasfaser zwischen der Pädagogischen Hochschule und dem Studentendorf war hierbei deutlich aufwändiger, da erst nach etwa 6 Monaten Abstimmungen zwischen dem Studierendenwerk Stuttgart, den Stadtwerken Ludwigsburg und uns ein entsprechender Vertrag geschlossen werden konnte. Die Bauarbeiten wurden dann sogleich in Auftrag gegeben und seit knapp 2 Wochen vergräbt das Bauunternehmen Leonhard Weiss zwischen dem Studentendorf und der Pädagogischen Hochschule die Leerrohre, in die später die Glasfasern eingeblasen werden.

Leider hat sich durch diese langwierigen Abstimmungen unser Zeitplan für die Anbindung sehr verzögert, was nun zu Lasten der Netzqualität der dortigen Bewohner geht.

Beispielfoto einer Netzwerkdose im Studentendorf Ludwigsburg.

Da es in den Gebäuden des Studentendorfs (abgesehen vom Wohnhaus der Finanzen) noch keine Netzwerkkabel in jedes Zimmer gab, wurden diese - parallel zu den Abstimmungen für den Uplink - im Auftrag des Studierendenwerks verlegt. Selfnet hat außerdem den Auftrag zur Verlegung der Glasfasern zwischen allen Gebäuden erteilt.

Mit der schrittweisen Fertigstellung der Netzwerkverkabelung haben wir dann jeweils unsere Technik (Router und Switche) in den einzelnen Gebäuden verbaut.

Um bereits möglichst früh die ersten Mitglieder im Studentendorf an unser Netzwerk anbinden zu können, haben wir im April diesen Jahres eine provisorische Funkbrücke installiert, welche unser Netzwerk mit dem Uplink an der Pädagogischen Hochschule verbindet. Durch die großen Verzögerungen beim Bau der Glasfaserstrecke findet die derzeitige Anbindung leider noch immer über diese Funkbrücke statt.

Das Problem dabei ist, dass die Funkbrücke zwar für einen Durchsatz von ca. 450 MBit/s (was am Anfang durchaus ausreichend war) ausgelegt ist, aber mittlerweile nach der Anbindung des Wohnhauses der Finanzen der Menge der Verbindungen nicht mehr wirklich stand hält und dementsprechend keine zufriedenstellende Versorgung bieten kann.

Fertig verlegtes Leerrohr das noch mit Erde bedeckt werden muss.

Seit dem 12. November finden nun die Bauarbeiten zur Glasfaser-Anbindung statt. Diese bestehen aus dem Vergraben der fehlenden Leerrohre zwischen der Pädagogischen Hochschule und dem Studentendorf und dem anschließenden Verlegen der Glasfasern. Leider haben sich auch hierbei Probleme ergeben, dass unter anderem bestehende Leerrohrstrecken nicht mehr zugfähig sind und daher durch weitere Tiefbaumaßnahmen erst in Stand gesetzt werden müssen.

Nach dem derzeitigen Stand hoffen wir, Ende November oder Anfang Dezember die Glasfaser in Betrieb nehmen zu können, und dadurch den geplanten Zustand der Anbindung zu erreichen. Einen genaueren Termin können wir leider nicht nennen, da dies von den (weiteren) Problemen beim Bau abhängt.

Das hilft den Bewohnern des Studentendorfs und Wohnhaus der Finanzen natürlich nicht über die derzeit schlechte Anbindung hinweg, allerdings können wir sagen, dass wir selbst mit der Situation sehr unzufrieden sind und unser möglichstes tun, um bald eine Besserung zu erreichen. Auch werden wir die Bewohner über den aktuellen Stand auf dem Laufenden halten (u.a. über Twitter).

Wir bitten die momentanen Einschränkungen zu entschuldigen und verbleiben mit einer Vorfreude auf die schnelle Anbindung, sobald die Glasfaser in Betrieb ist!

Foto von Bagger der die Straße aufreist. Foto von neu gesetztem Schacht der später zur Wartung Zugang geben soll.

← Previous Next → Page 2 of 8