Huhu, ich habe eine Roaming-Netzwerk nach dieser Anleitung, seit gestern habe ich einen zweiten Uplink im Betrieb. Die Client kriegen ja den zu benutzenden Gateway per DHCP mitgeteilt. Welcher DHCP-Server zuerst antwortet, dessen Gateway nutzen sie.
Trotzdem drängeln sich fast alle um den ersten uplink, während die Bandbreite des zweiten fast ungenutzt bleibt.
Kann ich das mit einfachen Bordmitteln ändern, etwa indem ich die Antwortzeit des ersten DHCP-Servers verlängere, oder wie geht man damit um?
Hallo, normalerweise sollte der Router sich den Gateway aussuchen, der am meisten Bandbreite announced, und wenn die Router alle im gleichen Layer2 Netz sind sollte über batman-adv Roaming möglich sein, am besten fragst du mal bei deiner community direkt nach, viel erfolg noch
@MisterCrumble das ist nicht korrekt, die meisten Installationen benutzen batctl gw client 20 - das bedeutet die benutzen einen neuen GW nur dann wenn einer 20 besser ist. es gibt ein batctl gw client 1 das sowas ähnliches macht, aber das bezieht sich nur auf die behauptete BAndbreite, und dann gehen alle zu dem mit dem besseren credits… ein Einstieg wäre die batctl man page zu gw client mode … und hier im Forum mal suchen, eine Einfache Lösung gibt es nicht - bzw. sehr stark von dem physischen lokalen Setup abhängig und u.u. schlicht nicht möglich.
Das bezieht sich aber vor allem alles nur auf die dhcp leases und deren standard Gateway die clients dann bekommen, wie die real beste route ausfällt hängt von der batman TQ ab, und da kann man mit hop_penalty evtl nachjustieren oder mit verringerter Sendeleistung bei dem „heavy use“ knoten
ok, ich habe das bei uns in der firmware jetzt nur ein „“*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client"" gefunden wie der knoten ds gw auswählt wurde mir nur mal so erklärt das er sich das aussucht was am meisten bandbreite announced, roaming tut bei uns
@MisterCrumble das sieht sehr falsch aus, man muss den nicht off stellen, da macht es grundsätzlich sinn das einmalig auf auf gw client 5 oder so zu setzen, oder gleich auf 1 und das nur einmalg, ohne ein off - das bringt nix batctl gw client 1 - abfrage über batctl gw
würd mich interessieren in welcher FW das warum in dieser form drin ist, vielleicht hat/hatte es ja nen guten Grund.
nein, die Metrik bezieht sich auf die TQ zum Gateway.
Und warum der Threshold? Damit die Routen nicht sofort mit dem Flappen beginnen sobald auf einen Link mal ein wenig mehr Last kommt als auf den anderen und daher der Packetlos der OGM-Messung mal um ein paar Prozent schlechter wird.
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).
Hintergrund ist ja, das alles was direkt amKabel hängt und von dort an einen Server geht, also „quasi“ direkt, bekommt die bestmögliche Quality von 255 - aber das hatten wir in Länge auch schon hier im Forum diskutiert. Das das alles nicht besonders gut klappt sei dahin gestelt, ab Batman 2016.1 gibt es auch einen Threshold - aber inwiefern der zur Wahl von Pfaden benutzt wird, kann ich nicht/kaum sagen, daran wäre ich sehr interessiert.
uci batch <<EOF
delete batman-adv.bat0
set batman-adv.bat0=mesh
set batman-adv.bat0.gw_mode=‚client‘
set batman-adv.bat0.gw_sel_class=‚1‘
set batman-adv.bat0.bridge_loop_avoidance=‚0‘
set batman-adv.bat0.network_coding=‚0‘
set batman-adv.bat0.aggregated_ogms=‚1‘
set batman-adv.bat0.ap_isolation=‚0‘
set batman-adv.bat0.bonding=‚0‘
set batman-adv.bat0.fragmentation=‚1‘
set batman-adv.bat0.orig_interval=‚1000‘
set batman-adv.bat0.vis_mode=‚0‘
set batman-adv.bat0.distributed_arp_table=‚1‘
set batman-adv.bat0.hop_penalty=‚30‘
EOF
welchen Effekt soll es denn haben, mit batclt gw herumzuspielen? Die Clients benutzen ja das Gateway, das sie vom DHCP-Server mitgeteilt bekommen haben, also entscheidet allein, welcher DHCP-Server zuerst antwortet, oder übersehe ich etwas?
Das aufrufen von batctl gw listet auf einem gateway die aktuell announcte bandbreite des gateways auf, was das auf einem router tut müsste ich gerade selber nachschauen
__Edit
Also, mir wurde das so erklärt, das der Router alle Gateways in einer wolke/hood/broadcastdomäne in den fastdpeers hat und sich das batman-adv einen anhand bestimmer kritieren raussucht. Dieser wird dann dem Client als Gateway mitgeteilt. (zumindest habe ich das bei uns so verstanden) Es kann also sein das du an einem Router das eine Gateway bekommst und an einem anderen Router ein anderes Gateway. die Gateways sind zumindest bei uns über das batman und über ein fastd einterface ( oder auch l2tpbridge) miteiander verbunden
___ Netzkonzepte können abweichen, ich weiss leider nicht in welcher Community du bist und wie die das lösen
schaltet am Router die gateway selection kurz aus und wieder an, damit eine announcment änderung am Gateway auch registriert wird (quick and dirty ;-))
— Edit.
Die Anpassungen vom Batman das wir aktuell noch verwenden werden erst übernommen wenn man am client die gw selection am client frisch aktiviert wird.
Mir wurde von der Potsdamer Community gesagt, dass ich einfach auf jedem der Uplinks einen DHCP-Server aufsetzen soll, im selben Subnetz aber mit verschiedenen IP ranges. Das Gateway bekommt der Client dann mit dem DHCP lease mitgeteilt. Aber offenbar sorgt das nicht für ein vernünftiges Load Balancing und das ginge auch eleganter…
Bei uns (so wie MisterCrumble beschrieben) läuft das Konzept so:
Alle Router haben zu allen Gateways der Hood (=Layer 2 Broadcastdomäne, davon gibt es hier mehrere die per L3 Babel untereinander geroutet werden, bisschen was anderes als das was meist bei Gluon gemacht wird) eine VPN/l2tp Verbindung (und natürlich die GWs auch untereinander). Auf jeden Gateway wird eine bestimmte Bandbreite announced meist mit diesen Script:
Je mehr Bandbreite auf dem GW frei ist, desto mehr wird also announced.
Da Batman leider zu dumm dafür ist, das auf den Knoten regelmäßig zu aktualisieren muss eben minütlich aus & wieder angeschaltet werden, somit wird dann auch minütlich geprüft ob den mittlerweile ein anderes GW mehr announced und neue Clients dann vllt. von diesem GW eine IP bekommen.
ah, i see - so macht das tatsächlich sinn @MisterCrumble ich nehme jede kritik zurück ihr benutzt ja eben batctl gw client 1 und das mit den sonst nicht aktualisierten bandbreiten is zwar nicht schön mit dem cronjob aber praktikabel. (man könnte mal testen ob das reicht die bestehende gw class neu zu setzen, also sowas wie
batctl gw client $(uci get batman-adv.bat0.gw_sel_class)
