Aus gegebenem Anlass und begonnenem Richtfunkausbau mehren sich Sorgen um die Skalierbarkeit des Netzes.
Die naheliegende Lösung ist die Teilung des Netzes in mehrere Subnetze.
Dummerweise gibt es in Darmstadt nur EIN Zentrum, so dass wirksame Teilung immer die Stadt zerschneiden würde.
Zu lösende Probleme sind:
Roaming, wenn Clients die Netzgrenze überschreiten
Umgang mit Richtfunkstrecken, die die Netzgrenze überschreiten
Am wünschenswertesten wäre (meiner Meinung nach), das Netz nicht zu teilen. Allerdings steigt damit der Verwaltungstraffic weiter an (linear mit Netzgröße). Für die Nutzer von Volumentarifen stellt das bereits ein Problem dar; 10kB/s Background sind 36MB/h, 864MB/d oder 26GB/Monat.
Lösungsansätze müssen also die Datenmenge reduzieren. Hier bleibt:
Umstellung auf babel
Optimierung von BATMAN zur Reduktion der Datenmenge.
Zu babel kann sicher hexa mehr sagen, soweit ich weiß ist Roaming das wesentliche Hindernis.
Zur Optimierung von BATMAN:
Das Layer-2-Netz, das der Haufen von BATMAN-Knoten aufspannt, ist flach. Jeder Client (auch das Gateway) ist gleichberechtigt und es gibt keine zentrale Organisation. Daraus folgt, dass dass jeder Knoten regelmäßig Informationen über alle Clients bekommen und verarbeiten muss. Zur Zeit werden diese Daten alle 5 Sekunden ausgetauscht. Eine Verlangsamung ist nicht mehr wirklich denkbar, weil das Netz sonst zu träge auf Veränderungen reagiert. Eine Verbesserung um Größenordnungen ist hier nicht erzielbar.
Denkbar wäre, das Netz geografisch zu unterteilen und deutlich seltener (Minuten, Stunden?) eine Liste der Knoten im betreffenden Netzsegment zu verteilen. Ein Knoten an der Grenze würde also sehr viel seltener Nachrichten über die Grenze gelangen lassen. Die Pakete werden wie bisher auf Layer 2 vermittelt, was Roamingprobleme ausschließt.
Trennung des Netzes:
Wenn das Netz getrennt werden würde, müsste eine Lösung entwickelt werden, wie Richtfunkstrecken segmentübergreifend gebaut werden (das Roamingproblem würde dann als gegeben hingenommen werden - vielleicht nicht gerade in der Mitte vom Luisenplatz teilen…).
Dafür muss a) eine Routerfirmware entwickelt werden, die die Netze koppeln kann (eventuell nur auf x86-Basis, wer ernsthafte Richtfunkgeräte aufbaut, kann auch einen Futro hinstellen) und b) ein Weg gefunden werden, das an die Clients zu verteilen. Der Weg in ein anderes Netzsegment wäre damit theoretisch möglich, es fehlt aber immer noch ein Weg, die Routen zu bewerten (Möglicherweise ist der Weg über das Gateway besser).
Ich halte mich etwas zurück da ich mir nicht zutraue genügend Skills beitragen zu können bzgl der Entwicklung einer Lösung. Dafür kenne ich mich zu wenig aus, ihr wisst ja ich bin der Handwerker der Spaß an RiFu hat und nicht der Firmwareentwickler
Aber mein erster Gedanke den ich schon vor über einem Jahr hatte ist nach wie vor der Hotfix eine eigene Site für das RiFu Only zu machen. Also alles was ich mit den anderen Teilnehmern so verbinde über lange Strecken muss halt in diese Site. So verhindern wir ungewolltes L2 Bridging. Ich verstehe ja das das desaströs wäre.
Mir ist bewusst, dass dies nicht die endgültige Lösung ist, nix mit Backbone zu tun hat und stark auf die Anwendung bezogen ist. Aber bevor das Ausrollen der Sites für das gesamte FFDA Netz nur daran scheitert weil ich gerne mit anderen über viele km Strecken aufbaue und gerne große Striche auf der Karte sehen möchte sehe ich das doch als eine vorrübergehende Lösung an bis was handfestes und funktionierendes Verfügbar ist.
Andererseits möchte ich halt auch nicht darauf verzichten Freifunk über die ganzen Links zu schicken. Wir investieren viel Zeit und Geld da rein. Klar laufen die Links auch ohne Freifunk aber schade wäre es schon.
Ich möchte heute nur auf den aktuellen Stand eingehen, das ufert sonst aus. Dazu habe ich folgenden Gedankengang:
Wenn wir das aktuelle Mesh in viele kleinere Meshs teilen, …
… dann ist es kritisch dass diese nicht gebrückt werden Das hätte zur Folge dass die brückenden Knoten die Originator Tabelle (quasi eine Layer 2 Routingtabelle) in das jeweils andere Netz leaken.
… dann müsste m. E. nach ausgehend von der Gateway-Farm alle Mesh-Netze in ein VLAN verpackt werden, und können dann erst transportiert werden
Nicht jedes VLAN muss in jede Himmelsrichtung transportiert werden.
Alle Geräte auf dem Transportweg müssen sich über die VLAN ID Allokation einig sein.
Insbesondere wenn die Geräte von einer Vielzahl Personen betrieben werden sehe ich hier Probleme alle Maintainer zeitnah wegen Konfigurationsaktualisierungen zu erreichen.
… dann muss Firmware-Support für die (automatische) Wahl der korrekten Mesh-Domain eingebaut werden. Dazu existieren derzeit zwei konkurrierende Vorschläge in Form eines Pull-Requests gegen Gluon, die beide noch evaluiert werden müssen. Nur einer wird letztlich gemerged werden, die Entscheidung ist noch nicht gefallen.
Weniger Konfigurationsaufwand an den Richtfunkstrecken durch Transport der Mesh-Netze über ein einzelnes L2-Netz.
Die Trennung könnte dann bspw. durch VXLAN erfolgen.
VXLAN ist ein Protokoll zum Transport von Layer 2 Domänen über UDP
Für den Transport sollten wir die MTU der Richtfunkstrecken auf bspw. 1600 Byte anheben, damit Pakete mit 1500 Byte Größe nach Enkapsulierung durch VXLAN ohne Fragmentierung transportiert werden können.
Nachteil: Dort wo ein Mesh-Domain aus dem VXLAN ausgeleitet werden muss, benötigt es einen kleinen Router, der die VXLAN Terminierung vornimmt.
[…]
Muss hier pausieren, mal abspeichern, bevor der Text verloren geht. Gedanken sind noch nicht zu Ende.
Ich liebäugle da mit den APU2/3 von PC Engines (http://pcengines.ch/apu2.htm), die kommen mit drei Intel NICs, einem seriellen Konsolenport (bspw. für einen Managed Switch), hätte via MiniPCI Express noch die Möglichkeit bspw. ein Management WLAN zu verbauen. Außerdem sind das x86_64 Systeme mit ECC-RAM.
Wenn ich weiterdenke, dann sollen diese Geräte in einem späteren Babel-Netz auch als (mesh-only) Router fungieren, so dass dort nicht nur VLANs terminiert werden, sondern das Gerät aufgrund der Babel-Metriken Routingentscheidungen für eingehende Pakete trifft.
Bei Varia kosten die mit Gehäuse und Netzteil ab ~160 €, siehe http://varia-store.com/advanced_search_result.php?keywords=apu2 und können mit weiterem Zubehör bis hin zu SSD und Rackmount-Kit versehen werden.
Für jemanden der nur ein VXLAN terminieren möchte eignet sich auch sicherlich sowas wie ein Futro, oder bereits bestehende Infrastruktur.
Klar, du leitest das VLAN was wie VXLANs transportiert in deine VM und terminierst beispielsweise dort in ein weiteres VLAN, dass du dann intern routen kannst wie du möchtest.
Ich würde das allerdings nicht mit OpenWrt bauen, sondern wie den Backbone auf ein generisches Linux aufsetzend. Ich persönlich verstehe dafür zu wenig von OpenWrt, als dass ich sowas zeitnah damit realisiert bekäme.
