Da wir momentan knapp 800-900 Nodes + 1400 Clients haben, müssen wir einen letzten Netsplit für Rheinufer durchführen.
Hierfür werden die vorhandenen Supernodes in 3-4 Kollisionsdomänen aufgeteilt. Allerdings gibt es dafür noch Entwicklungsarbeit die anfällt.
Gluon muss angepasst werden um auf dem Wifi-Interface mit VLAN’s so arbeiten, dies ist notwendig da wir an einer neuen Netzwerkarchitektur arbeiten und es für die Migration anschließend einfacher ist.
Dazu sei gesagt das wir, sobald die neue Architektur läuft, die 4 Subdomains wieder zu einer zusammenfügen werden.
Der Split wird wenn alles gut läuft in den nächsten 2-3 Wochen stattfinden, dies ist abhängig davon wie schnell die Änderungen in Gluon angewendet werden können. Außerdem müssen die Ansible Playbooks angepasst werden da wir keine manuelle Konfiguration durchführen.
Wenn ich mich nicht täusche kann Gluon bereits VLAN auf dem mesh WLAN Interface. Allerdings kommen die status-seite und ggf. die Kartendarstellung noch nicht ganz damit klar. Wären verschiedene ad-hoc Zellen-IDs keine Lösung?
Ah das wusste ich nicht, das erleichtert die Arbeit natürlich
Naja wir haben das Problem das wir auf der Funkseite bald genügend Verbindungen haben das wir dort mit dem Broadcast Traffic zu viel Airtime belegen.
Daher sollten die Bat-Adv Inseln mittels Layer3 untereinander verbunden werden. Wir zielen hier auf die Libremesh Architektur:
Der Cloud Identifier (Basiert auf der Client AP SSID) der dort verwendet wird wäre bei uns dann z.b. ein Feld im Config-Mode.
Natürlich ist noch einiges zu tun bis wir soweit sind, aber die Libremesh Firmware gibt es bereits zu Download inkl. OpenWRT feed. Es wäre also möglich dies für Gluon zu portieren (Denn der Firmware Builder von Libremesh ist nicht so schön). Dies in Verbindung mit dem verteiltem DHCP + DHCPv6 / SLAAC wäre das Ziel
Gluon ist nur ein Framework, es ist ein Werkzeug um Mesh-Firmwares zu bauen. Eine Gluon „Lösung“ gibt es so gesehen nicht, die Lösung selbst liegt in den Paketen und der verwendeten site.conf bzw site.mk .
Evtl werden die Pakete dann auch später bei Gluon im Paketerepo landen, dies bleibt den Devs überlassen.
Im Bereich Moers und Kleve wird es bald deutlichen Zuwachs geben (in Moers gedeit es schon jetzt deutlich). Außerdem migrieren die Krefelder gerade in die Niers wie ich gehört habe.
Krefeld, Kempen, MG, Viersen und was da so noch westlich des Rheins rumwuselt sind übrigens in eigenen Ruhrgebiets Subdomänen und deshalb aktuell nicht in der Ruhrgebiets und Vereins Map zu sehen!
Aber im Falle des Ruhrgebiets soll das auch so gesplittet bleiben (und noch mehr gesplittet werden), denn wir finden es alle ziemlich gut, dass die Communities vor Ort stärker in die Serveradministration einbezogen werden, statt alles zentral zu (dikitieren) steuern.
Schön wäre auch wenn Ratingen beim Rest des Kreis Mettmann bleiben könnte. Wir haben uns doch gerade est aneinander gewöhnt im Kreis
Und das sage ich als Nichtratinger.
Der Split hat rein technische Gründe. Man sollte sich vor allem überlegen, was die optimale technische Lösung ist.
Wenn ihr also mittelfristig Pläne habt, euch mit einer Nachbarstadt per Richtfunk zu vernetzen solltet ihr natürlich in der selben Domäne sein. Wenn nicht, dann sollte man imo eher drauf achten, dass die Rheinufer-Knoten möglichst gleichmäßig aufgeteilt werden, und danach die Grenzen ziehen.
Meint ihr damit den Split auf Basis des kombinierten Layer2/3 Mesh auf Basis von libre net oder das vorläufige Vierteln des Netzes auf Basis der derzeitigen Technologie.
Je nachdem würde ich die Pläne in Aachen das Netz im Juli zu splitten auf Eis legen und auf eure Lösung warten.
Exakto Mundo. Ich würde mich freuen wenn wir hier mal zusammen quatschen könnten um die Router in Krefeld, die sich noch in Rheinufer befinden, ins Niersufer zu Migrieren.
Wir migrieren erst mal auf einen Zwischenstand um später einfacher auf die neue Architektur zu wechseln.
Es wird sich nicht nur die Clientseite ändern sondern auch die „Supernodes“, diese werden in der neuen Architektur obsolet. Wir werden nur noch große Fastd-Server brauchen welche Layer3 routen, völlig uninteressant welche Community/Domain darüber läuft. Also quasi eine direkte anbindung des Meshs an das Backbone ohne Zwischenstopp auf „zentralierten Strukturen“ wie @adorfer es beschreibt.
Hohl mich doch mal ab.
Ich denke ja schon das es die Supernodes weiterhin geben wird. Batman wird dort halt durch „LibreMesh“ ersetzt. Es macht doch nicht so viel Sinn das direkt auf dem Backbone zu betrieben (Last).
Nur die aktuell stattfindende Stückelung konnte dadurch minimiert werden.
Ist den jemand von euch am Wochenende auf dem Freifunktag in Essen und kann das näher Präsentieren?
Nicht ganz, die Supernodes werden stateless. Somit ist es egal welche community drüber läuft da bmx6 (Batman Layer3) jede Wolke announced in diese in Quagga und Co direkt propagiert werden können.
Somit brauchen wir nur noch ein Pool an Servern, natürlich könnt ihr weiterhin eure eigenen Server betreiben, aber es ist halt nicht mehr notwendig unbedingt die von der „Domain“ zu verwenden.
Wir können so horizontal skalieren und müssen kein Geld mehr aus dem Fenster werfen für ineffizientes vertikales Skalieren.
Supernodes wird es in dem bisherigen Sinn nicht mehr geben. Derzeit funktionieren die Supernodes in drei Funktionen:
Endpunkt für VPN-Tunnel (fastd)
Nodes im Mesh (batman-adv)
Router für Rheinland Backbone (batman gateway)
Wir wollen batman-adv nur dazu einsetzen, um Standorte innerhalb ihrer selbst, aber nicht unter einander zu verbinden. Die Standorte sollen mittels bmx6 verbunden werden. Die bisherigen Supernodes sind dann weiterhin Endpunkte für VPN-Tunnel, fungieren aber als bmx6 Nodes.
Das ist insofern um Größenordnungen effizienter, als dass bmx6 erstens nicht auf Broadcast-Paketen fungiert, also nur die jeweiligen Nachbarn Pakete austauschen und zweitens nur bei Änderungen der Topologie ein wesentliches Aufkommen an Traffic auftritt. Sobald die neue Topologie an alle Knoten propagiert ist, sinkt der Traffic wieder auf ein Minimum.
Sobald wir diese Infrastruktur realisiert haben, können wir wieder beliebig viele Domänen zusammenlegen, da die Standorte nun die Broadcast-Domänen werden. Der Traffic auf dem Backbone der Domäne steigt nämlich nicht mehr mit Anzahl der Clients, sondern nur noch mit deren tatsächlicher Nutzung (Payload).
Die Payload-Kapazität der 10 Rheinufer-Server liegt insgesamt bei mehreren hundert Megabit. Dies genügt bei mobilen Netzen wie dem unsrigen heutzutage für mehrere Tausend Clients.
