ich vermute schon lange das es semi optimal ist auf der einen Seite eine hop-penalty von 15 zu haben und auf der anderen Seite gw client 20
nochmal aufgefrischt:
hop penalty ist die Batman Metrik interne „strafe“ für jeden Hop. Ein direkter Top Link (in der Regel jeder Kabelgebundene Uplink zu einem Gateway) hat ein Maximum von 255.
Das reduziert sich durch hop_penalty und (wenn ich das richtig erinnere) durch packet loss.
die Metrik baut sich bei Beginn von unten auf … verbessert sich also stetig.
gw client 20 bedeutet das ein Wechsel des Gateway(GW) nur stattfindet wenn ein GW um 20 oder mehr Punkte besser ist.
Das führt nun dazu das ich früh ein Gateway auswähle , obwohl noch nicht klar ist welches GW denn jetzt mein bestes ist. das führt auch dazu das ein GW was 1 Hop weiter entfernt ist und bspw. ttq von 240 hat behalten wird, obwohl ich einige andere direkte GW mit ttq 255 habe.
ich vermute das GW class eher weniger sein sollte wie hop_penalty auf den Gateway servern, die in aller Regel noch untereinander sehr gut verbunden sind.
Die Hop Penalty wurde einmal herunter gesetzt um größere Meshwolken zu erlauben und auch 3-4 Hops zu kommen (ein realistisches Szenario mit mittelmäßigen WLAN Mesh links und hop_penalty 15 (default))
hop _penalty kann man auch auf den GW servern auf 21 setzen, auf den knoten bleibts dann bei gw client 20 und damit werden direkte verbindungen nach kurzer Zeit enforced.
bisher haben wir hier nur das problem das unsere meshwolken begrenzt waren und das sozusagen unser lokales Mesh klein gehalten wurde durch die hop_penalty 15 - daher meine intensive beschäftigung damit. Mit den Servern und dessen hop penalty hab ich mich noch nie beschäftigt - aber wenn ich recht habe, sollte man unbedingt auf den servern die gw client XY (default 20) der uplink router gleich der hop_penalty +wenig auf den servern haben.
der effekt +5 bis +10 Punkt penalty hinzuzufügen dürfte keinem weh tun - und das Netz in sonst keiner Weise beeinträchtigen
(ausser an so gaaanz wackeligen Links, wo diese 5-10 eben viel ausmachen und wo der ssid changer aktiv ist (der nutzt die ttq als refferenz metrik und behauptet ab weniger wie 50(glaube) das der link offline ist, was nur begrenzt korrekt ist))
man kann das einfach ausprobieren, low hanging fruit. Die Knoten wechseln in jedem Fall recht flott wenn die bedingung +20 erfüllt ist.
die lösung ist ja entweder die gw client XY runterzusetzen (auf den Knoten, das führt aber auch zu hibbeligeren Knoten und will man auch nicht unbedingt), oder die hop_penalty auf den EXIT GW etwas darüber … (wenn die GW ansonsten untereinander verbunden sind)
was damit nicht gelöst würde, sofern ich recht habe : das ein dhcp lease lange schon bekommen sein kann, bevor überhaupt feststehen kann welcher GW jetzt der beste ist (weil das von unten anfängt) - das könnte dann bspw. einfach der schnellste gewesen sein.
direkt auf einem Knoten verbunden könntest du testen, mit regelmässigem batctl gwl (erste zahl in klammer) wenn der router gerade hoch kommt, oder noch besser wenn du dem den uplink/mesh weg nimmst und dann wieder gibst. das dauert eine kleine weile. Und sofern es mehrere GW gibt, wechseln die auch munter durch.
Kurzum: Handlungsempfehlung konkretisieren: leider nein, es hängt davon ab was man erreichen möchte und man muss das ausprobieren - ob es den quertraffic eindämmt
Coole Analyse. Mir ist allerdings eine deiner Schlussfolgerungen noch nicht ganz klar:
Hier sagst du nur, dass ein Knoten nicht wechselt, aber nicht, dass ein neuer Knoten nicht das bessere Gateway wählt.
Wenn ich dich richtig verstanden habe, müsste man die Strafe zwischen den Gateways hochdrehen, was allerdings auch sofort zu dubiosem Querverkehr führt, wenn man in einer lokalen Meschwolke Verbindungen zu mehreren Gateways hat.
Mir ist das Zusammenspiel von ausgewählten Gateway und DHCP noch nicht ganz klar. Der Knoten wählt ein Gateway aus und lenkt dann alle DHCP-Anfragen seiner Clients dorthin, richtig?
ich hab das so verstanden das an das Gateway alles geht was ich lokal nicht direkt zustellen kann. insofern auch die dhcp requests.
hier ein beispiel, weil ich das gerade zur Hand hab, als der Uplink Knoten rebootet hat, da siehst du das Anfangs der 2, meshende Router ein anderes GW gewählt hat, alles so um die 99 . Dann eine Minute behalten hat, aber später dann ein anderes als bestes erkant hat. Dabei hilft dir die hop penalty hochdrehen allein evtl nicht ausreichend.
Senario: 2 physikalische Server an verschiedenen Standorten A und B.
Auf jedem irgendwelche Dienste/VMs, die die Services erbringen:
Fastd-server
Batman-Gateway
DHCP-Server
v4-Gateway
VPN-Uplink (GRE zum FFRL, whatever)
Prinzipiell kann auf jeder dieser Etappen der Wechsel stattfinden, mit mehr oder minder großen Schmerzen (oder SP-Szenarien, wenn man ihn schlecht verhindert.)
Plasterouter verbindet sich zu FastD A, bekommt aber BatmanGate B, dann kommen die dhcp-replies von Batman A, Das V4-Gateway ist jetzt auch zufällig A, dafür nutzt das V4-GateA aber mangels eigenem Tunnel den von B…
Und mit mehreren announcten v6-Routern wird’s nicht unspannender.
Aber da warte ich erstmal ab, was sich derzeit Interessantes im Gluon tut.
Wenn ich das richtig verstehe, schlägst du vor, die Batman-Links zwischen den GWs mit mehr penalty zu versehen. Das klingt soweit sinnvoll, die wollen wir ja eigentlich nur „im Notfall“ verwenden. Wie würde ich das konkret machen? Wenn ich batman auf den GWs die hop_penalty anders einstelle als auf den Knoten, gibt das dann keine Probleme – wo zum Beispiel das GW den Links zu den Knoten mehr penalty zuweist als die Knoten, weil an den beiden Enden dieses Links ja je verschiedene penalties eingestellt sind?
ist das „gw client“, das du erwähnst, dasselbe wie „gw_sel_class“ in /sys/class/net/<DEV>/mesh? Zumindest ist das bei uns 20
Das stimmt, das kann schon chaotisch werden; Ziel wäre es aber doch, dass es immerhin konvergiert. Wobei wir versuchen, alle Server gleich auszustatten, sodass sie insb. immer selbst einen V4-Uplink haben – und wenn sie keinen V6-Uplink haben, sollten die Clients an den Knoten, die diesen Server gewählt haben, auch kein V6 bekommen.
Wenn der Knoten Batman GW B gewählt hat, sollten doch die DHCP-Antworten auch von B kommen, oder nicht? Das einzige Problem, das ich hier bisher beobachtet habe, waren alte Leases: Der Client hat eine IP von GW A bekommen, danach hat der Knoten auf GW B gewechselt. Der Client hat schön brav regelmäßig (per Unicast) um Verlängerung seines Leases gebeten, und die wurde auch immer gewährt, da Batman ja nur bei den Broadcasts eingreift. Sprixh, der V4-Traffic des Client ging weiterhin über das alte GW. Bei V6 geht das etwas besser (zumindest mit https://forum.freifunk.net/t/ipv6-uplink-und-inter-gw-traffic/10690/7), da wechseln die Clients nach spätestens 5 Minuten auf die neue IP, sodass ihr eingehender Traffic gleich beim richtigen GW ankommt.
Gibt es da irgendwas bestimmtes, was sich im Gluon tust, worauf du dich bezogen hast?
Ich habe die (leidvolle) Erfahrung gemacht, dass viele Versuche, große Netze manuell zu optimieren mit z.B. geänderten Originator-Intervallen oder „strategisch überlegten Hop-Penalties“ dazu tendieren, ins Schwingen zu geraten.
d.h. das Netz / die Routen wechseln dann in Wellen zwischen den Uplinks hin und her. Und sorgen so mitunter für wechselseitigen Vollanschlag und massivsten Quertraffic auf allen Ebenen, wenn ein Batman meint, ein Quertraffic-Link sei weniger belastet und habe daher höhere TQ als der „eigentlich“ kürzere/schnellere/breitere/„bessere“.
Aber wenn jemand testen möchte, ich habe hier mehrere Wolken, in denen man durchaus Dinge tun könnte nach Absprachen.
(Wo uns auch alle Knoten gehören und wir keine Heimnetze bedrohen)
unter der Vorraussetzung das es mehrere Gateway gibt, die auch je exit sind und dhcp und foo machen.
Und das man nebeneffekte in kauf nimmt (gleich mehr dazu)
würde ich bei einem default batctl gw client 20 (default auf den Freifunk Plaste Routern/ Gluon) die hop penalty auf den GW Servern auf 20++ setzen, damit ein Knoten nicht durch den fastd/l2tp tunnel einen extrahop weiter sein GW wählt.
Das setzen auf 30 würde dazu führen, das pro hop den ein GW weiter weg ist vom Tunnelendpunkt man 30 Punkte abzieht (von den maximal 255) - statt womöglich 15.
Bei 15 kann es sein das ein Knoten NIE auf den Tunnelendpunkt wechselt, da er erst bei 20+ wechselt.
15 ist für mittlere Meshwolken ganz gut gewählt - und man möchte das nicht auf den Knoten hochsetzen (in diesem Fall dann gw class 10 bei hop_penalty 15 auf den GW) - das ist auch eine Möglichkeit, aber nicht schön und setzt meiner Meinung nach an dem falschen Ende an.
# auf einer unserer vm abgefragt ...
cat /sys/devices/virtual/net/bat0/mesh/hop_penalty
# gesetzt
echo 30 > /sys/devices/virtual/net/bat0/mesh/hop_penalty
gw_mode|gw [off|client|server] [sel_class|bandwidth]
If no parameter is given the current gateway mode is displayed
otherwise the parameter is used to set the gateway mode. The
second (optional) argument specifies the selection class (if
'client' was the first argument) or the gateway bandwidth (if
'server' was the first argument). If the node is a server this
parameter is used to inform other nodes in the network about
this node's internet connection bandwidth. Just enter any number
(optionally followed by "kbit" or "mbit") and the batman-adv
module will guess your appropriate gateway class. Use "/" to
separate the down‐ and upload rates. You can omit the upload
rate and the module will assume an upload of download / 5.
default: 2000 -> gateway class 20
examples: 5000 -> gateway class 49
5000kbit
5mbit
5mbit/1024
5mbit/1024kbit
5mbit/1mbit
If the node is a gateway client the parameter will decide which
criterias to consider when the batman-adv module has to choose
between different internet connections announced by the
aforementioned servers.
default: 20 -> late switch (TQ 20)
examples: 1 -> fast connection
consider the gateway's advertised
throughput as well as the link quality
towards the gateway
2 -> stable connection
chooses the gateway with the best link
quality and stick 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).
@ralfj
Erklärbar : eine Randnotiz, unterschiedliche Hop_penalty machen garnix, man kann so geschickt routen enforcen - auch wenn die mehr hops haben, als „kürzere“ die man nicht haben will … bzw. routen gezielt schlecht machen.
vom Start zum Ziel gibt es 255 Punkte zu verteilen. Start könnte ich als client sein, und Ziel ein anderer Client oder eben das Exit. Jeder Knoten/server -bzw besser gesagt Batman-adv Punkt der passiert wird (also bspw. Plasterouter bei mir zu hause → Tunnelendpunkt → anderer Server in Freifunk → freifunk.firmwareserver ) verringert die zu meiner MAC gehörenden Punkte um seine Hop_Penalty. (siehe batctl tg | grep W | cut -d")" -f1 # show quality to all other freifunk wifi users
Packet Loss führt auch zu ein bisserl Hop_penalty.
Es kann dann also so sein, weil ich im Garten weit weg Sitze kommen so pi mal Auge -77 Punkte, an meinem Router penalty -15 Punkte, der meshed nochmal -15, der hat nen tunnel zum exit nochmal -25 = 255-77-15-15-25=123 in Richtung Exit Knoten.
@MPW insofern hast du recht damit das sich das nach einiger Zeit gibt (dhcp lease time!) was den effekt bei sich aufbauenden Verbidnungen angeht … allerdings :
@Adorfer - man möchte auf jedenfall verhindern das es sich schaukelt, was bei sehr niedriger hop_penalty schnell passiert : bei deinem benrode beispiel : mach doch mal ein seitenthread auf und lass mal was laufen wie for ip in $(cat iplist_benrode); do echo -n "$ip "; ssh -lroot $ip 'batctl gwl|grep =' ; done
evtl ist das Netz stellenweise zu „schlecht“ … das verrät dir 1. ttvn 2. welcher gw 3. uplink oder mesh
aber auch der nebeneffekt wenn ein GW nur xy l2tp/fastd verbindungen annimmt. Also ein Limit eingestellt hat und das irgendwie einen direkten Zusammenhang mit dem dhcp leases hat (kann ich mir grad nicht vorstellen).
ganz am rande hats einen effekt auf pakete wie ssid-changer, er bei miserablen verbindungen die ssid auf offline-$knoten setzt, und hier wird ja extra „penalty“ zugegeben. der effekt ist aber „klein“ - vernachlässigbar.
Ich verstehe nach wie vor nicht, was Dein Anliegen ist.
Was schlägst Du konkret vor?
Mag sein, dass ich das irgendwie alles falsch lese, aber was sollte man Deiner Meinung nach abweichend vom Standard (HP 15 auf Meshknoten, 30 auf Gateways) setzen?
P.S. Ich könnte auch eine Abhandlung schreiben, dass eine Hop-Penalty von 180 auf Meshknoten und 220 auf Gateways nicht optimal wäre.
Nur auch das würde ich nicht tun, da ich nicht davon ausgehe, dass irgendwer mit solchen Werten fährt.
hast du in deiner folgenden Zeile doch super erfasst, für dich aber nochmal EXTRA als Erinnerung - der doch so gerne überblick und Ordnung im Forum bewahren will : dieser Thread ist ein Hilfsthread zu IPv6-Uplink und Inter-GW-Traffic - #5 von MPW
da hab ich mir sehr viel Mühe gegeben ein existierendes Problem mit den default Werten von gw client XY auf den Plasteroutern und hop_penalty auf Gateways in bezug auf Quertraffic zu schildern, bzw. der dringende Hinweis das das zusammen passen muss! sollte.
is das jetzt ein seitenhieb, rant , whatever ? ich verschieb den sinnfreien comment mal in /dev/null
Ich verstehe nach wie vor nicht, was Du als Alternative zu den üblichen Defaults vorschlägt.
Deinen Erläuterungen glaube ich folgern zu können, dass die mit 15/30 so bleiben sollten.
Oder würdest Du die (wenn ja, wie) verstellen?
@adorfer, wenn deine server hop_penalty 30 haben, und die knoten unverändert gw client 20 fahren ist doch alles gut - versteh nicht was dich da verunsichert? dein beispiel von einem meshcluster is dann noch interessant, aber hier Off topic (s.o.)
Macht das überhaupt Sinn, die hop_penalty auf verschiedenen Knoten der Batman-Wolke verschieden zu setzen? Ich wäre jetzt davon ausgegangen, dass die Plasterouter-Knoten ja den Grafen kennen und einfach die Distanz im Grafen mit der lokalen hop_penalty malnehmen. Das Ändern der hop_penalty auf dem Gateway würde also genau gar nichts bewirken. @fuzzle hast du das mal ausprobiert, die hop_penalty auf den GWs zu ändern? Gab es überhaupt eine Änderung der Metriken auf den Plasteroutern?
Wenn Batman doch die hop_penalty eines Links im Netz propagiert, was tut er dann bei Links zwischen zwei Knoten mit verschiedener hop_penalty?
Ich meine mich zu erinnern, dass Ruben und Mathias mal vor ca. einem Jahr eine Diskussion zur Hop-Penalty auf den Plasteroutern hatten. Die Penalty für die die Gluon-Knoten ist aber derzeit wieder auf 15.
Auf Batman-Gateways kenne ich eigentlich nur 30 als Default-Wert.
Abweichend habe ich lediglich Communities gesehen, die, dort 60 eingetragen haben, um „Traffic in lokalen Wolken“ zu forcieren.
Was aber meines Erachtens Kontraproduktiv ist, weil es nämlich umgekehrt die Gatewaynutzung für Knoten „tief im Mesh“ unterbindet, wenn bei zusätzlich „nicht perfekten“ Linkstrecken die errechnte TQ „zum Gateway“ dann künstlich auf „0“ fählt. Was natürlich nicht den Tatsachen entspricht, aber das ist, womit der jeweilige Knoten dann rechnet.
