Sturm im Rheinufer vorüber

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.

http://fastd.readthedocs.org/en/v17/releases/v17.html

4 Likes

Es wäre sehr hilfreich, in die Kommentare der Blacklist betroffene Node-Namen oder zumindest Mac-Adressen hineinzuschreiben.
Denn seinen public-fastd-Key dürfte so ziemlich keineR der Betroffenen erkennen.

2 Likes

Hallo mic,

ich bin mir gerade auch unsicher, wie ich es verstehen soll.
Wird das Update via autoupdate ausgerollt oder soll/muss dies manuell geschehen?

Ich habe mir die pubkeys meiner Nodes zumindest nicht aufgeschrieben ;D

@Nomaster meint damit alle Nodes die keine Konnektivität zu den Supernodes mehr haben und welceh eine veraltete Firmware haben. :slight_smile:

Hängt das kürzliche Snapshot-Release von @thomasDOTwtf damit zusammen?

Normalerweise werden auch die Namen beigeschrieben zur Identifikation, das war in diesem Krisenszenario vermutlich einfach nicht möglich noch zu versuchen die Namen herauszufinden.

Thomas rollt prophylaktisch die Ruhrgebiets Änderungen schon mal in Möhne aus, um in diese Falle gar nicht erst zu tappen.

Die ULA Adressen sind für uns aber auch nicht wichtig. Selbst ohne Tunnel wird lokal das public Prefix announced, ohne Tunnel sind die Adressen dann nur nicht aus dem Internet erreichbar - sind die ULA aber ohnehin nicht.

Nachtrag zu den Tunnelverbindungen:

Ich hatte mir zumindest teilweise die pubkeys aufgeschrieben und konnte deswegen

„pubkey“: „085c4af980f6b8d4bf6d2c8d7b0641efa6129696cdd7a79346d7bb00ac8d73dd“,
„comment“: „Broadcast Storm #8

einer von mir betreuten Node zuordnen. Die Node wurde erst vor einigen Wochen aufgestellt und läuft mit der aktuellen Firmware.

Da die betroffene Node noch über das Mesh mit dem Internet verbunden war, kam ich mit SSH auf die Node. Obwohl die Node vorher schon mit 2014.4-stable-3 lief, habe ich habe nochmal auf die aktuelle Firmware geupdatet. Da das keine Besserung brachte, habe ich versucht manuell einen neuen Key generieren lassen:

uci set fastd.mesh_vpn.enabled=1
uci commit fastd
/etc/init.d/fastd generate_key mesh_vpn

Nach einem Reboot und zehn Minuten hat die Node wieder zwei Tunnel zu den Supernodes aufgebaut.
Mich verwirrt aber gerade sehr, dass ich immer noch den alten pubkey angezeigt bekomme:

root@FF-KLE-KLE-SuppenSchwaermerei:~# /etc/init.d/fastd show_key mesh_vpn
085c4af980f6b8d4bf6d2c8d7b0641efa6129696cdd7a79346d7bb00ac8d73dd

Hast du dir den das eigentliche Problem mal angeschaut, bevor du wieder ins Netz spammst?

Dazu müsste würde mich interessieren, was man da überhaupt anschauen kann, wenn denn -wie hier beschrieben- bereits die aktuelle Firmware im Autoinstaller auf dem Gerät war und das Gerät weiter Amok gelaufen ist.

Vorsicht: der Broadcast-Sturm geht möglicherweise von einem anderen Node aus. Du hast gerade lediglich einen Uplink-Node behandelt. Bei der Begrenzung des Broadcast-Sturms konnten wir nichts anderes tun, als diejenigen Nodes per VPN aussperren, die am selben Standort stehen wie eine problematische Node und den Sturm ins VPN verteilen.

Bitte checke alle Nodes an Deinem Standort durch, damit wir nicht gleich erneut Broadcast-Sturm im Netzwerk sehen und Deinen Standort dann wieder aussperren müssen.

Es gibt zwei weitere Nodes in Meshreichweite in der Gegend. Diese beiden sind direkt mit dem Internet verbunden, bauen ganz normal Tunnel auf und wurden nicht gesperrt.

Cool. Dann hoffen wir mal, dass es wieder läuft. Danke für den Einsatz!

1 Like

Wenn dem so war wie hier geschrieben, ließe sich dieses „Problem“ wie folgt endgültig lösen:

Auslagerung aller Server in ein eigenes Netzwerk, welches per Routing mit dem Freifunk Client-Netzwerk verbunden ist. Damit entfällt sämtliche Neighbor Discovery zu den Servern. Die einzigste Adresse die von den Clients discoverd werden muß ist der default Router. (Und umgekehrt.)

3 Likes

Kurzes Feedback:

„pubkey“: „0a82c608203c1cc98d7e7d3bc1eb487b6dadb0d15c83829707635d6164a8dc2c“,
„comment“: „Broadcast Storm“

war:
Hostname: freifunk-NE-GlehnerWeg
MAC-Adresse: f8:d1:11:76:a0:d0
Hardware-Modell: TP-Link TL-WR741N/ND v4
Gluon-Version: v2014.3
Firmware-Release: 0.4+3-exp-2
Site: Freifunk Rheinland - Rheinufer
Öffentlicher VPN-Schlüssel: 0a82c608203c1cc98d7e7d3bc1eb487b6dadb0d15c83829707635d6164a8dc2c

2 Likes