Wir ( @chrisno ) und ich,
Haben auf einer Test Supernode Babel in Kombination mit Dibbler (für Prefix Delegation) und ISC-DHCP (v4 für die Router NAT) laufen, allerdings mit einem OpenWRT als Basis für die Router.
Wie sieht es denn im gluon aus mit dem Konzept für ipv4 ?
Ja es ist Legacy und es nervt, aber leider brauchen wir es ja noch.
Wir hatten erst mal nur NAT im Test Betrieb, würden aber auch gerne mal 6to4 Proxys (nat64) testen.
Gruß
Über v4 machen wir uns Gedanken sobald v6 rund läuft. Die grobe Idee wäre es den v4 Space in v6 zu mappen (für den Client transparent).
Also ich würde auch gerne dran mitarbeiten. Ich denke ich könnte auch eine VM beisteuern oder zumindest einen Fastd oder Tunneldigger VPN Server.
Ich habe noch etwas Magie in l3roamd eingebaut. Der Daemon kann nun erkennen, dass ein Client eine neue IP verwendet und die entsprechende Route zum Client im Mesh verteilen. Somit müssen nun Clients gar nicht wie bisher geplant erst gesucht werden sondern sind einfach direkt erreichbar (das „Suchen“ bleibt als Fallback jedoch drin). Das spart nochmal ein wenig Traffic ein.
Im Video seht ihr unten den Client, dem ich neue IPs zuweise, und oben die Routingtabelle von babel auf einem anderen Knoten als dem an dem der Client hängt. In der Tabelle tauchen die IPs bereits nach kurzer Zeit auf und der Client wird darüber erreichbar.
https://drive.google.com/file/d/0B3cI8IK0BKaoYzhqSFJUdWJDbmc/view?usp=sharing
Daher trage ich das mal in den Babel-Thread.
Woher die Aussage kommt:
Und auf die Frage „wer das entscheidet“: Es wird wie beim „OLSR vs Batman“ irgendwann eine „Abstimmung mit den Füßen“ werden.
Niemand verbietet die Nutzung von OLSR für Freifunk-Domains. Es ist halt nur irgendwie offensichtlich prozentual nicht mehr so verbreitet wie vor 10 Jahren.
Danke für die ausführliche Antwort.
Mir ist bisher nur von einem Babel-Test in größerem Umfang bekannt und der lief nur wenige Tage, bei der Breminale in Bremen. Aufgrund der Kürze halte ich das nicht für aussagekräftig.
Hast du Links zu weiteren Testbetriebsberichten in relevanter Größenordnung?
Wie definiert und misst man hier „performant“?
was sich mit der Zeit immer mehr erledigt durch bessere Tarife.
Generell bin ich skeptisch, wenn man nur Vor- aber keine Nachteile liest…
aktuell ist meines Wissens das Thema IPv4 z.B. noch nicht endgültig geklärt, oder irre ich?
Der Breminale-Test offenbarte noch einen Flaschenhals, der dafür sorgte, dass die sinnvolle Domaingröße irgendendwo bei 500+ Nodes lag. Dieser wurde rund einen Monat später in der folgenden Firmware behoben.
Vorschläge:
Bei allen diesen Punkten kennen wir inzwischen die Probleme bei Batman-ADV.
Ich glaube natürlich nicht, dass es nicht bei Babel andere/neue Probleme geben wird. Aber zumindest die Papierform und die ersten Rollouts bei Babel sind vielversprechend bei den obigen Punkten.
Metriken habe ich in der Tat keine, gehe aber davon aus, dass vielleicht irgendwer sich dessen annehmen könnte.
Ich habe nur schon häufig beobachten müssen (nicht speziell auf Freifunk bezogen), dass bei etwas neuem nur die Vorteile betrachtet werden und sich oft erst zu spät herausstellt, dass man dafür andere Nachteile hat, zum Beispiel weil man manches schon als selbstverständlich betrachtet hat.
Was mich auch interessieren würde, gegen welche BATMAN Adv Version wird verglichen? IV oder V? Und welcher Release?
So haben gerade die letzten Releases nochmal einiges an Noise (mit BATMAN_V) bei uns in den Domänen verringert.
Mir geht es da wie @rotanid etwas Neues als die Lösung anzusehen fällt mir auf Grund viel Erfahrung ( vor allem im Job ) schwer. Und ich würde auch gerne die Nachteile sehen um eine Entscheidung treffen zu können.
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:
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:
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.
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.
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:
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:
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
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
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! 
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.
