Erfahrungen mit Babel

Du bist mit der Skepsis „funktioniert Babel wirklich“ nicht allein.
Die Mehrheit wartet, dass andere vorausgehen und sich ggf. erstmal blutige Nasen holen.

(So wie ja viele Leute auch nach München schauen, wie sich Gluon-BatmanV dort entwickelt. Danke dafür!)

Mich überzeugt bei Babel die Aussiacht auf mehr Privacy, also dem Zuwachs an Datensparsamkeit, um von diesem Security-Nightmare eines „untrustworthy distributed L2-Switches“ wegzukommen.

Ich bin bei dir, ohne ausprobieren werden wir keine Antworten bekommen :). Und mehr potentielle Meshprotokolle ist ja auch charmant.

Auf der Suche nach Antworten auf die Fragen bin ich zum Beispiel auf das hier gestoßen:

Das wäre jetzt noch für größere Scales gut ;).

Zur Privacy Diskussion gibt es auch was nettes auf der Mailingliste von BATMAN:
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-August/013512.html

Und noch ein Dokument was ein paar Sachen vergleicht:

2 „Gefällt mir“

Vor Allem der Teil aus dem letzten Paper ist interessant, als short facts.

Hallo zusammen,

bitte nehmt doch aktuelle Quellen. Das wirklich wichtige an dem Dokument ist das Deckblatt. Da steht das Veröffentlichungsjahr drauf: 2013. Nichts von dem, was hinter diesem Deckblatt steht (inklusive der zitierten Tabelle) ist heute noch relevant. Batman hat sich entwickelt, babel hat sich entwickelt. Es kommen andere Metriken zum Einsatz und die Konvergenzeigenschaften wurden angepasst.

Bei babeld zahlt man den Preis bei der Entwicklung: Roaming geht ohne l3roamd nicht. Jemand musste den also bauen. Broadcast an alle Nodes geht nicht ohne separate Software. Es musste also entweder multicast-routing oder ein weiterer Daemon implementiert werden. Mit dem mmfd ist diese Arbeit getan.

Aktuell weitere Knackpunkte: ipv4 unterbricht beim roaming die laufenden Verbindungen, bis der xlat426-Ansatz implementiert ist. Schaut man sich an, wie viel traffic mittlerweile via ipv6 abgewickelt wird und korreliert das mit dem roaming, kann man wohl für den Moment damit leben.

Die Vorteile sind: Babel skaliert grandios, erlaubt den Einsatz von wireguard und damit im Vergleich zu fastd den 4-fachen Durchsatz und die Softwarekomponenten sind im Vergleich zu Batman klarer in Module unterteilt. Babel lässt sich gut mit Standardwerkzeugen debuggen und die zum Einsatz kommende Netzwerktechnologie ist in jeder Linuxinstallation erprobt und hat damit eine viel höhere Installationszahl als wir das bei batman jemals erreichen werden.

Bei allen berechtigten Sorgen wegen einem neuen Sotwarestack (ja, da werden sich mit Sicherheit noch Dinge einspielen müssen) sind zwei Dinge wichtig:

  • Seit zwei Jahren ist babeld in verschiedenen freifunk-Testnetzen im Einsatz
  • zu der Zeit als batman eingeführt wurde gab es nicht mal annähernd solche Tests wie den auf der letzten Breminale mit babel. Auch keine synthetischen Tests wie sie Dave durchgeführt hat.

Man kann es nicht anders sagen: Wir stehen ziemlich gut da mit babeld.

Jahrelang war das Verhalten in den Batman Netzen von Instabilität, Speicher- und Performanceproblemen geprägt. Vieles ist heute besser. Aber Batman läuft immer noch nicht so stabil wie ich mir das wünschen würde und Batman skaliert weniger als wir das für unsere Freifunknetze benötigen. Man behilft sich mit hoods - aber eigentlich möchte ich als Teil einer dezentralen Community nicht zentral koordinieren müssen welcher Node mit welchem anderen Node in der selben Stadt keinesfalls meshen darf.

7 „Gefällt mir“

Wo gibt es denn aktuelle Quellen? Also wirklich Paper dazu? Bis jetzt habe ich leider nicht wirklich was gefunden. Wenn du da was hast wäre das super.

1 „Gefällt mir“

Auch ganz Interessant zu lesen und aktueller:
https://tools.ietf.org/id/draft-ietf-babel-applicability-03.html

Ob es auf low-memory Geräten aber funktioniert im großen Stil bezweifle ich schon Aufgrund der Routingtable die jedes Node vorhalten muss.

While there exist techniques that allow a Babel speaker to function with a partial routing table (e.g., by learning just a default route or, more generally, performing route aggregation), Babel is designed around the assumption that every router has a full routing table.

Das Paper hier wäre interessant mit dem aktuellen Entwicklungsstand:

Denn genau diese Befürchtung hatte ich schon beim Lesen des Drafts zu Babel:

Our emulation and testbed-based experiments with various network conditions at different scales have provided several detailed results that compare the three protocols. In
summary, we can say that Babel is the most lightweight protocol with the least memory,
CPU, and control-traffic requirements as long as it is used in networks with stable links and
low node densities.
However, if the protocol is used in large or dense wireless deployments with frequent
link changes due to dynamic interference or nodes leaving or joining the network, then its
reactive mechanisms to encounter topology changes by sending additional routing updates
and route request messages turn into massive control-traffic and processing overhead. In
such scenarios, OLSR and BMX6, with their strictly constant rate for sending topology
and routing update messages, outperform Babel in terms of overhead, stability, and even
self-healing capabilities.

Auch wäre da interessant, wie die BATMAN bewertet hätten.

hi

da muss man sich doch dann eigentlich kritisch hinterfragen:

Ist Babel das richtige wenn man Roaming benötigt?

Allein von der OSI-Layer Schichten wird da ja schon wieder allles zerstückelt (so wie Batman-adv auch mit Routing auf L2).
Für mich der richtige Weg (und denn unsere Community auch geht), alle Standorte die kein Roaming benötigen (Niemand benötigt Roaming von einem Ende der Stadt bis in die andere, da ist WLAN sowieso die falsche Technologie dafür) werden per Babel (o.ä. Layer 3 Routingprotokoll wie z.b. OLSR, OSPF oder gar BPG) verbunden und an einen „Aufenthaltsbereich“ wo man Roaming haben will (innerhalb eines Gebäudes, einen Straßenzug entlang, etc.) nutzt man ein ganz kleines Layer 2 Netz (z.b. Batman-adv oder einfach Ethernet und wenn ich per Funk ein Meshnetzwerk aufbauen will, kann man auch WDS oder HWMP/11s verwenden oder oder, das ist jedem Layer 2 Netzbetreiber dann sogar selbst überlassen was er nimmt). Dadurch bleiben Layer 2 Netze klein und übersichtlich, ARP Spoofing o.ä. Probleme in einem Layer 2 Netz betreffen nur den ganz kleinen Teil und der Overhead bleibt geschmeidig klein.

Für mich ist das die Zuku… eigentlich schon aktuell. Ich kann hier nur mal wieder unser RF Netz zeigen:

https://monitoring.freifunk-franken.de/map?mapcenter=49.46522,11.09997,12&source=1&layers=0,0,1,0,0,0,0

Alle blauen Linien sind RF Strecken (mit einer Ausname, da ist es Kabel tlw. Glas, tlw. Kuper) und sind über Babel verbunden. An jeden ende einer blauen Linie steht ein Babelrouter und daran sind dann verschiedene APs mit total verschiedene Technologien angeschlossen:

  • Von mindestens einem Standort weiß ich das WDS verwendet wird
  • Mehrere Standorte verwenden noch Batman-adv (in einer mini kleinen Wolke mit 2-5 Router)
  • An mindestens einen Standort ist auch das Ubiquiti Mesh System im Einsatz
  • andere haben von Mikrotik irgendwas mit denen ihren System aufgebaut (damit kenn ich mich dann gar nicht mehr aus… daher auch nur eine wage Beschreibung)
  • Manche Standorte haben bisschen MischMasch wie es gerade Sinn macht.

Die Idee ist dem Libremesh eigentlich sehr ähnlich: How it works

Babel funktioniert damit bei uns absolut ausgezeichnet und wir sind sehr zufrieden damit, für v6 nutzen wir source specific und können so auch verschiedenste v6 Netze routen (dezentral, mehrere AS Systeme in einem Babelnetz).

Gruß

Christian

1 „Gefällt mir“


awlnx

1min

Sehr cool, danke für die Zusammenfassung :).

Für mich ergibt das auch sehr viel Sinn es so zu machen wie ihr es vorschlagt.

Und große Layer2 Domains sind halt immer ein Problem, egal wie man das Routing löst. Die meisten BATMAN Probleme sind auch eher auf L2 Domains bezogen als ein Problem von BATMAN selbst zumindest mittlerweile.

Die Frage die sich mir dann nur noch stellt, warum dann überhaupt noch Babel? Und nicht OSPF oder IS-IS? Hat es wirklich noch Vorteile, wenn man sowieso ein „bekanntes“ Netz benutzt und nicht viel flapping hat?

Du zählst OSPF und BGP auch auf, wie sind denn da für euch die Erfahrung oder welche Beweggründe habt ihr trotzdem Babel einzusetzen?

Danke!

wir hatten ganz früher (da warens vllt. 10-20 Router und noch gar nix davon in der Stadt sondern nur im RZ Server) OLSR. Damit hatten wir massiv Probleme und haben was neues gesucht:

BGP = zu komplex
OSFP = skaliert nicht so gut weil es irgendwie diesen 0 Baum braucht und man nur davon abzweigen kann (hab von OSPF keine Ahnung aber es klang nicht als könnte man das so schön dezentral und groß machen)
bmx6 = war damals Doku zu schlecht wir habens nicht richtig verstanden
OlsrV2 = Nach der Erfahrung mit OLSR wollten wir es nicht riskieren hier wieder in ein Problem zu rennen.
rest = zu exotisch (z.b. Batman ohne adv ist ja auch Layer 3)

das waren die Gründe die ich noch grob im Kopf habe, ist schon viele Jahre her wo wir das umgestellt haben und seitdem wir Babel nutzen.

Gruß

Christian

2 „Gefällt mir“

Babel eignet sich für die Unterstützung von Roaming gut weil es die Routen schnell im Netz verteilt.
Natürlich kann man die Entscheidung treffen, das nicht zu brauchen und etwas anderes Nutzen.
Mit dem Refactoring, können nun in gluon auch andere Protokolle leichter integriert werden.

Für direkte Vergleiche wäre das durchaus interessant. Freiwillige für die Implementierung vor! :slight_smile: Mir ging es weniger darum babel als die zentrale Antwort auf alles zu plazieren sondern zunächst irgendeine (vielversprechende) Alternative zu batman in gluon zu schaffen. Ob man irgendwann in großen Netzen ein rate-limiting für unscheduled updates einbauen muss und wie man steuert, was ein deutlicher Topologiewechsel ist, muss man auch laut Aussage vom Hauptentwickler von babeld noch einmal ansehen. Bislang kenne ich keine systematischen Untersuchungen von halbwegs aktuellen babel-Versionen dazu. Spannend wäre alles mit babeld 1.9+.

Die Idee mit einem anderen Mechanismus das mesh aufzubauen als mit der Verbindungstechnologie der Wolken ist gut (und nicht mehr ganz jung). Allein, es hat noch niemand in gluon implementiert.

1 „Gefällt mir“

Dann nehmt unsere Firmware, die ist mittlerweile so gut wie fertig (inoffizielle Firmware gibt es schon seit Jahren die sehr gut tut, in den „offiziellen Zweig“ fehlen noch 2-3 Kleinigkeiten) und die kann das, nicht ganz automatisch aber siehe anderer Beitrag das ist weder das Ziel noch der Wunsch.

Gruß

Christian

https://tools.ietf.org/id/draft-ietf-babel-applicability-03.html

Das ist von Oktober 2018 und führt die oben genannten Probleme auf. Und die Probleme ergeben auch Sinn, weswegen ich den Ansatz von @ChrisD schon sehr verlockend finde, ein Protokoll da einzusetzen wo es auch Sinn ergibt. Macht man ja im professionellen Stil nicht anders ;).

1 „Gefällt mir“

Ich habe kein Interesse daran eine Situation wie beim Meshviewer zu schaffen. Lass uns unsere Zeit und Ressourcen bündeln und gluon verbessern, wenn da was fehlt. Es ist durchaus erwünscht, dass Communities sich mit PR an gluon beteiligen.

2 „Gefällt mir“

Keine der von Juliusz in https://tools.ietf.org/id/draft-ietf-babel-applicability-03.html aufgeführten Probleme ist für unseren Anwendungsfall relevant.

  • wir führen (bislang?) keine routen-Aggregation durch. Probleme die durch Aggregation entstehen, haben wir also nicht.
  • Wir wissen, dass die full-table bequem in die Nodes passt
  • die periodic updates sind in unserem Anwendungsfall ein Vorteil. Wir haben große dynamische Netze. Low-Power-Devices spielt (noch?) keine Rolle. Wir haben den gelegentlichen Akku-Mesh-Node, aber das war es auch.

Der Overhead der aber bei unstabilen Links entsteht ist doch nicht verleugnenbar, wenn ich sehe wie oft bei uns Links flappen im Wireless muss das im großen Stil zu hoher CPU Last führen.

Ich zitiere mal Dave, der die tests mit den 50K routen durchgeführt hat: „You run out of bandwidth long before you run out of CPU or Memory“. Als Ergebnis wurden die Updates in babel etwas träger gemacht und die Anforderung an Bandbreite gesenkt.

Am Ende weiß es im Moment noch keiner. Sobald jemand wieder ein Netz mit 1K clients aufbaut und dabei den aktuellen Softwarestack (Stand jünger als Juli 2019) nutzt, werden wir irgendwelche Effekte sehen, etwas lernen und darauf basierend die Protokolle verbessern. Vielleicht lernen wir auch, dass 1K clients nicht mehr reichen um den Stack an die Wand zu fahren. Bis dahin ist das jedenfalls Kaffeesatzleserei.

5 „Gefällt mir“

Ich hab mal ein paar synthetische Tests gemacht. Ein TL-WR841 verträgt bis zu 15K routen. Es werden also bequem Netze bis 5K clients unterstützt.

2 „Gefällt mir“

Wieviele Router hattest du zum Testen? Und wieviel Bewegung im Netz?

ich habe in einer for-schleife 15K routen in die Routingtabelle eingefügt und alle 1000 routen 30 Sekunden gewartet und als client eine Webseite aufgerufen. Bei 16-18K routen (je nachdem ob zram an ist oder nicht) startet das Gerät neu. Man braucht für das Szenario nicht mehr als ein Gerät.

Es gibt noch andere Szenarios, die auch interessant sind bei denen man mehr Geräte benötigt - da ist man dann allerdings in dem Bereich in dem die Links und deren Bandbreite eine Rolle spielt, wodurch man nur noch situationsbedingte Aussagen ableiten kann. Da muss man dann selbst testen.

1 „Gefällt mir“