Ist halt alles noch in Planung. Ich kann aber mal versuchen ins Detail zu gehen, wie der aktuelle Stand ist.
Die Segmentierung erfolgt durch einen Hack mit fastd-Whitelists/Blacklists, die dynamisch generiert werden.
In der site.conf sind bei uns aktuell für jeden Node 100 fastd-Endpunkte eingetragen, aufgeteilt in 10 Gruppen. Der Knoten wird also versuchen, zu jedem dieser Endpunkte eine Verbindung aufzubauen.
Das „Segment 0“ lässt jeden rein, sperrt aber nach Blacklist aus, alle anderen lassen nur per Whitelist rein.
Ein uns noch unbekannter Knoten wird also jetzt verschiedene Segmente ausprobieren und irgendwann in Segment 0 akzeptiert werden, das einzige was ihn bis jetzt aufnehmen würde.
Dann wird nach einer noch zu bestimmenden Logik der Knoten einem anderen Segment zugeordnet. Also in Segment 0 in die Blacklist kommen und in genau einem anderen Segment in die Whitelist. Größtenteils wird das nach Geo-Koordinaten gehen.
Da wir für alle Segmente eine Firmware nutzen ist das Meshing immer möglich. Also ist eine automatische „Kurzschluss“-Erkennung nötig, die erkennt wenn zwei Segmente miteinander verkoppelt werden. Das würde ja dazu führen, dass BATMAN-Originators ausgetauscht würden, und Traffic zwischen Segmenten über eine dünne Uplinkleitung statt über die Supernodes fließen würde. Probleme mit DHCP gäbe es auch.
Und als ob das noch nicht genug wäre, darf diese Zuteilung auch nicht zu streng sein. Man stelle sich den Fall vor, wo jemand für verschiedene Segmente Knoten fertig macht, inkl. Geodaten, die aber alle testweise bei sich im Keller funken lässt. Da würde natürlich die Kurzschlusserkennung anschlagen und alle in das selbe Segment stecken. Wenn aber alle vor Ort im Einsatz sind sollten die natürlich zeitnah wieder in die „natürlichen“ Geo-basierten Segmente finden.
Die fehlende Entwicklungsarbeit ist also noch:
- Alfred-Daten auswerten und eine Logik befüttern, die entscheidet, welchen Segmenten ein Uplink zugeordnet wird.
- Eine Kurzschluss-Erkennung schreiben, die dafür sorgt, dass alle Uplinks in einer lokalen Wolke stets im selben Segment unterwegs sind.
Auf Supernodeseite sieht es dann so aus, dass jedes Segment ein bat00-bat10 Device ist, welches das BATMAN-Mesh terminiert. Originators würden da ja nicht rauslecken, was nach Tests bereits den Broadcasttraffic von 300 kBit/s auf 100 kBit/s reduzieren würde, womit die Nodes wieder klar kommen sollten.
Die werden testweise erstmal zusammengebridget, und dann schauen wir ob das schon reicht.
Wenn nicht bekommt jedes Segment halt ein eigenes z.B. /20 für DHCP bzw. /64 für IPv6 und dann wird per Layer 3 geroutet, was kein zusätzlicher Aufwand ist.