Selfnet Blog

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.

Nov 13, 2018

Connected In der Au to the dormitory network

Last Saturday (2018-11-10) we've connected the dormitory In der Au in Stuttgart-Untertürkheim to our network.

The new dormitory is connected with 10 GBit/s to our core network. We are currently investigating if the network outlets in the individual rooms are working properly. In some cases the outlets may be defective due to the usual wear and tear and are only capable of 10% (100 MBit/s of 1000 MBit/s) of the possible speed. Due to the previous overall uplink connection this was probably unnoticed.

If you live in the In der Au dormitory and notice that your device only has a link speed of 100 MBit/s (also called FastEthernet) instead of 1000 MBit/s (1 GBit/s or GigabitEthernet) please send an email to support@selfnet.de so we can have a look at the individual outlet in your room.

Switches in house A connecting the fiberoptic uplink from the outside the the rooms in house A and to the other switches in house B and C. Switch rack in house C being prepared for our switches. Switch rack in house C with our switches but unpatched. Switch rack in house C with switches and all patch cables neatly arranged for clarity when one has to debug a problem. Another photo of one of the switches in house A showing the fiberoptic uplink cable (bidi SFP+) and a DAC cable connecting it to the other switch Photo of the 2 switches in the rack in house B properly patched and operational.

May 03, 2018

Connected Anna-Herrigel-Haus to the dormitory network

Last Friday (2018-04-27) we connected the Anna-Herrigel-Haus to the dormitory network.

As with all newly connected dormitories we:

  • Checked the RJ45 LAN network outlets in all rooms using a measurement device.
  • Mounted the access switch into the rack which distributes the network connection from our fibre network.
  • Connected the optical fibers using optical transceivers. Most of the transceivers (SFP+) we buy are sold by Flexoptix. In this case we used 10G SFP+ BIDI LR LC, 10km, 1330 nm, singlemode transceivers.
  • Connected all patchpanel copper RJ45 LAN connectors (which on the other end lead to the network outlet in a room) to the switch.
  • Made sure everything works.

Switchroom with laptop connected via serial console to access switch to configure fiberoptic uplink. // Switchraum mit Laptop das über eine serielle Konsole mit dem Switch verbunden ist um den Glasfaser-Uplink einzurichten. Starting to patch the the copper RJ45 patchcables neatly between patchpanel and switch. // Während des Patchens der RJ45 Kupferkabel zwischen Patchpanel und Switch. Photo from outside of building. // Foto des Hauses vom Garten aus. Close up of operational switch showing neatly connected cables. // Nahansicht der Verkabelung. Completely patched and operational Switch fully patched with all cables. // Komplett angeschlossener Switch. plaque in the entrance area (translation from German): Until 1943 this was the "Jakobiheim", named after Margarethe Jakobi 1910 given to the female teachers of Canstatt, destroyed by bombs in 1943, the house could be rebuilt thanks to Anna Herrigel in 1953/54. // Gedenktafel im Eingangsbereich: Bis 1943 stand hier das "Jakobiheim", von Margarethe Jakobi 1910 den Cannstatter Lehrerinnen gestiftet, 1943 durch Fliegerbomben zerstört, konnte das Haus 1953/54 dank der tatkräftigen Bemühungen von Anna Herrigel wieder aufgebaut werden. Speedtest in progress showing a Download speed of 983.88 Mbit/s. // Speedtest im Gange der im Download 983,88 Mbit/s anzeigt.

Mar 19, 2018

Einladung zur Mitgliederversammlung 2018 / Invitation to our general meeting of 2018

(English translation below.)

Liebes Mitglied,

anbei erhältst Du die Einladung zur ordentlichen Mitgliederversammlung 2018. Wir hoffen auf zahlreiches Erscheinen.

Die Mitgliederversammlung wird sich dieses Jahr auch mit Satzungsänderungen befassen. Die vorgeschlagenen Änderungen kann man im Anhang des Einladungsschreibens (PDF) einsehen.

Termin: Mittwoch, den 18. April 2018 um 19:00 Uhr
Ort: Ökumenisches Zentrum, Allmandring 6, 70569 Stuttgart

PDF Einladungsschreiben

Mit freundlichen Grüßen,
Selfnet e.V.
Der Vorstand


English version

Dear Member,

please find attached the invitation to our general meeting of 2018. Please note that this meeting will be in German language only. However, the topics that will be discussed include:

  1. reception and establishing decision capability
  2. report about what the club did in the year 2017/2018
    1. report by the elected board of directors
    2. treasurer's report
    3. report of data protection commissioner
  3. report of the financial auditors
  4. exoneration of the elected board of directors
  5. proposals for changing the clubs statutes
  6. election of new board of directors
  7. prospect for the next year 2018/2019
  8. information about connecting new dormitories
  9. resolution regarding the future orientation of Selfnet e.V.
  10. checking the presence of all keys
  11. miscellaneous

Please note that this general meeting will include proposals for changing the clubs statutes. See attached document for the proposals.

Date: Wednesday, 18th of April 2018 at 7:00 PM
Location: Ökumenisches Zentrum, Allmandring 6, 70569 Stuttgart

PDF invitation

Sincerely,
Selfnet e.V.
Board of Directors

Feb 15, 2018

Data protection and privacy at Selfnet e.V.

Some of you might wonder how we collect and handle the personally identifiable information we have about our members. In this blog post we will try to give you a bit of insight into that topic.

If one stores information it can and will be lost/leaked at some point!

First of all: We only store information we really need. While it is debatable in some cases what is needed and what is not we try to collect as little information as we need.

All over the world with lots of organisations / companies / governments losing your personal information, criminals use your information to do their "business" either by stealing from you or someone else in which case you will be blamed.

If someone tells you that their system is completely safe from viruses (malicious software), attackers, etc. they are simply lying. Nothing in this world is 100% safe. This is a simple universal fact.

While we try to keep your information as safe as possible we will not lie to you just to give you a good feeling.

There are things everyone can do to improve security apart from only trying to store information in a secure/encrypted way.

More so for an organisation: If you do not think upfront about what personal information is really necessary for your operation you are probably doing something wrong.

Define how long you need the information and how you delete / destroy it!

After defining what data you store about other people you should always define how long you need to store the information.

While we also keep records on paper, all information actively used is in an electronic database system (RDBMS / PostgreSQL).

We delete the information in our database if the following three things apply:

  1. The person in question has terminated his/her membership more than 6 months ago.
  2. The cash audit for this member has been done.
  3. There are no outstanding membership fees.

The cash audit is done once a year before our yearly meeting of members. The meeting of members is held once a year in April and it is the main body of the association (Verein) where every member is invited (via email) and welcome to participate in the meeting (even non-volunteering members). During the meeting of members the cash auditors (minimum 2 people) attest that the treasurer did nothing wrong.

To do that they manually check every single transaction on our bank account. For things we buy (e.g. hardware) there has to be an invoice and for every monthly membership fee there has to be a record in our database.

Because Selfnet e.V. is a "Verein" some data retention is required by law meaning that the paperwork you signed has to be stored for several years. After that time has passed we destroy it.

So once we (regularly) delete the data in our database we create a list of all deleted membership numbers (VNR), print it and get the paperwork for the listed members.

This paperwork along with the list is kept for some years (due to the aforementioned regulations) in a box which we store in a locked room.

Once enough years have passed we have a "shredder party" and feed all the paperwork to Mr. OmNomNom and his brother which is also a document shredder.

Of course backups of the database also have to be pruned regularly. :-)

Photo of last shredder party:

Source of imagePhoto of the last shredder party.

Video of last shredder party:

Source of video

Setting up rules for everyone who works with the data.

The first thing you should do is think about what you tell everyone who might be in contact with the information you are collecting before he or she comes into contact with the information.

While the law in some countries favours data protection at least in Germany the punishment for doing something stupid with other peoples personal information is - for the most part - pretty tame.

Therefore it does make sense to - in addition to the things required by law - setup rules for everyone in your organisation.

In case of Selfnet every volunteer and basically everyone who wants to enter the office where you could potentially see information about other members has to completely read, understand and sign the data protection guidelines (Datenschutzrichtlinie) before they can advance to the non-public rooms.

While it does not improve the law it should make it more clear that all personal information is sensitive and has to be protected.

Giving everyone only access to what they really need.

A good example for this is the SEPA mandate. A SEPA mandate usually consists of the IBAN and BIC of your bank account along with the mandate ID for which you signed the form (we have to produce the paperwork if the banks ask for it).

Because only our treasurer needs to see the full IBAN (International Bank Account Number) (to create the transaction file for the direct debit of the membership fees) the volunteers doing support for other members only see the last 4 digits of the IBAN. This way if you have forgotten which of your bank account numbers you gave us they can tell you the last 4 digits which should be enough for you to verify which bank account it is. But the full IBAN (which could be used on online shopping websites) is not shown.

Also not all volunteers do support work, for example they concentrate on technical things and therefore those volunteers do not have access to any membership information at all.

If you have made it this far we also recommend you to have a look at the terms of use for the dormitory network (also known as "Network rules" or "Benutzerrichtlinien"). They are signed by everyone who wants to use the dormitory network.

Nov 08, 2017

Erweiterung des Selfnet-Netzwerkes in der Stuttgarter City (Teil II)

Im Laufe des Wochenendes 18.11./19.11.2017 werden die Wohnheime:

  • Kernerstr. 2
  • Landhausstr. 14
  • Neckarstr. 132
  • Rieckestr. 17
  • Neckarstr. 172 (Boardinghaus)

an unser Wohnheimnetzwerk angeschlossen.

In Vorbereitung dieser Aktion haben wir bereits den Umbau geplant, die notwendige Hardware angeschafft (vor allem Switche) und Glasfasern zu den Gebäuden legen lassen.

An genanntem Wochenende werden wir die neue Hardware in den Gebäuden installieren, die bestehende LAN-Verkabelung innerhalb der Gebäude mit unserer Hardware verbinden und über die Glasfaserkabel dann an unser Netzwerk anbinden. Wenn du Lust hast, dabei mitzuhelfen, kannst du gerne auf uns zukommen!

Wir werden Euch natürlich über den Status der Umbauaktion per twitter.com/Selfnet_eV auf dem Laufenden halten.

Nachtrag 2017-11-21: Leider konnte die Rieckestr. 17 an diesem Wochenende nicht angebunden werden, da es Verzögerungen bei der Verlegung der Glasfaser gegeben hat. Nachtrag 2017-11-30: Die Rieckestr. 17 wurde heute heute erfolgreich ans Wohnheimnetzwerk angeschlossen.

Aug 29, 2017

SelfStreaming Photo Story

Sitting on a roof

Photo from the top of the roof of the oecumenic centre. // Foto vom Dach des Ökumenischen Zentrums. Photo from the top of the roof of the oecumenic centre. // Foto vom Dach des Ökumenischen Zentrums.

Input

Photo of big satellite dish with fiberoptic LNBs. // Foto von großer Satellitenschüssel mit Glasfaser LNBs. Photo of big satellite dish with fiberoptic LNBs. // Foto von großer Satellitenschüssel mit Glasfaser LNBs.

Mux

Photo of multiplexers taking in a single optical fiber and demultiplexing it to coaxial cables. // Foto von Multiplexern die jeweils aus einer einzelnen Glasfaser mehrere Koaxialkabel demultiplexen. Photo of multiplexers taking in a single optical fiber and demultiplexing it to coaxial cables. // Foto von Multiplexern die jeweils aus einer einzelnen Glasfaser mehrere Koaxialkabel demultiplexen.

Output

Photo showing the backside of a 19" 4U server with lots of TV tuner cards connected to lots of coaxial cable. // Foto der Rückseite eines 19" 4HE Servers mit vielen TV Karten die wiederum mit vielen Koaxialkabeln verbunden sind. Photo showing the backside of a 19'' 4U server with lots of TV tuner cards connected to lots of coaxial cable. // Foto der Rückseite eines 19'' 4HE Servers mit vielen TV Karten die wiederum mit vielen Koaxialkabeln verbunden sind.

then multicast <3

Photo of rack with 3 big routers and lots of fiberoptic patchpanels. // Foto eines Racks mit 3 großen Routern und vielen Glasfaserpatchpaneln. Photo of rack with 3 big routers and lots of fiberoptic patchpanels. // Foto eines Racks mit 3 großen Routern und vielen Glasfaserpatchpaneln.

Aug 21, 2017

Storage Ausfall

Wie einige im August vielleicht gemerkt haben, hat es von Montag Nacht (14. August 2017) bis Mittwoch Abend einige technische Probleme bei uns gegeben. Diese haben dazu geführt, dass das Selfnet-WLAN nicht mehr funktioniert hat. Doch was war die Ursache dafür?

Alles fängt damit an, dass einige virtuelle Maschinen nicht mehr normal funktionieren. Schnell ist klar, dass dies kein Problem der jeweiligen virtuellen Maschinen, sondern unseres Storage-Clusters ist.

Unser Storage-Cluster basiert auf Ceph und stellt allen virtuellen Maschinen die Festplatten und damit etwa 100 TiB Speicherplatz bereit. Es besteht aus 3 Knoten (Nodes): Ein großer Klotz in Vaihingen (storage-1), ein weiterer großer Klotz in der Heilmannstraße (storage-2) und ein kleinerer nochmals in Vaihingen (storage-3). In der Theorie sollte der Cluster auch noch weiterhin funktionieren, wenn ein Knoten ausfällt.

Die erste Diagnose war, dass der Link (Verbindung) von storage-2 zum Core-Router dort wackelig ist. Deshalb entscheidet man sich dazu storage-2 komplett abzuschalten. Die Hoffnung: Das Ceph sammelt sich dann und verteilt die Inhalte neu, damit wieder hinreichende Redundanz sichergestellt ist. Das tritt jedoch entgegen unserer Annahme nicht ein.

Virtuelle Maschinen, welche viel Disk-IO (also Lese- und Schreiboperationen) verursachen (z.B. Mail, DHCP wegen logging oder Radius), stellten daher sofort ihren Dienst ein. Auf wundersame Weise überleben die IRC und Jabber/XMPP Server die Zeit ohne funktionierende Festplatten.

Erste Versuche den Link (Glasfaser und Optik) zwischen storage-2 und heilmann-core zu reparieren, scheiterten an einem SFP (Optik), auf dessen Schachtel Intel draufstand aber wohl doch nicht Intel drin war und deshalb die Netzwerkkarte den SFP nicht akzeptiert.

Um das Netz für unsere Mitglieder wieder halbwegs verfügbar zu machen, wird dann in den Morgenstunden des Dienstags (etwa zwischen 5 und 6 Uhr) auf kvm-dev (Virtualisierungsserver) die virtuelle Maschine 'notfall-1' mit lokaler Festplatte erzeugt und dort mit Ansible (schick, wa?) ein resolver und DHCP-Server installiert. Glücklicherweise hat einer von uns noch von der DHCP-Migration vor einer Woche die von den Update-Skripten erzeugte DHCP-Konfiguration im /tmp Ordner liegen. Sonst wäre das deutlich schwerer gewesen...

Auch nachdem erfolgreich in storage-2 und den heilmann-core neue SFPs und neue Patchkabel eingebaut wurden, will sich das Ceph immer noch nicht wieder zusammenbauen. Mal geht es aufwärts mit der Anzahl an 'guten' Objekten, um dann wieder zu sinken. So läuft das dann bis Mittwoch Abend. Im tcpdump zwischen den Storage-Kisten fallen uns recht viele ACKs auf, aber mit iperf laufen dennoch 10GBit/ über den Link...

Einem unserer aktiven Mitglieder fällt dann im IRC Chat auf, dass

ich hab grad die vermutung, dass der link zwischen heilmann-core-2 und -1 hin ist

ich hatte gerade jede menge loss dazwischen und testweise das routing umgebogen, dass der weg zu storage-2 nicht über den link geht

Daraufhin fängt sich Ceph wieder. Im weiteren Verlauf der Dinge stellt sich dann heraus, dass nicht der link zwischen den beiden Core-Routern in der Stadt wackelig ist, sondern die Strecke vom vaih-core-1 zum heilmann-core-2 wackelig ist. Auch das Tauschen und Putzen aller Glasfasern und SFPs ändert daran nichts.

Mit dem Routing über den kade-core hat sich das Ceph dann auch im nu zusammen gebaut, aber manche virtuelle Maschinen wollen gar nicht booten. Andere virtuelle Maschinen kommen nicht über die Initramdisk hinaus. Alles ganz komisch.

Also haben wir eine der Festplatten (der virtuellen Maschinen) mit rbd map als Blockdevice auf einem der kvm-hosts (Virtualisierungsserver) gemapped und mit cat /dev/rbd0 | xxd einen Dump (Speicherauszug) erstellt. Feststellung: Nach ein paar Megabyte bleibt die Operation hängen und will sich weder durch ^C noch mit kill -9 beenden lassen. Vermutlich findet bei rbd map die Kommunikation mit den storage-nodes im Kernel statt und der syscall bleibt hängen. Das ist zum Debuggen natürlich gar nicht schön.

Deshalb haben wir mit rbd import die Platte auf stdout (Standardausgabe) geschrieben und festgestellt, dass auch dies nach ein paar MB hängen bleibt, sich aber im Gegensatz zu der Methode davor mit ^C abbrechen lässt. Ein wenig Debuggen mit strace zeigt, dass sich rbd mit einem OSD (so heißen bei Ceph die Daemons (Dienste), die an den Platten im Storage dranhängen) auf Port 6914 verbinden wollte, aber ein "connection refused zurück kam". netstat bestätigt, dass da tatsächlich ein OSD auf dem Port lauscht. Es stellt sich heraus, dass in der Firewall auf allen Storage-Knoten nur Ports 6700-6900 offen waren, Ceph aber die Ports 6800-7300 benützt. Interessanterweise steht in den Release notes von Ceph nichts von der Portänderung sondern nur in den verschiedenen Versionen der Dokumentation.

Nachdem das repariert war, wollen auch alle virtuellen Maschinen wieder hochfahren. Ein stichprobenartiges fsck (Dateisystemüberprüfung) fand nirgendwo Fehler.

Woran lag's also?

Ursächlich war die kaputte Glasfaserstrecke zwischen Vaihngen und der Innenstadt. Dies hat zu Paketverlusten geführt aber der Link war noch da und deshalb sah das Routing keinen Grund, die betroffene Strecke nicht zu nehmen. Dem Ceph kann man hier nichts vorwerfen, Zitat:

und halb-kaputtes "Kabel" fickt am Ende jedes System

Das zweite Problem war, dass sich das Ceph nach Abschalten von einem der drei Knoten nicht wieder zu einem funktionierendem Zustand zurückkehren konnte. Weshalb wissen wir noch nicht. Die Firewallregeln von oben kann man ausschließen, da alle anderen OSDs auf nicht gesperrten Ports liefen.

Das dritte Problem war, dass die Firewall auf den storage-nodes falsch konfiguriert war. Weshalb das davor nicht aufgefallen ist wissen wir nicht genau. Wir vermuten, dass die OSD's bis jetzt immer zufällig auf den 'freigeschalteten Ports' liefen und das mit der neuen Version von Ceph sich der Bereich der Portnummern geändert/erweitert hat.

Was wollen wir noch verbessern?

Wir vermuten, dass durch die OSD-Crashes wegen kaputtem Netz einige Objekte nur auf storage-2 ge-ack-t waren, der restliche cluster hat diese dann nach dessen abschalten nicht gefunden und I/O blockiert. Deshalb konnten storage-1 und storage-3 sich nach abscahlten von storage-2 nicht mehr syncen.

Um das in Zukunft zu verhindern überlegen wir uns gerade wie wir unser Routing (OSPF) verbessern können. Folgende Möglichkeiten werden im Moment diskutiert um bei defekten Verbindungen die Routen möglichst schnell über andere Verbindungen laufen zu lassen:

  • BFD (Bidirectional Forwarding Detection): Hierbei werden zwischen zwei Routern viele Pakete hin und hergeschickt. Sollten einige Pakete nicht oder nicht intakt ankommen wird der Link automatisch deaktiviert. Die Folge: OSPF baut die Routen neu und der Pakete nehmen einen anderen Weg.

  • OSPF Metriken: Der defekte Link (Glasfaserstrecke) ist die (geographisch) längste die wir im Moment haben. Es bietet sich hier an die Metriken aller Links im Wohnheimnetzwerk über ihre Entfernung voneinander in Kilometern zu setzen.

  • Carrier-Delay: Wenn ein Link instabil ist und häufig an/aus geht (flappt) müssen alle OSPF Teilnehmer (Router) ihren "Shortest Path Baum" neu bauen. Carrier-Delay sorgt dafür, dass ein Link erst dann verwendet wird wenn dieser eine gewisse Zeit stabil läuft.

  • Dampening: Immer wenn ein Link down geht, bekommt dieser Link einen Malus (Penalty). Sollte diese über einen Schwellenwert steigen wird der Link deaktiviert. In bestimmten Zeitabständen wird der Penalty Wert halbiert.

Jul 24, 2017

Network Debugging: Rogue Router Advertisements

In the last few months we observed weird behaviour regarding some of our servers that resulted in our servers not being able to reach the internet over IPv6[1]. The servers could reach other devices within the same layer 2 network but not much else.

[1] The current standard protocol alongside the ancient IPv4 protocol that has been deprecated in the year 1998.

On digging further we discovered that there was an additional default route to the linklocal fe80::0123:45ff:fe67:89ab IPv6 address.

$ ip -6 route
2001:db8::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2001:db8::254 dev eth0  metric 1024 
default via fe80::0123:45ff:fe67:89ab dev eth0  proto kernel  metric 1024  expires 1717sec hoplimit 64 

At first we just removed the additional default route from one of the servers.

$ ip -6 route del fe80::0123:45ff:fe67:89ab dev eth0

But this only worked for about 2 minutes. After that the additional default route appeared again.

Since the IPv6 address included the 'ff:fe' pattern we knew that this is in fact an autoconfigured address.

Therefore with some quick searching we found out the brand of the device.

By looking at the switch the servers were attached to we could also find the port of the device in question because we knew the MAC address.

Digging deeper we suspected router advertisements as the culprit (because the bad default route reappeared after a short time).

Running tcpdump on all 3 of our virtualisation servers confirmed that the problem persisted in both server networks (Allmandring and Heilmannstraße) and was in fact caused by 2 devices (one in each server room).

$ sudo tcpdump -vvvv -ttt -i br-server icmp6 and 'ip6[40] = 134'

The devices causing the problem were our Cisco ASAs. This is a VPN/Firewall/... appliance. We only use the VPN functionality and all functionality not related to VPN has been deactivated on both devices.

But since most organisations that operate this kind of device use it primarily as a firewall appliance - we suspect by default - router advertisements are turned on for the main network interface to divert all traffic through the device. (In our case this did not work because the Firewall/Gateway functionality was deactivated entirely so the packages sent from the different servers were just dropped.)

Temporarily the problem could be fixed by disabling the auto-learning of default routes (and removing the defective default routes on the affected servers).

$ sudo sysctl net.ipv6.conf.all.accept_ra=0

After deactivating router advertisements on the two ASA devices the problem could be solved without reconfiguring every server and without having to keep this in mind for future deployments. We are now looking into implementing RA Guard. :-)

PS: Instead of staring at the manpage the arguments for tcpdump have been copied shamelessly from https://gist.github.com/hgn/383308615d8c96551afa.


Update 2017-10-31: In August 2017 we overhauled our virtualisation Servers so they are basically routers.

In this scenario there is no single network bridge on the virtualisation Server but every virtual machine has it's own network interface on the VM Host including a BGP Daemon, a NDP Proxy and an ARP Proxy.

Once a VM is booted up the interface on the host system becomes active and the BGP Daemon announces the IP addresses of the VM to the network.

This does not only mitigate the problem (because rogue router advertisements are not proxied to the VMs) but also makes it possible to live migrate all VMs to the different virtualisation hosts even without having "one unified" server network.

With this one can save a lot of money for routers capable of Layer-2-VPN / EVPN and still be able to live migrate VMs. Also there are cases where you do not want to or simply cannot aggregate or even renumber old subnets so a L2VPN would not help anyway.

We plan to describe what we did in detail later in another blog article.

Next → Page 1 of 2