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.

1 Like

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:

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