Quo vadis, Gluon? (batman/Babel/BMX/…)

Fortsetzung der Diskussion von Erfahrungen mit Babel:

Hmm; gefühlt ist IPv6 nach wie vor das Nischenprotokoll, wenn etwas funktionieren muß, ist es IPv4.

Naja, wenn das die normale Linux-Routingtabelle ist und wir von einem Freifunk-Mesh reden, wie groß ist dann die „full routing table“? Bei 2k Clients erwarte ich etwas mehr als 2000 Routen, Platzbedarf ist dem Vernehmen nach linear, dann sollten 2k Routen ca. 0,256 MB verbrauchen (basierend auf [1] brauchen 2 Millionen Routen 256 MB RAM). Bei vier Alternativwegen (VPN, 3 Peers per WLAN) also vielleicht 1 MB.

Arbeitet eigentlich auch jemand an einer BMX6/BMX7-Integration in Gluon? libremesh.org setzt BMX ja für die Einzelknoten ein und Batman nur für Gegenden, wo Roaming auch stattfinden könnte/sollte (ein solches Setup setzt aber, anders als Gluon, Planung/Koordination beim Netzaufbau voraus).

Generell die Frage doch eher, was man will: Plug-n-Play-Netzerweiterung, dann bleibt nur ein L2-Gewurschtel wie mit Batman oder L3-Gewurschtel mit Babel/BMX. Jeder kann sich einen Knoten flashen, ins Netz hängen, tut. Nachteil: die Koordination wird „ins Netz“ verlagert, IP-Vergabe (v4 und v6) erfolgt eher zentral. Vorteil: funktioniert (im Rahmen vorzugsweise nur zweistelliger Knotenzahlen) einfach, solange die Gateways tun.

Oder, @ChrisD hat es angesprochen, man plant den Netzausbau, dann muß ein Knotenaufsteller zumindest minimale Informationen haben, wie er den konfigurieren soll. Allerdings: da kommen Gluon/batman-Communities sowieso hin, wenn sie „das Netz“ in „Hoods“, „Domänen“, sprich: kleinere Meshes, splitten. Siehe Multidomain-Ansatz in v2018.x: der Aufsteller muß die „korrekte“ Konfiguration auswählen. Aber: das wiederum könnte teilautomatisiert werden, indem ein Defaultmesh betrieben wird und nach Erstinstallation der Knoten im Netz nach seiner Konfiguration fragt (z. B. auf Basis Geolokation per WLAN oder bei der Erstinstallation abgefragter Koordinaten) — auch derlei Ansätze gibt es AFAIK schon.

Ich finde den Ansatz in den meisten Gluon-Netzen, daß man einen Knoten einfach aufstellen kann, deutlich angenehmer als den z. B. der Berliner Firmware, daß man sich erst Konfigurationsdaten holen muß, bevor man den Knoten konfigurieren kann. (Stand 2016, Dinge mögen sich geändert haben?)

[1] IPv4 route lookup on Linux | Vincent Bernat

1 Like

Ich greif das mal auf um das Grundproblem an aktuellen Gluon Communitys zu erklären:

Es gibt eine hand voll Admins die die Gateways verwalten und ganz viele Knotenaufsteller. Die Admins finden keine weitere Hilfe (oder tlw wollen sie es nicht mal!) weil das ganze Netz so ein gefrickel ist das ein normaler Netzwerkadmin gar keine Lust darauf hat. Also werden es immer mehr Knotenaufsteller immer weniger Admins und das Netz „zerbricht“. Es gibt durchaus Netzwerkadmins die vllt. Bock auf Freifunk haben aber nicht auf Layer 2 Routing und ein Layer 2 Netz in einer ganzen Stadt, da stellen sich jeden Netzwerkadmins die Haare auf.

Seitdem wir nun die Möglichkeit bieten das Netze dezentral und eigenständig nach eigenen Wünschen aufgebaut werden sprudelt es hier nur so von Ideen. Der eine nutzt auf einmal Network Namespaces, der nächste setzt eine Proxmox VM auf, wieder ein anderer hat ne richtig coole Firmware entwickelt (die sogar schon wieder geforkt wurde und nun in 2 verschiedenen Zweigen vorhanden ist!) um Babel auch einfach (jeder der SSH und vi bedienen kann bringt das hin) einrichten kann. Der nächste hat auf einmal HWMP für sich entdeckt, wieder andere bauen Batman-adv in ganz kleine (2-5 Knoten bis 30 Clients oder so) Domänen. Es gibt auch sehr viele Leute die nun auf einmal interesse zeigen und mit ein Netz „bauen“ und nicht nur Knoten aufstellen. Natürlich gibt es zweiteres auch noch bei uns, daher fahren wir das ganze auch zweigleisig. Es gibt bei uns das „zentrale“ System wo eine Hand voll Leute Zugriff auf das Backend haben wie es bei Gluon auch der Fall ist aber selbst hier sind es bestimmt 10 wenn nicht mehr Leute die Gateways betreiben für sich und nicht zentral von paar wenigen Leuten. Dazu eben das oben beschriebene dezentrale System wo man dann eben bisschen was konfigurieren muss, sei es nur diese sog. Gatewayfirmware (Sprich ein Babelrouter mit OpenWRT in der Stadt, der Name hat sich bei uns halt so eingebürgert man muss hier nur per SSH eine Konfigurationsdatei bearbeiten wie IP Adressen und wireguard Tunnel Endpunkte) oder es setzt eben jemand als VM oder als Debianserver auf, ja sogar ein händisch eingerichtetes RasPi als Babelrouter fällt mir gerade ein gibt es schon. Andere nutzen Babel sogar unter Bird und nicht mit babeld. Es gibt wirklich die verschiedensten Wege die sich aktuell auftun.
Ich bin der Meinung das ist das allerwichtigste das Leute die freie Entfaltung gibt, solang sich ans PPA gehalten wird und das Netz nicht gestört wird darf und kann jeder aufbauen was er will. Solang nur ein „Flashe den Router und du bist im Freifunk“ verkauft wird, wird sich dieses oben beschrieben grundlegende Problem niemals bessern. Es werden immer mehr „dumme Knotenaufsteller“ und immer weniger Admins weil niemand Bock auf dieses (Achtung jetzt kommt es zum Abschluss!) kommunistischen Frickelnetze hat.

Gruß

Christian

2 Likes

The amount of state stored by a Babel router is at worst one routing table entry for each destination through each neighbour. In the source-specific implementation, one routing entry occupies roughly 100 bytes of memory. To put these figures into perspective, in a network with 1000 nodes, a Babel router with 10 neighbours needs roughly a megabyte of memory to store its routing table (not counting malloc overhead).

http://www.watersprings.org/pub/id/draft-mrw-homenet-rtg-comparison-02.html#rfc.section.13

Ein paar Ergänzungen von meiner Seite, damit wir alle auf den gleichen Stand kommen:

  • Bei Babelnetzen braucht man je node 2 Routen und je client ca 2.5
  • Die IP-Vergabe erfolgt in Babel-Netzen am Node, also dezentral
  • Es wird von babel gesteuert, welcher Pfad in die Routingtabelle eingetragen wird.
  • In Frankfurt kann man sehen, dass je nach Tag für die Statistik der IPv6-traffic >50% des Volumens ausmacht. Klar muss ipv4 funktionieren. Aber wenn es nur in einem Randfall kaputt geht (War batman nicht im Bezug auf roaming mehrere Monate für ipv6 und ipv4 kaputt ohne dass es bemerkt wurde?), dann ist das schon einsetzbar. Wir lassen bitte die Kirche im Dorf :slight_smile:
1 Like

Reden wir von Traffic Richtung Internet exklusive der Nodeverbindungen? Oder mit fastd/l2tp je nachdem ergibt das einen sehr großen Unterschied.

Immer wenn jemand sagt „Wir machen Batman in den lokalen Wolken und in der Anbindung dann BMX/Babel/GRE/BGP/you-name-it“:
Das mag in Communities funktionieren in denen

  • entweder (so ziemlich alles) zentral administriert wird
  • es in jeder lokalen Wolke dauerhaft(!) immer mindestens eine Adminperson gibt, die Strukturänderungen nachpflegt „anderswo im Netz“

Will sagen: Der Durchbruch für Gluon-Batman im Freifunk war der Zeroconf-Ansatz: Einmal ausgerollt läuft das irgendwie, selbst über Releasewechsel hinweg. Egal ob mit oder ohne Autoupdater, man kann das Netz umbauen ohne in der bestehenden VPN-Infrastruktur configchanges ausrollen zu müssen.

Hi

bei uns wird nichts zentral administriert und Punkt 2 sollte einfach selbstverständlich sein. Wir sagen seit Anfang an, einfach nur Router aufstellen ist NICHT(!!) Freifunk das ist einfach nur HotSpot deployn und das wollen wir nicht. Es gibt Leute die tun das, die können das auch im zentralen kommunstischen Frickelfunk tun aber wer #echtesfreifunk machen will, muss sich um seinen Kram kümmern, nach PPA als Ansprechperson verfügbar sein (wobei hier der Zeitrahmen sehr offen ist, wenn jemand 4 Wochen im Urlaub ist oder 8 Wochen lang für Klausur lernt ist das vollkommen ok, Privatleben geht eindeutig vor!)und bei Probleme eingreifen ansonsten wird halt das Peering zugemacht und diese Person ist wieder offline. Es geht ja nicht darum 1000000 Hotspots in die Gegend zu werfen sondern Leute sollen ihr Netz pflegen und wenn man dann jemand verliert, mein Gott dann ist das halt so.
Also lasst Leute ihr Netz bauen, helft denen (Bildung, verdammt ihr seid alle Bildungsvereine!) und baut gemeinsam ein geiles Netz. Das es geht beweist Freifunk Franken indem es genau das schon gibt was ich heute den ganzen Tag schon predige.

Gruß
Christian

Richtung internet. Ich klär mal ob wir einen Graphen haben, den man teilen kann.

Denn mit den Nodes ist das klar, da die meisten vermutlich bei der DTAG oder so sind … und damit per IPv6 verbunden. Das heißt du siehst auch IPv4 Traffic der Clients nachher als v6 Traffic und prozentual immer mehr v6 Traffic ;).

Wie es „den“ Freifunk nicht gibt, gibt es auch nicht „die aktuellen Gluon-Communities“.

Es war ein Geburtsfehler mancher Communities, – überspitzt – Knoten per Drückerkolonne ins Feld gestellt zu haben, das funktioniert in der Regel eher schlecht — das dürften viele 3 bis 5 Jahre später unterschreiben.

Ob „das ganze Netz so ein gefrickel ist das ein normaler Netzwerkadmin gar keine Lust darauf hat“, sei mal dahingestellt; daß „normale Netzwerker“ beim Thema „kreisweites L2-Netz“ schon von der Vorstellung graue Haare bekommen, erscheint mir nicht unwahrscheinlich. Mit Recht, im Grunde. Ganz so schlimmt ist es meistens nicht, aber ja, collision domains hält man prinzipiell so klein wie möglich …

batman v15 war bzgl. Roaming zeitweise borked; feststellen konnten dies nur Communities, die „schon“ auf v15 waren, was aufgrund der als Feature gepflegten Inkompatibilität vor v15 und dem daraus resultierenden Aufwand längst nicht alle Gluon-Communities waren — oder sind.

Also Kirche, Dorf — oder eher FUD? Dieser Einwand war eher letzteres. Ich hätte ja gehofft, Babel hätte von sich aus Vorteile, ohne daß seine Protagonisten auf temporären Bugs alternativer Protokolle rumreiten müßten; schade, dem ist offensichtlich nicht so.

Second that; als Aufsteller macht Gluon mir die Sache einfach (wie gesagt, „Hoods“/„Domänen“, sprich getrennte Meshes, machen das ein Stück weit wieder komplexer), als „Netzdiktator“ im Hintergund ebenso.

Daß ich „#echtesfreifunk“ so nicht stehen lassen kann, dürfte klar sein. Falls Ihr tatsächlich einzig Euren fränkischen Ansatz als „echt“ anseht, hat sich der Boden für eine Diskussion in ein Logikwölckchen aufgelöst.

Auch aus „8 Wochen lang für Klausur lernt“ ergibt sich schon eine komplett andere Zielgruppe; in dieser Neugroßstadt hier gibt es keine nennenwerte Studentenzahl oder einen Hack(er)space. Einen Makerspace gibt es mittlerweile, aber gefühlt sind auch dort die U27 eher unterrepräsentiert.
Wenn wir also die Ü40 ansprechen, mag da der eine oder andere dabei sein, der mitfrickeln möchte; das Gros stellt sich einen Freifunk-Knoten auf’s Fensterbrett für’s gute Gefühl („digitales Glas Wasser“), aber nur, wenn er/sie (da noch selten: divers) sonst keinen Aufwand mit dem Ding hat.

Noch so eine unzulässige Verallgemeinerung — glaub’ es, ober glaub’ es nicht, nicht alles da draußen, was Freifunk macht, ist in einem (eingetragenen) Verein organisiert.

Hmm. Wie könnten entsprechende Graphen bei Freifunk nicht öffentlich teilbar sein?

… außer bei L2TP, denn tunneldigger buddelt nur IPv4-Tunnel.

Wir sehen aber leider auch das Problem der „Spezial-Briegel-Wolken“ in denen ein engagierter Einzelkämpfer irgendwas total geniales gebaut hat… vor ein paar Jahren.
Aber dann ist er Job nach $SONSTWO gefolgt und nun sitzt da ein Wohn-Projekt mit einer GRE-Anbindung auf einen WG-Schrankserver, den keiner versteht, mangels Doku kommt man auch nicht dahinter. Aber irgendwie läuft’s ja noch, meistens.
Aber um alles neu aufzusetzen müsste man durch x Wohnungen in der Nachbarschaft, wo man von y% noch nichtmal weiss, wo die exakt sind oder wer da helfen kann… Bei einem Infrastrukturänderung würde man also z mal eine faktisch kaum nutzbare „Freifunk“-SSID in der Nachbarschaft herumstrahlen lassen.

Wer? Ich nicht, vielleicht mit Ausnahme von W, aber … nee.

Der Begriff ist mir neu. Das Einzelkämpfer-baut-Lösung weniger, aber …

… wird zur Schutzbehauptung von jedem vor allem.

root@l2tp-ham01 ~ # ip route show table 42 | grep default
default via 193.26.120.113 dev ens3 proto bird 

Welche „Doku“ fehlt Dir hier? Was verstehst Du nicht? Aus welchem Level ist anzusetzen, „bash Grundkurs“? Das hat zwar alles nichts mit dem Thema zu tun (lies: Du hättest gerne „+ Neues Thema“ nutzen dürfen), aber, wie es ein Kollege so nett formuliert: „for fuck’s sake …“ :wink:

Einbruch in fremde Systeme ist immer blöd, auch wenn es „zum Besten der Betroffenen“ ist, oder die einem sogar physikalischen Zugriff geben.
Hint: Verschollener Ex-Admin hat natürlich nicht überall offene Telnet-Ports hinterlassen. Und wenn dann Plasteroute mit seiner Firmware zufällig meshen und dann Telekom-Prefixe announcen im ganzen Netz und darüber auch Exit machen, dann ist das irgendwie blöd. Wir konnten uns zumindest vor 3 Jahren nicht vorstellen, dass das „absichtlich“ (also ein gewolltes Szenario) gewesen ist.

Das Problem wurde dann darüber gelöst, die Router zu jagen und wieder eine standard-Gluon-Firmware draufzutun, die im Autoupdater läuft und (deren Config auch nachvollziehbar bekannt gegeben wird, dort wo es die Firmware gibt.)

Zugangsdaten zählen doch nicht zu „Doku“, das ist ein vollkommen anderer Themenkreis.

O.k. Du hast Recht. Ich habe „Zugangsdaten“ fälscherlicherweise als (Teil der) „Doku“ bezeichnet.
Daher ist mein Punkt „warum individuell mit SpezialFirmware aufgesetzte Wolken ebenfalls nach ein paar Jahren schlimme Probleme bereiten können“ vermutlich wirklich nicht valide.

Hat es. Wenn Du die Entwicklung und Motivation verfolgt hast, kennst Du die auch. Falls Du sie nicht kennst, bist Du herzlich eingeladen die bestehende Dokumentation zu konsumieren anstatt rumzupöbeln. Falls du die nicht findest hilft Dir die Forensuche sicher weiter.

Ich sage: Bei Batman lief das einige Zeit nicht ohne dass es ein Problem war, also kann es für die Babel-Welt schonmal kein größeres Problem sein, wenn weniger als die Hälfte des traffics devon betroffen ist. Das hat nichts mit Fear / Uncertainty / Doubt zu tun.

Noch ein Nachtrag: Das ist auch kein schlechtreden von anderen Protokollen oder gar der Arbeit anderer. Ziel war und ist die Einordnung des Schweregrads des Problems. Die Tatsache, dass ich derjenige war der das Problem überhaupt angesprochen hat, sollte dabei ein Hinweis sein dass es mir nicht darum geht, die babelwelt zu beschönigen.