TL;DR: Wer keine Verbindung hat, möge bitte unverzüglich seine Geräte aktualisieren!
Da die Broadcast-Stürme im Rheinufer nun seit ein paar Tagen nicht wieder aufgetreten sind, erklären wir diese Störung für beendet.
Am vergangenen Wochenende ist nach einer Überlastung der Supernodes das Rheinufer-VPN zusammengebrochen. Die Standorte blieben für mehrere Tage vereinzelt und ohne Verbindung zum Internet.
Als ich den Datenverkehr auf den Supernodes beobachtete, stellte ich einen Broadcast-Sturm fest. Bei diesem Phänomen ist das Netzwerk überlaufen mit Datenpaketen, die alle Teilnehmer erreichen sollen. Wenn so etwas passiert, ist für die Benutzer kein Dienst mehr erreichbar, weil in der schieren Masse der Pakete die rechtmäßigen untergehen und nicht innerhalb der Verfallszeit ausgeliefert werden können.
Meine Versuche, von den Supernodes aus das Problem zu identifizieren und zu lösen, blieben erfolglos.
Am Dienstag nahm @cyrusfox sich des Problems an und fand bald heraus, dass der Fehler nicht von den Supernodes ausging. Bei der Untersuchung seiner lokalen Freifunk-Wolke stellte sich heraus, dass der Broadcast-Sturm auch ohne Anbindung an den Rest der Welt dort auftritt. An diesem Standort befindet sich offenbar eine Node, die in einem Zustand hängen geblieben ist, in dem sie massenhaft Broadcast-Pakete verteilt.
Bei den Paketen handelte es sich um Neighbor Solicititations (IPv6). MIt diesem Protokoll (NDP) werden Nachbarn im lokalen Netz gesucht, die eine bestimmte Adresse haben. Die Systeme werden als Nachbarn gesucht, weil ihre Adresse einem Netzwerk liegt, an das das suchende System direkt angebunden ist und somit der Weg über einen Router unnötig.
In unserem Fall handelte es sich dabei um die Adresse des Maps- und Update-Servers. Dieser war am Samstag abgestürzt und wurde seit dem von sämtlichen Nodes gesucht. Beim Absturz ist anscheinend daraufhin extrem viel Broadcast-Traffic durch NDP entstanden. Dieser Traffic erreichte die Supernodes, die daraufhin diesen über alle Tunnel wieder zurück ins Netz geschoben haben. Dabei wurden vermutlich einige Nodes derart überlastet, dass sie in einen fehlerhaften Zustand gerieten.
So baute sich eine Schleife auf, in der der Broadcast-Traffic im Netzwerk unbegrenzt zunahm. Daher wurden die Systeme unserer Supernodes beim Provider auffällig, der diese dann notgedrungen abschalten musste. Die in Eile zusätzlich aufgebauten Supernodes in Berlin haben das Problem folgerichtig nicht lösen können, sondern nur schlimmer gemacht. In der Spitze habe ich Bandbreiten von 70 Mbit/s auf allen zehn Supernodes gemessen. Wir haben bei ingesamt zehn Supernodes in der Summe also annähernd ein ganzes Gigabit an Broadcast-Traffic verteilt.
Die kurzfristige Lösung für dieses Problem besteht darin, einzelne Standorte auszuschließen, an denen derzeit ein Broadcast-Sturm auftritt. An diesen Standorten ist Freifunk ohnehin nicht nutzbar und eine Behebung liegt außerhalb unserer Reichweite. Die betreffenden Standorte bleiben ohne Verbindung, bis die Nodes aktualisiert und neu angeschlossen werden. Bei einem Update auf die Gluon-Firmware wird ein neuer Schlüssel für die betreffende Node generiert und diese kann sich dann wieder mit dem Rheinufer-VPN verbinden.
Das Batman-Modul, mit dem wir das Mesh-Netz aufbauen, hat keine Optimierungen für IPv6. Daher ist der Datenverkehr über ein lokales IPv6-Netz problematisch. Um massenhafte Anfragen per NDP zu vermeiden, die zu Broadcast-Stürmen führen können, bauen wir zunächst die Verwendung von ULA-Adressen für Infrastruktur zurück. Die Map funktioniert so halbwegs wieder, muss aber noch ein paar Verbindungen bekommen, um alle Standorte anzeigen zu können. Wir sind derzeit noch dabei, das zu verbessern.
Nachtrag
Wir haben auch den VPN-Dienst fastd aktualisiert auf Version 17. Seit dem können Nodes mit alter Firmware nicht mehr Tunnelverbindungen aufbauen, da sie eine zu große MTU eingestellt haben. Diese haben wir vor ein paar Wochen verändert, da wir Probleme mit DS-Lite Internet-Zugängen hatten. In Version 16 klappte der Handshake noch, führte aber laut Entwicklern des Programms zu Problemen. Vermutlich hängt das auch irgendwie mit dem aktuellen Problem zusammen. Die Nodes müssen jedenfalls aktualisiert werden, damit sie wieder in das VPN-Netz gelangen.
