Maximale Clients auf einem Gateway begrenzen

anon68922371 · 14. Februar 2016 um 12:54

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

ReVoLt112 · 14. Februar 2016 um 14:11

peer limit 200; #Hier begrenzt auf 200 Verbindungen

in der fastd.conf eintragen

PetaByteBoy · 14. Februar 2016 um 17:40

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

ffksBeteiligter · 14. Februar 2016 um 18:06

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.

MrMM · 14. Februar 2016 um 18:09

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.

PetaByteBoy · 14. Februar 2016 um 18:11

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.

anon68922371 · 14. Februar 2016 um 18:19

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.

MrMM · 14. Februar 2016 um 18:27

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.

anon68922371 · 14. Februar 2016 um 19:15

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

Da kann man es schön sehen.

rubo77 · 7. Juni 2016 um 04:02

Irgendwie haben wir hier jetzt immer noch keine Lösung

vax · 7. Juni 2016 um 23:17

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.

wusel · 8. Juni 2016 um 00:00

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

In …

github.com

ffgtso/ffgt-gln-gw-puppet/blob/master/templates/etc/fastd/fastd-blacklist.sh.erb

#!/bin/bash

if [ -e /var/run/FASTD-<%= @mesh_code %>_FULL ] ; then
    /usr/bin/logger "$0: <%= @mesh_code %> fastd rejects $PEER_KEY because: $(cat /var/run/FASTD-<%= @mesh_code %>_FULL)."
    exit 1
fi

if /bin/grep -Fq $PEER_KEY /etc/fastd/<%= @mesh_code %>-mesh-vpn/fastd-blacklist.json; then
        exit 1
else
        exit 0
fi

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

Mittels des per cron aufgerufenen Checkscripts …

github.com

ffgtso/ffgt-gln-gw-puppet/blob/master/templates/etc/fastd/calculate_fastd_threshold.sh.erb

#!/bin/bash
#
# Calculate if fastd should accept more connections, but only after the
# system reached an uptime of at least 301 seconds (i. e. 5 minutes).
#
# We use "batctl o" as current network size (NETWORKSIZE)
# We use "batctl gwl" as current number of GWs (NUMGATEWAYS)
# We add 50 to NETWORKSIZE, then do MAXPEERS=NETWORKSIZE/NUMGATEWAYS.
# A static MAXPEERS setting can be written to /etc/fastd-limit.
# Finally we check the number of current fastd connections against MAXPEERS.
# If we have more connections, we'll just touch /var/run/FASTD-<%= @mesh_code %>_FULL,
# otherwise, we delete it.
#
# /etc/fastd/<%= @mesh_code %>-mesh-vpn/fastd-blacklist.sh should check for the existence
# of /var/run//FASTD-<%= @mesh_code %>_FULL and reject new connections if it's there ...

if [ ! -e /var/run/fastd-status.<%= @mesh_code %>.sock ]; then
  /usr/bin/logger "$0: WARNING: no fastd-status socket for <%= @mesh_code %>, is fastd running?"
  exit 0
fi

This file has been truncated. show original

… 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.

rubo77 · 12. Juni 2016 um 21:21

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.

vax · 12. Juni 2016 um 21:25

Nein.
Schau dir mal Batman-Adv Routing an.

fuzzle · 17. Juni 2016 um 04:58

@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 …