Freifunk-Gateway aufsetzen/Optimierungen: Unterschied zwischen den Versionen
(niemand fällt sowas auf...) |
|||
| (2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 34: | Zeile 34: | ||
<pre> | <pre> | ||
vi /etc/sysctl.conf // Am Ende einfügen | vi /etc/sysctl.conf // Am Ende einfügen | ||
net | net.netfilter.nf_conntrack_max=131072 | ||
vi /etc/rc.local | vi /etc/rc.local | ||
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize | echo 32768 > /sys/module/nf_conntrack/parameters/hashsize | ||
| Zeile 71: | Zeile 71: | ||
Da aber Batman sowieso die ARP Table cached (batctl dc) werden die ARP Requests im Netz vermutlich sowieso schon eingespart und das ganze dürfte fast nichts bringen. Da es aber auch praktisch nichts kostet kann man es dennoch erhöhen, dies muss im Einzelfall entschieden werden. | Da aber Batman sowieso die ARP Table cached (batctl dc) werden die ARP Requests im Netz vermutlich sowieso schon eingespart und das ganze dürfte fast nichts bringen. Da es aber auch praktisch nichts kostet kann man es dennoch erhöhen, dies muss im Einzelfall entschieden werden. | ||
Für IPv6 gibt es im Batman keinen Neighbor Cache. Es macht hier vermutlich Sinn den Wert deutlich zu erhöhen. | |||
Aktuelle Version vom 26. April 2019, 17:54 Uhr
Problem nf_conntrack
Bei vielen Clients und vorallem NAT und anderen Iptables kann es passieren das die nf_conntrack auf den Server voll läuft. Wenn dies passiert fängt der Server an Pakete zu verwerfen und ist dann nur noch schwer erreichbar. Zu erkennen ist das auch wenn dmesg unmengen von
nf_conntrack: table full, dropping packet
um sich wirft.
Folgendes sollte man im Auge behalten:
Ermitteln des conntrack_max
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
Debian9:
cat /proc/sys/net/nf_conntrack_max
Ermitteln des aktuellen conntrack count
/sbin/sysctl net.netfilter.nf_conntrack_count
sollte die aktuell Größe nahe an die maximale Größe kommen, kann diese vergrößert werden:
sysctl -w net.netfilter.nf_conntrack_max=131072 echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
Der hashsize sollte 1/4 des conntrack_max Wertes betragen Der Wert kann auch permamenent angepasst werden:
vi /etc/sysctl.conf // Am Ende einfügen net.netfilter.nf_conntrack_max=131072 vi /etc/rc.local echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
zusätzlich kann das unnötig lange Timeout verringert werden um den conntrack count schon von Grund auf kleiner zu halten:
vi /etc/sysctl.conf // Am Ende einfügen net.ipv4.netfilter.ip_conntrack_generic_timeout = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000
bzw. die Werte sofort setzen:
sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=120 sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
Quelle: [1]
ARP Cache erhöhen
ACHTUNG: Das ganze ist noch nicht intensiv getestet, bitte bei Änderungen beobachten! Default ist im Linux der Arp Cache relativ klein. Wenn man mehrmals hintereinander die Menge an ARP Einträgen im Cache abfragt (z.b. ip neigh show | wc -l) und man feststellt das der Cache regelmäßig aufgeräumt wird (Zahl springt alle paar Sekunden wieder auf einen deutlich kleineren Wert zurück) sollte man den Wert erhöhen um die Arp Requests im Netz zu verringern. Dies geht über sysctl Variablen:
sysctl -w net.ipv6.neigh.default.gc_thresh1=128 sysctl -w net.ipv6.neigh.default.gc_thresh2=512 sysctl -w net.ipv6.neigh.default.gc_thresh3=1024 sysctl -w net.ipv4.neigh.default.gc_thresh1=128 sysctl -w net.ipv4.neigh.default.gc_thresh2=512 sysctl -w net.ipv4.neigh.default.gc_thresh3=1024
die oben angegeben Werte sind die default Werte. Weitere Infos zu den Werten: https://wiki.manitu.de/index.php/Server:Fehlermeldung_%22kernel:_Neighbour_table_overflow%22
Ich hab z.b. auf nue2gw3 mit ~2400 Clients die Werte auf 2048 4096 8192 gesetzt.
Da aber Batman sowieso die ARP Table cached (batctl dc) werden die ARP Requests im Netz vermutlich sowieso schon eingespart und das ganze dürfte fast nichts bringen. Da es aber auch praktisch nichts kostet kann man es dennoch erhöhen, dies muss im Einzelfall entschieden werden. Für IPv6 gibt es im Batman keinen Neighbor Cache. Es macht hier vermutlich Sinn den Wert deutlich zu erhöhen.
