Eine Idee:
Wie sich ja herausgestellt hat, ist ein Großteil der Hintergrundrauschens durch die Router Advertisements, die jeder Gluon Node durch Radvd ablegt, bedingt. Verstehe ich das richtig?
Ist es nötig, dass das auf allen Routern ständig läuft?
Könnte ein Router nicht erst auf Advertisements warten und nach einem Timeout erst selber Radvd einschalten? Erfüllt Radvd einen weiteren Zweck, zu dem es auf jedem Router gebraucht wird?
Dazu haben wir bereits einen Thread aufgemacht 
Siehe:
Wir werden wohl nicht drum herum kommen, batman-advanced auf kleine Wolken auf der Wifi-Seite zu beschränken. Also über VPN und zwischen diesen Batman-adv. Wolken nur noch Layer3 Routing zu benutzen. Z.b. mittels bmx6.
Der Hintergrundtraffic steigt entgegen des allgemeinen Wissen eben nicht nur mit jeder Node sondern auch mit jedem Client. Dies macht die Skalierbarkeit natürlich zur nichte, daher konzipieren wir momentan ein neues System.
Die Umstellung auf ein anderes Protokoll und Absplitten der Wolken mit lokalem DHCP ist etwas, was meines Erachtens eher mittelfristig möglich ist, da die Eingriffe doch vergleichsweise groß sind.
Oder anders: Nichts was man schon morgen als beta/dev-Firmware testen könnte.
Meiner Meinung nach könnte man schauen, ob man radvd wirklich Netzweit brüllen lassen muss auf jedem Plasterouter für jeden joinenden Client.
Oder ob es es nicht reichen würde, die Neighbor-Discovery (wie?) über den Supernode zu aggregieren und dann komplette Tabellen nur periodisch upzudaten.
(Und bis dahin eben wenn wirklich lokale Dienste im Zugriff benötigt werden, mit Arp-Requests zu leben.)
Aber vermutlich stelle ich mir das in IPv4-Denke jetzt zu simpel vor.
Was zum Beispiel schon sinnvoll wäre:
Die TTL von RA Packets vom Router im Prinzip auf 1 begrenzen.
Wie sehen die Beschränkungen von BMX6 denn aus? Wie viel Traffic entsteht dort?
Also Radvd wird auf den Nodes beschränkt und nur an die Clients weitergegeben. Dies kann man in den Eb-Tables Filtern sehen:
Da muss also nichts mehr eingeschränkt werden, es ist einzig und allein der Fakt das die Clients Ipv6 verwenden und natürlich mit den Supernodes kommunizieren können müssen.
BMX6 arbeitet auf Layer3, hiermit würden in dem „neuen Konzept“ die Layer2 Wolken untereinander verbunden werden. Roaming usw wäre nur innerhalb der Layer2 Wolken möglich, diese wären auf der Funkseite durch VLANS voneinader getrennt.
Batman-Advanced ist auf Netzwerke bis zu 30-40 Nodes ausgelegt, dann ist das Hintergrundrauschen noch ertragbar.
Mit Tricks kann man dies auf 200-300 Nodes hoch treiben, allerding sieht man dann die üblichen Symptome: Hoher Hintergrundtraffic, weniger Bandbreite für Nutzlast usw.
Heißt das BMX6 überrollt nicht mit Traffic?
Der radvd auf den Knoten selber verteilt die Announcements nicht im Mesh weiter, sondern sendet diese nur an lokal verbundene Clients.
Ansonsten: Ich arbeite schon länger an einem Konzept um das Grundrauschen zu reduzieren ohne umständlich in lokale Wolken trennen zu müssen. Bei Router Advertisements wäre mein Vorschlag, die default routen der Gateways und Prefixe nur zwischen den Knoten zu verteilen und daraus lokal am Knoten Routeradvertisements für die Clients zu bauen. Der Knoten selber ist dann default gateway des Clients und routet die Pakete zu den entsprechenden Gateways. Das Konzept sieht vor, dass vierschiedene Gateways unterschiedliche /64-Prefixe announcen können und der Knoten dann jeweils nur über die Gateways routet, die für die entsprechenden Sourceaddressen nötig sind.
Man würde bei dem anderen Konzept das Rauschen auf die kleinen Layer2 / Batman-Adv Wolken beschränken, also indirekt Ja.
Allerdings funktioniert dies anders als das jetzige Prinzip und würde auch mehr Dezentralität erlauben da man auch Communities untereinander Verbinden kann. (Beispiel wäre hier ein Wifi-Link zwischen zwei Communities, dies würde bei einem puren Batman-Adv. Netz arge Probleme verursachen.
Man könnte also auch sagen: Bevor man Wifi-Backbones überhaupt plant, sollte Layer3 Meshing in Gluon eingebaut werden ;).
Naja bei uns gäbe es da schon ein Problem: Die Wolken haben teilweise mehrere Uplinks zu unterschiedlichen Supernodes, so würde man das ganze auf der Wifi Seite wieder vermischen. Zumindest ist dies in allen meinen Überlegungen, Batman-Adv weiter skalierbar zu machen, aufgefallen.
Wo ist dabei das Problem?
Das Problem ist das wenn wir mehrere Wolken verbinden das Rauschen das wir dann aus dem VPN entfernt haben auch im Wifi haben und kostbarer Airtime verlieren. Hier sollte falls möglich so gut wie gar kein Layer2 Traffic fließen. Daher auch unsere Überlegung dies zu segmentieren
Achso. Mein Plan sieht vor danach pro Knoten zwei disjunkte layer2 Netze zu haben: Das batman layer2 Netz zwischen den Knoten und jenes für die Clients. Der Knoten routet dazwischen (Layer3). Sobald das läuft, können wir das batman layer2 durch beliebige andere, multicastfähige Meshprotokolle tauschen (also auch layer3 Protokolle).
Zusätzlich gibt es dann einen kleinen Daemon, der das Roaming der Clients quer durchs Mesh (und bei passender Konfiguration und Absprache) ggf. auch über’s IC-VPN hinweg.
Das klingt sehr gut 
Also im Grund gar nicht so verschieden von unserem Ziel.
Ich würde mich freuen wenn wir zusammen daran arbeiten könnten, gerne kannst du auch in Rheinufer Zugriff auf ein paar Nodes bekommen falls dies hilft.
Ich habe da ein kleine Wolke von 4-5 Nodes die ich auch für meine Firmware Release Tests verwende.
Zeitlich sieht das ganze in etwa so aus:
Vielleicht hast du ja Lust an einigen Punkten davon mitzuarbeiten?
Könnte man das als Schritt zu einer Freifunk-weiten Firmware benutzen? Also auch über Domänen- und Vereins-Grenzen hinweg meshen und routen?
Jetzt hast Du aber „Jehova“ gesagt…
Äh. Abgesehen davon, daß es „den“ Freifunk prinzipbedingt nicht gibt … möchte glaube ich niemand Inter-Community-Verbindungen über 841er?
Huch, und ich dachte, wir würden eigentlich gerne am besten deutschlandweit meshen, wenn es technisch möglich ist.
Warum nicht?
Klar, dass Routing müsste dann so intelligent sein, dass nicht der gesamte Verkehr zwischen den Communities durch die Plaste-Router geht. Sollte aber doch machbar sein.
Und gerade, weil es den Freifunk prinzipbedingt nicht gibt, wäre eine möglichst große technische Interoperabilität zwischen den unterschiedlichen Interpretationen doch wünschenswert. Dann kann man sich nämlich wirklich frei entscheiden und muss sich nicht der Vereinsmeierei, die vor Ort die Hoheit errungen hat, anschließen, bloß damit das mit dem Meshen auch funktioniert.