BATMAN_V — warum?

Fortsetzung der Diskussion von Wie nachtraeglich in Config-Seite von FB 4020?:

(Abgesehen davon, daß es ein Wechsel des »routing_algo« und nicht der Batman-Advanced-Protokollversion ist …) Hmm, warum? Ich weiß nicht, seit wievielen Gluon-Versionen dieser ›known issue‹ existiert, aber für Gluon v2022.1 existiert er noch:

  • The integration of the BATMAN_V routing algorithm is incomplete.
    • Mesh neighbors don’t appear on the status page. (#1726) Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput metric.
    • Throughput values are not correctly acquired for different interface types. (#1728) This affects virtual interface types like bridges and VXLAN.

Welche gravierenden Vorteile bringt mir BATMAN_V, daß es mich die operativen Nachteile vergessen läßt? Insbesondere im Layer-2-Umfeld?

2 Likes

Hi @wusel,

Beides wird umgestellt. Aktuell läuft FFAC mit gluon2019, openwrt2018, BATMAN_IV, COMPAT_VERSION 14, gluon-mesh-vpn-fastd
Zukünftig gluon2022, openwrt2022, BATMAN_V, COMPAT_VERSION 15, gluon-mesh-vpn-wireguard

Das heißt, um vom status quo weg zu kommen gibts breaking-changes.
Also ffho-autoupdater-wifi-fallback rein gepackt, damit hintenliegende Nodes sich im Zweifel ihr update ziehen können falls ihr uplink zuerst updated - und wenn man schon umsteigt, dann direkt komplett und alle Changes auf einmal.

Breaking Changes sind somit COMPAT_VERSION 15, BATMAN_V und wireguard. Was uns dann auch ermöglicht auf gluon2022 umzusteigen.
Zu Wireguard wurde bereits viel diskutiert - es gab auf dem Gebiet bereits kompetenz und man hat eben auch zu FFMUC geschaut gehabt.

Dort gibt es auch Patches für die Statuspage und den wired throughput. Die es nicht upstream schaffen, weil sie dann BATMAN_IV kaputt machen würden - siehe #1726.
Welche Punkte auf der Con-Seite gäbe es denn sonst noch?

Auf der Pro-Seite:
Für mich erscheint die throughput basierte Metrik zukunftsträchtiger für neue Devices - da sind wir eben auch der Argumentation von BATMAN-adv gefolgt.
Zukünftig natürlich die Hoffnung dass man zwischen Mesh-VPN und Mesh-LAN unterscheiden kann nicht automatisch Mesh-VPN nimmt, was wohl noch nicht ganz zu funktionieren scheint

Gravierend ists nicht, aber wenn man schon frisch macht… :slight_smile:

Ich sehe nach wie vor nur Nachteile in der Praxis mit Batman-V. Multi-Uplink-Wolken mit stark unterschiedlich schnellen VPN-Uplinks funktionieren einfach nicht.
Also insbesondere wenn man mehr als Hotspot-Steckdosen-Freifunk macht.
Richtfunk mit symmetrischer Glasfaser und lahmen DSL in der gleichen Wolke: Bandbreiten müssen manuell statisch hinterlegt werden. Oder aber es route nach Murphy über irgendein DSL. Und wenn das Docsis-Kabel mal schlechten Tag hat, wird trotzdem dem DSL50/19 beim Nachbarn vorgezogen, weil ja 1000/50 im gluon hinterlegt.

2 Likes

Mir ging’s eigentlich nur darum zu erfahren, warum man (ließ: ich) vielleicht sich zu BATMAN_V neu verhalten und informieren sollte. Bisheriger Eindruck war ›neuer, nicht zwingend besser‹, und den haben @adorfer und Du mir eher bestätigt.

Ich habe selbst noch mit BATMAN_IV_LEGACY-Netzen zu tun, ziehe aber L2TP der Wireguard-VXLAN-Geschichte als fastd-Ablösung vor. KISS — zudem: zweimal enkapsulieren dürfte nicht schneller sein als einmal, und wenn das Paket unser AS verläßt, tut es das auch unverschlüsselt, warum also für die erste Meile diesen Aufwand treiben? Aber das sind Überlegungen, die jede Community für sich anstellt; daß mit Gluon v2022.1 drei flotte Tunnelverfahren bereitstehen ist sicherlich eher ein Vor- denn ein Nachteil.

Das muß ja in funktional schon in der Vorgängerfirmware drin sein — habt Ihr die Funktion dort überprüft?

Auch offtopic in diesem Thread, aber anyway: wir hatten erst drei Schritte vor (IBSS ⇒ 802.11s, v14 ⇒ v15, fastd ⇒ L2TP), dann aber nur den ersten Schritt vollzogen und erst nach rund einem Jahr den Ball wieder aufgenommen — und dann, mit einer Firmware mit (wieder) funktionalem autoupdater-wifi-fallback-Paket als Ausgang, den Wechsel nach v15 mit L2TP in einem Update vollzogen — vor ziemlich genau zwei Jahren. Diese WiFi-Fallback-Idee ist für sowas echt Gold wert! $woanders bereiten wir das gerade nach dem Muster vor (dort ist man auch schon auf 802.11s), und konsolidieren von 5+ FW-Builds (andere SSIDs, gleiches Mesh) auf eine Multidomain-FW (andere SSIDs, getrennte Meshes). Problem bereitet nur gluon-respondd: Neu installierte Knoten können mit dem Bestands-Yanic sprechen (mit dem bekannten Patch), aber aktualisierte Knoten melden sich nicht mehr zurück. Kurzum: je mehr Änderungen auf einmal, desto mehr ›Spaß‹, schon deshalb würde ich nicht gleichzeitig auch noch auf BATMAN_V gehen. Von fastd gen in-kernel-Tunnel bringt einen Durchsatzzuwachs. V15 den Zugang zu Gluon ab v2020. Aber wir wirkt sich BATMAN_V im Gesamtnetz und in gezielt gebauten Teilnetzen aus? Wenn die Rückmeldung kommt, es sei »gefühlt schlechter als vorher«, welche Änderung war es? Aber das muß jeder selber wissen :wink:

AFAICS hat sich bzgl. BATMAN_V nichts grundegend getan — es ist vorhanden für Experimentierfreudige, die stabilitätsliebenden, konservativen alten Säcke wie ich bleiben bei BATMAN_IV :grin:

2 Likes

Batman_V kann Traffic anhand der verfügbaren Bandbreiten optimieren.
Besser: Es könnte es. Nur hat es diese Informationen bei Gluon nur für die Wifimesh-Links.

Batman_V fehlt -wenn ich es richtig verstanden habe- die Informationen für MeshVPN und für Lan-Mesh, und damit auch für Richtfunk-Strecken.
d.h. Batman_V ist in Gluon leider blind für wechselnde Bandbreiten dort, wo sie besonders wichtig sind: in Richtung Supernodes.
Damit ist es ein Rückschritt gegenüber Batman_IV, sofern man nicht „Freifunk ohne Supernodes, ohne VPN, und ohne Richtunkstrecken“ baut.
Oder sowieso nie irgendwas mit „Wolken mit mehreren Uplinks“ baut.

Oder anders formuliert: Mag mir von (evtl. von denjenigen, die bereits auf Batman_V umgestellt haben) jemand ein (halbwegs realistisches) Szenario aufzeigen, in dem sich das besser verhält als Batman_IV?

(Ich hoffe schlicht, dass nicht nur gewechselt wurde „weil Versionsnummer höher“ und ich nur etwas übersehe.)

1 Like

Nur kurz der Hinweis, dass WireGuard kein Breaking-Change ist, wenn ihr es nicht unbedingt drauf anlegt.
Ich habe letzten Sommer ein Tool geschrieben, mit dem sich die fastd-Schlüssel in ihre WireGuard Pendants umrechnen lassen.

Wir haben in Hannover etwas über 3K Schlüssel umgerechnet und fahren seither einen Parallelbetrieb, um abzuschätzen, wie sehr uns die plötzlich wesentlich performanteren und damit Server-belastenden Router beuteln :slight_smile:

Das hier ist das Tool:

Und das hier die beiden Patches für die Gluon-Seite:

Letztere werden irgendwann upstream gehen (gluon#2601), allerdings wünscht sich NeoRaider noch, dass die Patches generischer werden.
Die Patches funktionieren prima und werden zu dem kompatibel sein, was später in gluon landet.

1 Like

Was hat Wireguard denn für eine Abhängigkeit von Batman_V? Oder warum schreibst Du das in diesem Thread?

1 Like

Die beiden haben keinerlei Abhängigkeit zueinander.

@fmaurer zählte sie in einer gleichwertenden Liste auf, mit einer nachgehenden Schlussfolgerung über Breaking-Changes.
Ich wollte (wenn auch nicht für fmaurer, wenigstens aber für Mitlesende) klarstellen, dass diese ihrerseits nicht mit WireGuard in Verbindung stehen, sondern allein vom wechselnden batman Ansatz herrühren.

Dass die Umstellung auf WireGuard schwierig oder gar breaking sei, ist ein hartnäckiger Irrglaube, der mir im letzten halben Jahr mehrmals zugetragen wurde.

Ich verstehe die Begründung für den Wechsel zu Batman_V dann nicht?
Wechsel, um das „Breaking change“ zu maximieren? Hat das einen Vorteil „an sich“?

Wenn Batman_V sonst kein Problem löst und auch nicht besser performed, zur Vergrößerung von BreakingChanges auch das Routingprotokoll wechseln, verstehe ich das richtig?

1 Like

Was da deren Beweggründe sind, kann fmaurer sicherlich besser schildern; wie du auch hoffe ich dass ihnen klar ist, dass das kein Update sondern ein Wechsel des batman Ansatzes ist.

Generell kann man festhalten, dass B.A.T.M.A.N. IV mit der Einführung der TQ deutlich besser mit (im WLAN Umfeld üblichen) unsymmetrischen Verbindungen klarkommt, also wenn die eine Station die andere besser verstehen kann, als umgkehrt.
Das war ein Upgrade gegenüber dem Vorgängänger III.

Gleich ist bis dahin, dass die Protokolle Pakeloss nutzten um sich ein Bild vom Zustand des Netzes zu machen. Das ist ein konzeptionelles Problem bei immer größer werdenden Netzen, die im Prinzip überwiegend stabile Verbindungen haben, solange man sie nicht belastet.
Überlastet man eine Verbindung, ist folgender Packetloss unausweichlich.
Den Zusammenhang kennt die bestehende Metrik nicht und hat auch auch keinen Weg festzustellen, wann eine Verbindung am Limit wäre.

Genau da würde B.A.T.M.A.N. V gerne ansetzen und führt Datendurchsatz basierte Metriken ein.
Die Verbindung wird daran gemessen, was man auf ihr an Traffic fahren kann.
Dazu braucht es allerdings Unterstützung vom drunter liegnden Layer; irgendwer muss batman sagen, was da an Datenverkehr stattfindet. So kann man bei LAN-Verbindungen gut abschätzen, ob es sich um eine 100Mbit oder eine Gigabit Strecke handelt und auch WLAN Treiber exponieren immer häufiger brauchbare Kennzahlen über den aktuellen und aktuell möglichen Durchsatz.
Kann man abschätzen, dass beide Varianten nicht zuverlässig funktionieren werden oder man selber detailliertere Werte kennt, kann man auch einen Override nutzen um die Werte selber festzulegen.

Das bis dahin.
Kurzgesagt ist V wenigstens theoretisch in der Lage mit Abschätzungen über das Netz besonders in störungsarmen Netzwerken richtig zu liegen, als es IV konzeptionell möglich ist.

In der Praxis hast du aber richtig erkannt und ich glaube auch weiter oben festgehalten, dass die Integration von B.A.T.M.A.N. V in Gluon noch immer eine offene Baustelle ist (auf der sich schon relativ lange wenig tut).

Möglich ist, dass das Interesse in der Community größer wäre, wenn die Integration abgeschlossen wäre.
Auch möglich, dass die Performance in den Netzen dann besonders in stabilen und oder viel genutzten Segmenten deutlich besser belastbar ist, weil die Metrik nicht im Blindflug austestet, wie viel (mehr) Datenverkehr man dem zugrundeliegenden Band gerade zumuten kann.

Und so ziehe ich meinen Hut vor Communities, die sich auf die Fahne geschrieben haben, V zu nutzen und die Integration vorranzutreiben.
Letztendlich werden wir da alle dran gewinnen.

Letztes Ding was ich irgendwann gelernt habe:
Während IV und V auf der Mesh-Ebene inkompatibel zueinander sind, kann man sie trotzdem Zeitgleich auf einem Gerät (Server) betreiben.
So könnte man für einen Stadtteil während der Migration je ein IVer und ein Ver Interface betreiben, auf das sich Knoten verbinden können und die beiden dann auf dem Server zusammen routen oder bridgen lassen.
Ein Breaking Change ist also auch da nicht notwendig, wenn man sich ein bisschen Mühe macht.

@adorfer gerade nochmal durchgelesen und beim ersten mal übersehen;
fmaurer hat alle drei explizit als Breaking identifiziert. Ich glaube damit ist der Einschub über WireGuard oben gerechtfertigt, auch wenn er nichts mit batman zu tun hat.
Trotzdem sorry, wenn er dich im Topic störte, wollte das nur klarstellen.

Breaking Changes sind somit COMPAT_VERSION 15, BATMAN_V und wireguard.

Nunja, schon der erste Beitrag von @fmaurer hier im Thread derailte — jene Erklärung hätte besser als Antwort auf den Beitrag von @Djfe stattgefunden. (Thema dieses Threads ist die erstgemeinte Frage, warum man BATMAN_V einsetzen wollen sollte — nicht, daß oder warum FFAC noch immer auf AdHoc sitzt und einem 2014er Batman.)

Dein Beitrag #10 ist allerdings genau das, was ich gefragt habe, danke. Wenngleich Deine Antwort mir noch unverständlicher macht, warum man heute generell auf BATMAN_V setzen würde. Für Testmeshes unter nahezu Laborbedingungen, sure, why not — aber generell, in einem unkontrollierbaren, echten Mesh wohl wohl eher (noch) nicht, aber YMMV.

Anyway, @moderatoren, hier kann zu.

Zumindest bei uns sind alle Meshlinks, die wirklich trafficrelevant sind immer entweder „echtes Kabel“ oder Richtfunkstrecken mit Stockfirmware (UBNT, Mikrotik). Und an dessen Metriken kommt der BatmanV in Gluon (derzeit?) nicht heran. Das ist immer „Linkspeed eth zum Vlan-Switch“.
Und auch bei Meshes mit mehreren VPN-Uplinks: Die VPN-Speed „hinterm DSL-Router“ erfährt der BatmanV nicht.

Batman IV hatte tendenziell flappende Routen, bei Last.
Batman V hat dumme (statische) Routen, weil bei Performance-Einbruch (DSL, Richtfunkwetter) die Routen statisch bleiben, bei den Links bei denen es drauf ankäme, deren Bandbreite zu wissen (Richtfunk, VPN)
Für mich also so ein „Das ist dann ‚Mesh wie bei UBNT‘, wenn der nur noch nach Hopcount routet“.

Vielleicht kommt ja mal irgendwann in Gluon da was, was auch die Performance von solchen Lan/VPN-.Links ermittelt und dem BatmanV mitteilt. Aber bis dahin bleibe ich lieber bei BatmanIV, das ist schlicht intelligenter.