IPv6 Router Advertisements legen Freifunk-Router lahm

Für mehrere Tage spielte das Freifunknetz Stuttgart verrückt: Router booteten nach wenigen Minuten von selbst neu oder fraßen sich fest, Datenpakete nahmen unmögliche Wege durch das Meshnetz und verloren sich in Loops, obwohl Verkabelung und Konfiguration der Router korrekt waren. Am meisten hat es die leistungsschwächeren Router erwischt, insbesondere die am Häufigsten eingesetzten TP-Link WR841n(d).

Was war passiert?

Im FFS-Netz war die Anzahl IPv6 Router Advertisement Pakete (RA) auf eine so hohe Zahl gestiegen, dass die Router diese nicht mehr in Echtzeit verarbeiten konnten und sich mehrere parallele Prozesse aufgebaut haben, jeder von einem RA getriggert.

Das ging jeweils so lange gut, bis nicht mehr genügend RAM für „Alfred“ zur Verfügung stand. In diesem Zustand stieg die CPU-Last noch stärker an, gleichzeitig wurde das freie RAM knapper, was schließlich im Kollaps des Routers endete. Bevor er sich entweder festfraß oder neu startete, wurde noch batman-adv in Mitleidenschaft gezogen und hat die Mesh-Pakete unkontrolliert weitergeleitet – daher die Schein-Loops.

Wie konnte das passieren?

Eigentlich sollte die Rate der von den Gateways per Multicast ins Netz geschickten RA limitiert sein. Das kann entweder dadurch erreicht werden, dass die Reaktion der Gateways auf Router Solicitations (RS = explizite Anforderung eines RA) verzögert wird, so dass ein ganzer Block von RS durch ein einziges RA per Multicast bedient wird. Alternativ können nur die periodischen RA per Multicast verschickt werden, während man die RA, die per RS angefordert wurden, per Unicast überträgt und daher nur dem konkreten Empfänger zur Auswertung zustellt. So wird es in RFC 4861 definiert.

Die Realität sah aber auf drei Gateways anders aus, wo „radvd“ für das IPv6-Management eingesetzt wird. Hier wurde jede einzelne RS von diesen drei Gateways parallel durch ein eigenes Multicast-RA beantwortet und damit ins komplette FFS-Netzwerk verteilt und durchlief dabei alle aktiven FF-Router. Ursache war ein Fehler in der eingesetzten Version 1.9.3 von radvd, der die zeitliche Streuung der RA in der Default-Konfiguration verhindert hat.

Wieso hat man das nicht schon früher bemerkt?

Normalerweise macht man sich nicht die Mühe, Mesh-Traffic zu analysieren. Solange die RA-Rate unter dem kritischen Wert blieb, wurde zwar das Freifunknetz immer langsamer, aber es gab keine verrückt spielenden Router. Erst das starke Wachstum des Freifunknetzes auf inzwischen mehr als 560 aktive Freifunk-Router, die mehr als 1800 Clients bedienen, über das wir uns beim Freifunk Stuttgart sehr freuen, hat den Fehler sichtbar gemacht.

Was kann man dagegen tun?

Ohne prinzipielle Änderung an der Freifunk-Infrastruktur kann man nur auf den Gateways dafür sorgen, dass die Anzahl der als Multicast verschickten RA so niedrig wie möglich bleibt, ohne die IPv6-Netzfunktion einzuschränken, denn die kritische Marke für die leistungsschwachen Router wie den WR841 lässt sich nicht exakt bestimmen.

Bis einschließlich radvd 1.9.5 lässt sich durch eine Änderung der radvd.conf auf den Gateways das Verhalten so ändern, dass nur die periodischen RA als Multicast verschickt werden, die anderen per Unicast. Der entscheidende Parameter ist hier „UnicastOnly on“, den man im nachfolgenden Beispiel sehen kann:


interface br00
{
AdvSendAdvert on;
IgnoreIfMissing on;
MaxRtrAdvInterval 600;

# don’t advertise default router
AdvDefaultLifetime 0;
UnicastOnly on; # das ist der entscheidende Parameter

prefix fd21:b4dc:4b1e::/64
{
AdvValidLifetime 86400;
AdvPreferredLifetime 14400;
};

RDNSS fd21:b4dc:4b1e::a38:1
{
FlushRDNSS off;
};
};

Mit dem Release 1.10.0 wurde das Verhalten geändert. Ab da wird mit dem Parameter „UnicastOnly on“ kein RA mehr periodisch verschickt, kann also nicht mehr als Lösung benutzt werden.

Es bleibt nur noch die Möglichkeit, mit dem Parameter „MinDelayBetweenRAs“ die Multicast-RA-Flut einzudämmen. Wir hatten allerdings in Stuttgart bisher nicht die Gelegenheit, das in der Praxis zu testen.

Fazit:

Durch die Art und Weise, wie ein Freifunknetz auf technischer Ebene funktioniert, entsteht ab einer bestimmten Anzahl Knoten und Clients so viel interner Verwaltungs-Traffic („Hintergrundrauschen“), dass schwächere Router an ihre Leistungsfähigkeit stoßen. Der Effekt mit den RA ist dabei sicher nur der Anfang. Beobachtet man das Netzwerk im Inneren, sieht man neben den RS und RA bereits weitere Multicast-Pakete in hoher Anzahl, nämlich die Multicast Listener Report Messages. Deren Verarbeitung ist in den Routern besser gelöst, Ausfälle, die darauf zurückzuführen wären, sind bisher meiner Kenntnis nach nicht aufgetreten.

Einen wesentlichen Schritt in Richtung Stabilität werden wir mit der Segmentierung bekommen, also der Aufteilung des großen Gesamtnetzes in mehrere Teilnetze, die untereinander auf Layer 3 (Routing) miteinander verbunden sind, was als Sperre für die Multicasts bei IPv6 und Broadcasts bei IPv4 wirkt. Hier sind die Gatewaybetreiber mit Hochdruck an der Arbeit.

Für die Betreiber der Freifunk-Router (Knoten) bleibt indes nur, die Verkabelung und Konfiguration der Router gewissenhaft zu machen und damit insbesondere Schleifenbildungen zu verhindern.

An alle Nutzer des Freifunks (Clients) möchte ich appellieren, bitte auf unnötige und in der Regel nutzlose Netzwerk-Scans zu verzichten. Was in einem klassischen LAN kaum ins Gewicht fällt, potenziert sich in einem Freifunknetz mit Mesh-Struktur und führt zu Nebenwirkungen, derer sich die meisten gar nicht bewusst sind.

Zum Schluss noch ein herzliches Dankeschön an alle, die dazu beigetragen haben, Puzzle-Teile für das Gesamtbild der Störung zusammenzutragen. Egal ob aus reiner Anwendersicht („Router bootet ständig“) oder mit Tracebacks aus den Tiefen der Firmware von Technik-Freaks, jede einzelne Information war wichtig, um den Gateway-Admins die Chance für eine schnelle Lösung zu geben.

Anmerkung: Vielen Dank an Roland für das Verfassen des Artikels und das Recherchieren, woher die Probleme im Netz kamen.