batmanV: reduzierter broadcast traffic und durchsatz basierte routenwahl


#1

vor kurzem wurde nach 5 jähriger entwicklung die neue protokol version von b.a.t.m.a.n. released

unterschiede batmanIV / batmanV
https://www.open-mesh.org/projects/batman-adv/wiki/BATMAN_V

broadcast vergleich

routing vergleich
https://www.open-mesh.org/projects/batman-adv/wiki/BATMAN_V_Tests


#2

Die Seite zu den Tests wurde scheinbar umbenannt:

https://www.open-mesh.org/projects/batman-adv/wiki/BATMAN_V_Tests


#3

copy paste fehler
danke


#4

Gibt es hier inzwischen Erfahrungen mit Gluon und BATMAN_V?

Man kann ja seit 2017 da neue Protokoll aktivieren mit

  routing_algo = 'BATMAN_V'

#5

I’m Chemnitz in Der domain “Umland” wird dies benutzt:

Was passiert bei gw_sel_class=1500 ?

Ist hier jemand aus Chemnitz, der Mal berichten könnte? @nemesis ?


#6

Anscheinend ist die Berechnung bei B.A.T.M.A.N. V in kbit anstatt TX.


#7

Hallo zusammen, da wir in Chemnitz anscheinend wirklich die einzigen sind, die BATMAN_V benutzen hier die gewünschten Infos.

Die Metrik ist wie schon bemerkt nun der Durchsatz und die selection class wird als kBit/s interpretiert. An sich ist die Metrik sehr gut um schnellere Anschlüsse dem weniger an Paketverlust vorzuziehen. Im Gluon Umfeld gab es allerdings ein paar Probleme.

  1. die VPN Verbindungen haben keine Geschwindigkeit, die Batman sofort für die Routingenscheidung heranziehen könnte, sie muss manuell gesetzt werden oder wird viel zu niedrig angenommen.
  2. Nur der ath9k Treiber liefert mit “expected throughput” einen Wert den Batman auch nutzen kann. Bei ath10k oder mt76 sind keine nutzbaren Werte Verfügbar.
  3. Unter Last ändert sich der “expected throughput” einer WLAN Strecke relativ schnell und oft. Das führt zu routen die sich mehrmals pro Sekunde ändern können und dann zu Paketverlusten führen.

Zusammenfassend werden wir in unserem Umland Netz aber an BATMAN_V festhalten, da sonst niemand ein größeres Mesh damit betreibt und wichtige Erkenntnisse zur Weiterentwicklung ausbleiben würden. Wir stehen auch in engem Kontakt mit den BATMAN Entwicklern um das Verhalten zu verbessern. Die Funktion zur Messung des Durchsatzes, die BATMAN schon hat soll die fehlenden Daten irgendwann mal ersetzen und BATMAN_V zu einem besser vorhersagbarem Verhalten bringen.


#8

Da batctl ja inzwischen nicht nur ping und arp integriert hat, sondern auch ein kleines iperf (wann kommt eigentlich der Dateieditor?): könnte man zumindest (als Paket) cronbasiert alle paar Stunden/Tage metriken erfassen lassen für die “bislang unbewerteten Nexthops”. Damit hätte man zumindest für VPN-Links, die sich in den seltensten Fällen an einem wackeligen Mobilfunk befinden dürften, eine sinnvolle Einordnung.


#9

Hey @adorfer auf dem Battlemesh gab es schon eine kleine Codingsession um den automatischen Geschwindigkeitstest der direkt im batman drinsteckt periodisch laufen zu lassen und die Geschwindigkeit anzupassen. Ich hatte noch vergessen, dass bridge interfaces auch keine Geschwindigkeit melden, das hatte in unserem ersten Test dazu geführt, dass WLAN dem Kabel vorgezogen wurde.


#10

Den 1. Punkt kann man ja also leicht umschiffen mit dem richtigen announcement im Gateway.

Heisst das, dass Alle Router, die nicht ath9k target haben nicht nutzbar sind? Oder kann man das umgehen?

Ist das sehr von Nachteil? Oder merkt man das kaum und es wirkt vielleicht sogar wie eine (erwünschte) Art Loadbalancing?

Genial wäre ja, wenn dadurch zwei langsame Verbindungen gebündelt werden könnten, also wenn man z.b. 2 Uplinks hat mit jeweils nur 4 Mbit, dass man dann durch diese Bündelung an die 8 Mbit rankommen würde.

Wir überlegen in Kiel und Flensburg auch auch BATMAN_V umzusteigen, deshalb müsste man vorher schon mal abklären, welche Workarounds man dann im Moment noch bräuchte, damit das flüssig läuft.


#11

zu 2.: Es sind alle Router nutzbar. Die Routing Entscheidungen werden dann aber nicht nach Durchsatz getroffen sondern nach packetloss wie bisher auch. Manuell kann man den Durchsatz immer auf ein Interface setzen.

zu 3.: Wir hatten eine relativ schlechte Umgebung mit einigen Knoten die sich gegenseitig schlecht sehen konnten. Daher kamen fast keine Nutzdaten mehr durch.

Loadbalancing kann man damit nicht machen, dass ist auch weiterhin nicht vorgesehen. Um das Routing allerdings stabiler zu machen läuft grade die Entwicklung, den eingebauten Speedtest für alle Interfaces die keinen Wert liefern laufen zu lassen (siehe git.open-mesh.org Git - batman-adv.git/shortlog).

Es kann nicht schaden ein kleines Mesh/Hood/wasauchimmer mit BATMAN_V laufen zu lassen. Mehr Erfahrung wird hier definitiv helfen.


#12

lange Rede kurzer Sinn, das will man im Produktivnetz eigentlich noch nicht?