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.
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.
Als Selfnet vor mehr als 17 Jahren gegründet wurde war dies nur durch eine große Anzahl an Bürgschaften, Spenden, Krediten und personeller Unterstützung möglich. Dass aus dieser Vereinigung von damaligen Studenten einmal eine so große Angelegenheit wird, hätte damals vermutlich nie jemand gedacht.
Mittlerweile sind diese damaligen Studenten bei verschiedenen Technologieunternehmen eingestiegen. Durch die nachfolgenden Generationen von Studenten ist Selfnet eines der größten Studentennetze in Deutschland geworden. Selfnet trägt sich nach wie vor nur durch Spenden, Mitgliedsbeiträge und der ehrenamtlichen Arbeit der Mitglieder selbst, ohne eine Einflussnahme von außen. Dadurch können wir technisch und auch ideell Dinge in unserem Netzwerk realisieren, welche man in einem industriellen Umfeld niemals finden würde.
Durch diese "Wir wollen dass alle Studenten eine gute Netzwerkanbindung haben" Mentalität, welche sich bis heute gehalten hat, wurde vieles verwirklicht. In den letzten Jahren kamen in der Stuttgarter Innenstadt mehrere große Wohnheime zu unserem Netzwerk dazu, unter anderem die Heilmannstraße 3-7 (190 Zimmer) und die Rosensteinstraße 1-5 (346 Zimmer) welche auch gleichzeitig flächendeckend mit WLAN versorgt werden konnten. Nach langen Diskussionen mit dem Vorstand und der Mitgliederversammlung, sowie Verhandlungen mit dem Studierendenwerk Stuttgart können wir jetzt einen weiteren Schritt gehen.
Vor einigen Wochen haben wir mit dem Studierendenwerk einen Vertrag geschlossen, welcher es uns ermöglicht in den kommenden Monaten weitere Wohnheime in der Innenstadt an unser leistungsstarkes Netzwerk anzubinden. Es handelt sich dabei um die Wohnheime
- Neckarstraße 132
- Wohngruppen im Studierendenhotel (Neckarstr. 172)
- Rieckestraße
- Kernerstraße
- Landhausstraße
- Anna-Herrigel-Haus (Nach der Kernsanierung im Februar 2018)
Die Umstellung der Wohnheime wird voraussichtlich zwischen September und Oktober vorgenommen, ein genaues Datum für jedes Wohnheim ist durch verschiedene Faktoren leider nicht festlegbar. Die Bewohner werden vor den Arbeiten natürlich noch einmal benachrichtigt.
Die Anbindung der Wohnheime wird dabei durch eine Glasfaser-Anbindung zu unserem bestehenden Netz realisiert, sodass zukünftig auch in diesen relativ kleinen Wohnheimen die Netzwerkgeschwindigkeiten pro Zimmer auf 1 GBit/s angehoben werden können. Durch die relativ hohen Investitionskosten (insgesamt etwa 200.000 €) können wir dort vorerst keine WLAN-Abdeckung aufbauen, werden aber natürlich versuchen diese in den kommenden Jahren zu realisieren.
In Zukunft wollen wir auch versuchen die noch verbliebenen Wohnheime in Stuttgart anzubinden. Ob, wann und wie schnell dies geschieht, hängt aber auch davon ab, ob wir Unterstützung von Bewohnern vor Ort bekommen. Da die Projekte wie immer von Ehrenamtlichen durchgeführt werden, suchen wir auch Leute vor Ort, die bei der Planung und Realisierung helfen möchten. Sofern du uns helfen willst in (deinem oder anderen) Wohnheimen deine Ideen zu verwirklichen: Komm einfach zum Schluss einer Sprechstunde bei uns vorbei und lass dir völlig unverbindlich alles zeigen. Wir sind immer auf der Suche nach neuen und motivierten Mitgliedern. Es spielt dabei keine Rolle, ob du dich für Technik begeisterst oder nicht. Lediglich Neugierde ist eine wichtige Voraussetzung.