BATMAN_V — warum?

Technik
1

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
2

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:

3

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
4

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
5

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
6

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
7

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

1 Like
8

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.

1 Like
9

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
10

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.

11

@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.

12

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.

13

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.

14

Prinzipiell gab es von uns drei Motivationsgründe für BATMAN V:

  1. Durchsatz- vs. Packetverlust-Metrik

Mit zunehmenden WLAN Geschwindigkeiten, wird es immer schwieriger anhand von Packetloss eine sinnvolle Entscheidung zu treffen. I.d.R. stellen wir ja eine fixe WLAN multicast Rate von 12, 18 oder 24Mbit/s ein. Sobald ein Link aber dann über dem Wert ist, hat man (meistens) auch wenig Packetverlust. Und es wird für BATMAN IV dann schwierig zu entscheiden, ob es z.B. die Route mit 50Mbit/s oder die mit 150MBit/s nehmen soll. Auch bei den Tests beim Battlemesh v8 zeigte OLSRv2, welches als erstes eine Durchsatz-Metrik von den gängigen Protokollen implementierte, eindrucksvoll, dass dieser Ansatz sehr großes Potential hat. In Durchsatztests schnitt OLSRv2 dort am besten ab.

Eigentlich, theoretisch, wäre dies auch gerade für 60GHz Gigabit-WLAN praktisch, damit batman-adv solch einem performanten WLAN-Backbone mehr Beachtung schenkt.

Aber wie schon im Thread erwähnt, gibt es dort dann noch zur Zeit das Problem, dass dort BATMAN V von den 60GHz Geräten noch nicht die Bandbreite mitgeteilt bekommt.

Was hier helfen würde: a) Mehr 60GHz Geräte auf OpenWrt portieren und sicherstellen, dass deren WLAN-Treiber ein „expected throughput“ reporten. b) Eigentlich war die ursprüngliche Idee, dass auch BATMAN V, wenn es keine sinnvollen Werte geliefert bekommt, dann selber mit selbst generiertem Traffic misst. Eine abgespeckte TCP Variante ist dafür auch im BATMAN V implementiert und kann mit „batctl throughputmeter“ benutzt werden. Jedoch fehlt dafür noch der Automatismus, dieses Feature selbstständig allein im Kernel zu benutzen, ua. weil es etwas schwierig abzuschätzen ist, wie oft zu welchen Nachbarknoten man messen soll. Denn man will ja auch nicht alles an nutzbarer Bandbreite nur für’s Messen verschenken. Gerne kann aber mit dem batman-adv „throughputmeter“ im user-space herumgespielt werden. Wenn jemand eine gute User-space Implementierung dafür dann finden sollte, würde uns das schon sehr helfen und wir könnten es dann vll. auch in den Kernel übernehmen.

  1. OGM ↔ ELP Split

Mit BATMAN V sollten auch die Aufgaben für OGM Pakete weiter aufgeteilt werden. Insbesondere in frühen Zeiten von BATMAN IV wurden diese zum Verteilen aller möglichen Informationen benutzt. Unabhängig davon, wie dringend deren Verteilung/Updates waren. Ursprüngliche Idee: OGMs zum Beispiel nur noch alle 15s durch’s Mesh fluten, während ein neuer Pakettyp, „ELP“ (Echo Location Protocol) Pakete dann z.B. jede Sekunde nachbarn anpingt, um die Packetloss Rate zu ermitteln. Auch wenn Packetloss-Metrik am Ende doch durch Throughput-Metrik ersetzt wurde, hat ELP Einzug gefunden. Um z.B. „später“ einen reaktiven Routen-Update-Mechanismus wie bei Babel zu implementieren: RIP - batman-adv - Open Mesh. Leider bisher nicht über dieses Konzept hinaus gekommen.

Trotzdem hat die Aufteilung von OGM und ELP auch schon ein paar kleine, einfache Overhead Reduktionsmechanismes ermöglicht: In bestimmten Fällen, wo ELP vorher die Nachbar-Knoten auf einem Link detektiert hat, werden OGM rebroadcasts vermieden:

https://git.open-mesh.org/batman-adv.git/commit/a00797d8fa8fd147
Bei BATMAN IV kann/wird dieser Mechanismus nur für die verkapselteten, per „classic flooding“ verteilten Broadcast Ethernet Frames benutzt, nicht aber für OGMs. In BATMAN V wird es für beides benutzt.

  1. Aufgeräumter Code

Der Routing-Code von BATMAN IV ist über die Jahre in batman-adv sehr gewachsen und etwas schwer erweiterbar geworden. Der BATMAN V Code ist viel, viel übersichtlicher und aufgeräumter, insbesondere weil wir ihn erst auf Papier und im Wiki genau spezifiert haben. Und dann daran BATMAN V sauber heruntergecoded wurde. Dadurch sollte, zusammen mit 2) BATMAN V theoretisch in Zukunft besser erweiterbar sein als BATMAN IV.

Leider hat der ganze BATMAN V Umbau aber auch eine Menge Energie gekostet. Was vll. auch ein Grund war, warum dann obwohl anfangs eine Menge toller Ideen da waren, was man auf BATMAN V dann alles aufbauen könnte, dann als BATMAN V dann fertig war, die Energie/Motivation/Zeit fehlte, diese spannenden, weiterführenden Ideen noch umzusetzen.

3 Likes
15

Gibt es denn einen Weg, bei BatmanV den (hardware-Links) ihre geschwindigkeit irgendwie statisch (per CommandLine-Magie) mitzuteilen?
Wir haben hier leider Mesh-Wolken mit mehreren stark unterschiedlichen schnellen Uplinks (DSL vs. Glas, ohne Packetloss/mit DSlite-verursachtem Packetlos).
Ohne die Kenntnis der Uplink-Speed würden bei Batman-V unsinnige Routing-Entscheidungen getroffen.

16

München macht es generisch, einmal alles wired auf 1gbit/s
Keine Ahnung, wann post-setup.d ausgeführt wird, ob nach jedem Betreten des Config Modes?

Also auf jedenfall sollte es sich so lösen lassen (nur wenn man die Münchener Patches unverändert nutzt, kann es passieren, dass die Werte irgendwann wieder auf 1gbit/s resettet werden):

batctl hardif $IFNAME throughput_override 1000mbit;

Statt $IFNAME muss man da irgendeins der interfaces verwenden, schätze eins mit mesh im Namen, aber genau weiß ich es leider nicht.

1 Like