Maximale Clients auf einem Gateway begrenzen

Moin FFer.

Gibt es eine Möglichkeit die Clientzahl auf einem fastd Gateway zu begrenzen?

Ich habe hier im Forum zwischen den Zeilen mal davon gelesen…

Gruß
Tarnatos

peer limit 200; #Hier begrenzt auf 200 Verbindungen

in der fastd.conf eintragen

1 Like

Man kann auch noch mit der announceten Bandbreite (batctl gw server xxxmbit) rumspielen.

Kann man denn die maximale Anzahl von Clients eigentlich auch direkt am Accesspoint/Freifunk-Router - statt am Gateway - begrenzen?

Das würde mich in dem Zusammenhang interessieren.

Damit kannst du keine Entlastung der fastd Tunnel erreichen, höchstens zusätzlichen Quertraffic zwischen den gw.

Du kannst ein wie auch immer geartetes Kriterium festlegen und dann mittels

on verify

in der fastd.conf die Verbindung ggf ablehnen.

Laut Wireless configuration [Old OpenWrt Wiki] kannst du ‚maxassoc‘ in /etc/config/wireless oder per uci setzen, um die Anzahl der Clients zu limitieren.

@MrMM

Wenn man mehrere Tunnel (hier 2) pro Router hat dann schon.

2 Likes

Wir kämpfen derzeit bei rund 330 Nodes im Netz mit einem unserer Hoster myLoc. Bei einem der Server dort, springt ständig die ddos Protection an, was zu paketloss via IPv4 führt.

Da der Hoster sich mehr als unkooperativ zeigt, suchen wir derzeit nach Möglichkeiten die Tunnel zu begrenzen. (s.o.).

Auch die Aufteilung der Clients auf alle Gateways ist mal wieder ein Thema. 300 Clients spielen mit allen 3 GWs ping pong. Alle sind oft nur auf einem GW konzentriert… Wirklich nervig dass dies nicht out of the Box besser gelöst ist.

Die Auswahl geht nach Latenz, die Supernodes werden kurz nacheinander gefragt, wer als erstes Antwort gewinnt.

Diese Strategie halte ich für zweckmäßig und sie funktioniert bei uns sehr gut.

Die Verteilung des IPv4 Traffic ist ebenfalls sehr gleichmäßig, lediglich IPv6 ist eingehend aus technischen Gründen auf zwei Gateways konzentriert.

Schau mal bei uns in den MV. mesh.ffnord.net

Da kann man es schön sehen.

Irgendwie haben wir hier jetzt immer noch keine Lösung

Wenn den Problem der Traffic auf einer GW Node ist, dann begrenze die fastd Connections wie oben angegeben. Haben wir hier eine zeitlang so gemacht und funktioniert als Stellgröße für den Traffic prima. Nix mit „hin und her“. Wir hatten pro Node nur eines fastd connection.

JFTR, wir fahren recht gut mit dynamischen Limits via fastd-blacklist.sh:

In …

… wird auf eine Statusdatei geprüft und ggf. eine neue Kontaktaufnahme abgelehnt.

Mittels des per cron aufgerufenen Checkscripts …

… wird jene Datei in Abhängigkeit von der Netzsituation auf jedem der Gateways erzeugt oder gelöscht, sodaß sich über die Zeit die Knoten über die Gateways verteilen, egal, was fastd gerne hätte.

1 Like

ich dachte, dass ein Ablehnen der fastd-Verbindung nicht ausreicht. also dass dann immer noch Knoten versuchen könnten ihr einmal ausgewähltes Gateway zu erreichen über den Umweg von anderen anderen Gateway. Also dass man dadurch nur mehr quer Traffic erzeugt zwischen den Gateways.

Nein.
Schau dir mal Batman-Adv Routing an.

@rubo77 … etwas eindeutiger … knoten machen x fastd verbindungen auf die haben dann eine sehr hohe ttvn (das die erste zahl in Klammern bei batctl gwl) mit jedem Hop gibt es hop_penalty und daher „weniger“ ttvn .
Jetzt muss man noch wissen das für die plaste knoten batctl gw client 20 default ist, und bedeutet das ihm die announcierte bandbreite egal ist - er das GW wechselt sobald eines um 20 ttvn besser ist. Einen echte Unterschied gibt es erst bei gw client 1 (dazu auch mal batctl manpage lesen)
eine besseres routing inkl speed kommt erst so langsam - die batman patches sind erst for ein paar Wochen für das aller allerneueste Batman eingeflogen, und erlauben überhaupt ersteinmal iperf ähnliche geschwindigkeit tests. (da mal auf der DEV Liste nachsehen)
hoffe das war verständlich genug - was die Knotenseitige wahl von batman gw angeht. Er wird also in der Regel das nächste GW nehmen …

1 Like