Aufgrund der momentan heiklen Lage bezüglich der Batman-Advanced Skalierbarkeit, bin ich dabei andere Konzepte zu testen.
Batman-Advanced wird in naher Zukunft vom VPN verschwinden und gegen Layer3 Routing ersetzt werden.
Dies ist alles schön und gut aber leider nicht schnell genug (Dies ist kein Vorwurf an die Entwickler ).
Momentan wird mit Geld nach Problemen geworfen: Neue Supernodes werden aufgestellt, Unsinnige Netplits durchgeführt die zwar temporär Abhilfe schaffen jedoch das Problem nicht lösen usw. Außerdem wird auch die Funkseite irgendwann zusammenwachsen und wir werden das selbe Problem erneut über Wifi bekommen.
Generell sollte auch die Community-Bildung in der Hand der Communities bleiben, dies ist mit der momentanen „Supernode“ Struktur nicht möglich. Es wird immer ein Admin benötigt der die Supernodes betreibt oder auch Debugging betreiben kann. Dies ist schlichtweg unpraktikabel wenn man für ein paar Nodes eine eigene Kollisionsdomäne möchte.
Kollisionsdomänen sollten vom Node-Bertreiber auswählbar sein, damit auch die Möglichkeit selbst zu Skalieren (z.b. eine eigene Kollisionsdomäne für die belebte Einkaufsstraße falls man merkt es wird zu lahm).
Auf meiner Reise durch das Land der Freifunk/Mesh Firmwares bin ich über Libre-Mesh gestolpert:
Hier wird ein anderer Weg gegangen als bei Gluon (Bzw Gluon mit Batman-Advanced, denn Gluon ist nur das Firmware Framework ;)):
Ein Auszug über die Features/Anforderungen:
Scalability
Network segmentation
Layer 2 roaming inside certain areas
Smart gateway selection with redundancy and possibility of user-choice
Dies wird mittels einer Mischung aus BMX6 (Layer3 Meshing) sowie Batman-advanced (Layer2 Meshing) erreicht.
Beide laufen parallel, wobei Batman-Advanced in kleineren Bereichen verwendet wird (z.b. die oben genannte imaginäre Einkaufsstraße). Die Abgrenzung findet hier mittels VLAN’s auf dem Adhoc Interface statt, die VLAN ID wird wiederum aus der SSID errechnet. So teilen sich alle Nodes mit der selben Client-SSID eine Kollisionsdomäne.
Die einzelnen Kollisionsdomänen / Batman-advanced Inseln können sich anschließend durch BMX6 gegenseitig erreichen.
Dies ist natürlich nur eine grobe Umschreibung, wer mehr wissen möchte kann sich die Links oben anschauen.
Interessant wäre es nun diese Funktionalität sowie das momentan sich noch in Entwicklung befindene „Verteilte DHCP“ als Gluon Pakete zu bauen und zu verheiraten.
Ich denke das dies der richtige Schritt ist und uns auch in Zukunft noch skalierbare und kostengünstige Infrastrukturen erlaubt. Von der wesentlich höheren Performance des VPNs / Meshs mal abgesehen
Das klingt sehr interessant, da hier wohl automatisch die Kollisionsdomäne sich nur auf die Geräte auszudehnen scheint, die sich gegenseitig sehen. Das halte ich prinzipiell für wesentlich sinnvoller als die Kollisionsdomäne jetzt auch über VPN auszudehnen, quasi auf die komplette Domain.
„A single firmware for all the network“
Das klingt für mich etwas schwierig. Ich denke Freifunk funktioniert auch deswegen so gut, weil die Node-Betreiber nur einfach Fragen sich ausgesetzt sehen wie: welche Email, Traffic Shaping ja/nein, GPS Koordinaten etc. Bei einer einzelnen Firmware für alle möglichen Ebenen könnte ich mir vorstellen, dass es den Normalbenutzer ziemlich schnell überfordert. Vielleicht täusche ich mich, aber das ist meine Vorstellung…
Der Plan wäre dann einen gluon Zweig dafür ins Leben zu rufen? Ich wäre dabei. Allerdings bin ich eher der Netzwerker als Coder. Wäre aber auch bereit mich in gewisse Dinge einzuarbeiten.
Auch würde ich micht nicht auf jeden Punkt dort festlegen, es geht schlicht um das Prinzip. Eine Firmware für alles funktioniert ja mit Gluon schon nicht ordentlich. Bitte lasst diese Punkte erst mal außen vor, gerade bei Dingen die leicht zu ändern sind oder Ansichtssache sind. Fakt ist das das momentan im FFRL verwendete Prinzip keine Zukunft hat.
Auch wird es kein Gluon Zweig/Branch. Gluon ist nur ein Framework und damit kann man Mesh Firmwares bauen Wir würden nur eigene Pakete bauen und diese anstatt der „original“ Gluon Pakete zu verwenden.
Die Kollisionsdomänen selbst funktionieren mittels VLANs auf den Adhoc Interfaces, Batman-Advanced bzw BMX6 läuft auf zwei verschiedenen VLANs.
Die o.g. CID (Cloud Identifier) setzt fest welches VLAN für Batman-Adv benutzt wird. So kann man effektiv die Meshs trennen obwohl man auf dem selben Kanal funkt.
Ich habe am Sonntag mal einen 841er mit der LibreMesh Firmware geflasht, aber mangels Dokumentation nicht zum laufen bekommen. BMX6 war für mich schon immer ein Kandidat gewesen für die Backbone Anbindung.
Die Frage ist halt ob man mit den Komponenten die LibreMesh beinhalten, ein ebenso einfaches Setup hin bekommt wie mit dem aktuellen Gluon.
Ich hab ein X86 Image gebaut, war mir dann doch lieber
Ohne Zweifel lässt sich das mit Gluon verwirklichen, den Weg den Lübeck bzw die Gluon Devs gehen wollen ist ähnlich. Dort wäre Layer3 VPN vorgesehen und das verteilte DHCP, beides benötigt eine Art Routing Daemon. Als erster Gedanke sollte dies mittels RIPv2 geschehen, allerdings sehe ich hier BMX6 als geeigneter da wir so auch einfach BMX6 via VLAN auf dem Adhoc Interface sprechen können, so ist es ein einfaches das die Inseln und Mesh Nachbarn die Routen untereinander kennen. Außerdem brauchen wir auf der Funkseite BMX6 wenn wir z.b. mit dem neuen Geld und auf den Liegenschaften des Landes NRW ein Backbone installieren wollen. Das können wir getrost vergessen wenn wir weiterhin pur Batman-Advanced verwenden.
Batman-Advanced ist halt für kleine Bereiche mit weniger als 50 ~Nodes + 200-250 Clients am sinnvollsten. Und bevor wir jetzt alle Domains so zerstückeln das nachher keiner mehr einen Überblick hat, wäre es sinnvoller die Entwicklung etwas voranzutreiben
Das ist der Grund, warum ich häufig Augenrollen bekomme, wenn es heisst „Wir bekommen Zugang zu Turm xy“
Auf mein „Und damit tut ihr dann bitte was?“ werde ich dann als Ketzer angeschaut.
Daher: Es wäre wirklich schön, ein Richtunk-Backbone-Netz besser abbilden zu können, ohne dafür gleich in der ganz großen Liga („lokale Supernodes im Glockenturm“) spielen zu müssen.
Ja bei mir ist da die Erfahrung nicht anders, es wird allerdings teilweise gar nicht wahrgenommen. Ich hatte damals beim Switch von Freifunk Advanced → Gluon schon gesagt das wir uns Gedanken um die Skalierbarkeit des Netzes machen müssen. Dies beinhaltet z.b. das Layer3 Routing für Wifi Backbone
Vielleicht macht es ja Sinn, sich mit den Berliner kurzzuschließen. Dort gibt es ja einen erklecklichen Funk-Backbone über den Dächern der Stadt (dafür Verbindungsabbruch bei jedem Knotenwechsel wg. OLSR). AFAIK war da (vor ca. 6 Monaten) der Plan, für Plätze auf batman_adv zu gehen (wg. des Handovers/echter ESS), Backbone rennt weiter per OLSR. Ich halte das koordinationstechnisch für kaum durchführbar, aber generell muß der Weg in die Richtung gehen: sich selbst organisierende batman_adv-Wolken, die automatisch über Richtfunk oder VPN auf Layer-3-Ebene zuammengefaßt werden.
Leider ist das die Quadratur des Kreises. In der Gluon-Welt funktioniert das Hinzufügen eines Knotes, weil alles eine große Wolke ist. Habe ich in einer 500m langen Straße an jedem Ende einen Knoten, könnten beide auf L3 autark laufen. Wie aber erkennt das Netz, nachdem in je 50m Entfernung zu bestehenden Knoten mehrfach welche aufgebaut wurden, daß hier nicht mehr n Einzelnodes (mit lokalem DHCP/RA), sondern ein Mesh benötigt wird? Diesen Punkt löst AFAIK auch LibreMesh nicht Ich muß mich bei LibreMesh initial entscheiden, welchen Modus ich für den Standort wähle, lernen tut LibreMesh AFAICS nicht? Unter allem Umständen ist zu vermeiden, eine ESS zu betreiben, bei der die einzelnen Knoten eben nicht alle Teil dieser ESS sind …
Jap das hatte ich auch schon in betracht gezogen Momentan ist alles noch in „Planungsphase“, also noch kein konkretes Konzept.
Alternativ hatte ich die Idee für „Freifunker mit Bastelbedarf“, also einen Supernode mit verschiedenen Fastd Instanzen aufzusetzen. Auf jeder dieser Instanzen läuft ein anderes Protokoll. Z.b. OLSRD, BMX6 und Babel.
Dadurch können die Leute verwenden was sie wollen. Auf der Wifi Seite müsst eman nur dafür sorgen das jedes Protokoll auf seinem eigenen VLAN arbeitet.
Gerade für größere Netze suche ich hier im Internet schon seit Jahren nach brauchbaren Studien. Gefunden habe ich bisher allerdings nur teilweise Brauchbares. Gewiss ist für mich auf jeden Fall, dass babel mit einer der am besten skalierensten Algorithmen zu sein scheint. BMX6 schneidet nach meinem Gefühl auch gut ab.
Dieses ganze technische Schlamassel denke ich sollte man in einer Art „Task Force“ ausarbeiten.
Leider sind viele Spezialisten sehr verstreut über D und bekannter Maßen arbeitet man am besten Vor Ort zusammen. Da dies aber ja meistens nicht geht, glaube ich, dass man sich eben auch über die Entfernung möglichst gut organisieren und verständigen muss, damit man hinterher ein ideales Ergebnis bekommt.
Wenn es solche Strukturen noch nicht gibt, denke ich sollten wir sie ASAP schaffen.
).
Ich muß mich bei LibreMesh initial entscheiden, welchen Modus ich für den Standort wähle, lernen tut LibreMesh AFAICS nicht? Unter allem Umständen ist zu vermeiden, eine ESS zu betreiben, bei der die einzelnen Knoten eben nicht alle Teil dieser ESS sind …
Momentan ist alles noch in „Planungsphase“, also noch kein konkretes Konzept.