Hallo Zusammen,
ich komme gerade nicht darauf wie ich einen bestimmten Server bevorzugen kann bei der Wahl des Routers. Im konkreten Fall haben wir bei einem deutlich mehr Bandbreite und Exklusivtraffic und ich würde den gerne stärker belasten als die anderen.
Würde mich freuen wenn mir da jemand nen Tipp geben könnte!
Grüße
Johannes
Bedingt über die GW Bandwidth:
batctl -m $IFACE gw server 96mbit/96mbit
Aber ich fürchte das hat eher eine dauerhafte Priorisierung, statt eine anteilige Lastverteilung zur Folge, das willst Du ja eigentlich nicht?
Mmh. Zumindest wäre es per Lastenverteiung schicker. Aber danke schonmal!
Wir machen das tatsächlich halbwegs dynamisch bei uns indem wir periodisch die Auslastung per Skript messen und entsprechend die announcierte Bandbreite nach unten korrigieren. So erreicht man tatsächlich eine bessere Verteilung.
Der @RubenKelevra hat das bei uns umgesetzt. Vielleicht hat er ja Lust hier noch rib paar Details zu geben.
Hallo @jom,
wir messen bei uns minütlich die auf eth0 durchgeflossene Daten, und ziehen die von der Maximalbandbreite des Gateways ab.
Hierdurch wird keine sofortige Änderung des Gateways auf den Batman-adv-Clients erreicht. Die Batman-adv-Clients selektieren standardmäßig wie folgt:
Maximale Gateway-Quality-20 als Limit, und aus der Gruppe der Gateways dann jenes mit der höchsten Bandbreite.
Wenn sie einmal ein Gateway ausgewählt haben, bleiben sie bei der Auswahl, bis es 20 Punkte schlechter in der Gateway-Quality ist, als ein anderes Gateway in der Liste. Danach wird die Auswahl erneut durchgeführt.
Das heißt, die Nodes suchen beim starten das derzeit schnellste Gateway, und wechseln nur selten. Wenn man möchte, kann dieses Verhalten auf den Node mittels GW-Selection Class angepasst werden:
1 → fast connection
consider the gateway’s advertised throughput as well as the link quality towards the gateway and stick with the selection until the gateway disappears
2 → stable connection
chooses the gateway with the best link quality and sticks with it (ignore the advertised throughput)
3 → fast switch connection
chooses the gateway with the best link quality but switches to another gateway as soon as a better one is found
XX → late switch connection
chooses the gateway with the best link quality but switches to another gateway as soon as a better one is found which is at least XX TQ better than the currently selected gateway (XX has to be a number between 3 and 256).
Quelle: batctl - html man page (v2023.3-3-gaf2806d)
LG Ruben
Moin @RubenKelevra,
kannst du das Script vllt. mal teilen falls noch aktuell? Baue gerade die ersten Gateways für meine Community auf und würde das gern integrieren.
Gruß Sven
Hallo,
wir haben da bei uns unter Freifunk-Gateway aufsetzen – Freifunk Franken ein gateway selection script, das startet man mit der bandbreite die man announcen will ( traffic vorher mal ausrechnen) und dann passt sich dann dynamisch an, die Router fragen in gewissen abständen das ab. Wir haben aktuell noch ein 2013.4 batman von daher schaltet das nicht automatisch um sondern über nen cron mit */1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client
Vielen Dank dafür, das hilft mir!
Das klingt ja interressant, wenn das funktioniert? Ich hatte mal wo gelesen und dachte desfhalb immer die announced Bandbreite wird weitestgehend ignoriert von den clients.
in Kiel und Freifunk Nord haben wir bisher nur eine minimale Lastenverteilung durch ein Fastd Peer Limit eingestellt:
In der fastd.conf:
peer limit <limit>;
Das begrenzt die Anzahl verbindungen zum Gateway (allerdings kann man dadurch nicht unterscheiden ob sich ein Knoten verbindet an dem noch 10 weitere maschen oder keiner.)
Fällt das nicht alles etwas zu kurz? Per Batman die Bandbreite announcen ist doch eine Regelung im falschen Layer. Wenn man (wie wir) nur eine Fastd Verbindung hat, dann wird zwar der beste Batman gw ausgewählt, der Traffic läuft aber über den Server, der den fastd Tunnel stellt. Das kann doch eigentlich nur funktionieren, wenn man die nodes sich zu allen gates gleichzeitig verbinden lässt. Und das ist für die gate Last nicht gut ums vorsichtig auszudrücken…
Guter einwand, dann würde es derbe viel inter-gateway traffic geben.
@RubenKelevra, habt ihr eine lösung, wie die Knoten auch zu dem gewählten Gateway die fastd Verbindung aufbauen? sie ev. kappen und neu aufbauen, wenn sie ein anderes Gateway wählen?
Setzt ihr alle keine „hop_penalty“ auf den Gateways ?
Als wir noch auf FastD waren haben die Clients/Router grundsätzlich auch
das gleiche GW für Batman ausgewählt über das sie per VPN drin waren.
Gruß
edit:
sah dann ungefär so aus bei batctl auf einem router
lokales gw = 255 TQ
entferntes gw 1 = 125 TQ
entferntes gw 2 = 125 TQ
entferntes gw 3 = 125 TQ
Moin rubo77,
denke du meinst das hier:
echo ‚120‘ > /sys/class/net/mesh-xyz/mesh/hop_penalty
Der Standard-Wert ist zu klein um einen Hop über ein Gateway zu verhindern. Das hier funktioniert.
@Comacho was setzt ihr derzeit ein?
Wir haben die auf 60
Auf den Gateways ist nach meiner Beobachtung ein guter Wert „4 x Router-HP + 1 x Threshold“
Spannend wird es immer erst bei Wolken mit mehreren Uplinks. Wenn da der Wert zu hoch gesetzt ist an den Gateways, dann kann das auch wieder zu unerwünschten Pendel-Effekten führen.
(Ich will nicht blind behaupten, dass das bei 120 schon eintritt, aber ich befürchte es, weil dann der Threshold zu klein wird im Vergleich zur künstlich erzwungenen HP)
Seid ca. 2 Jahren 120 ohne Probleme bisher, aber auf 2013.4 wo das lt. Doku noch
etwas anders gehandelt wird als 2014.x aufwärts. Aber 60 sollte ja auch reichen, um die
TQ des dahinterliegendem Gateways so weit zu drücken das er das lokale bevorzugt?!
@Comacho jain, der hop_penalty in Batman-adv Wert wurde zwar als default angepasst aber Gluon schreibt den alten hop_penalty wieder rein. Wir hatten von Problemen berichtet.
120 funktioniert seit 2012 hier super. Da wir die SSID bei sehr geringen TQ-Werten fürs Gateway wechseln „hüpfen“ die Clients vor einem möglichen „pendeln“ auf einen anderen Node. Pendeln an sich ist überhaupt kein Problem, da die IP der Clients ja weiter besteht. Nur neue Clients bekommen dann eben ne IP von einem anderen Gateway zugewiesen. Das heißt, beide Fastd-Verbindungen werden dann von unterschiedlichen Clients verwendet. Seh da kein Problem.