B.A.T.M.A.N. Symptombekämpfung

Technik Admin-Tagebuch
1

Da wir vorläufig nicht - und vor Allem nicht aus dem Stand - auf eine bessere Netztopologie und stabilere Tülchens umstellen können, werden wir nun auf den Servern auf denen batman aktiv ist die default sysctl.conf um zwei Zeilen ergänzen:

kernel.panic_on_oops = 1
kernel.panic = 1

Dies sorgt dafür das eine Sekunde nach einer Kernel Panic / oops, der Server automatisch resetted wird und neustartet.

Seit ein paar Wochen haben wir dies bereits zum Testen auf 4 Servern aktiviert, das Ergebnis ist absolut zufriedenstellend.

Bei normalen Servern kommen lediglich die beiden Zeilen in die sysctl.conf hinzu, bei batman gateways (Supernodes) sieht die neue sysctl.conf entpsprechend wie folgt aus:

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
net.ipv4.tcp_syncookies=1
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv4.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.accept_source_route = 1
net.ipv6.conf.all.accept_source_route = 1
net.ipv4.conf.all.log_martians = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 0
kernel.panic_on_oops = 1
kernel.panic = 1

P.S.:

Nach dem Bearbeiten der /etc/sysctl.conf mit „sysctl -p“ die Werte neu einlesen, da es sonst erst nach dem nächsten Reboot greifen würde!

9 „Gefällt mir“
2

Kommen bei euch wirklich so viele Panics vor? Hab ich den Beitrag überlesen wo ihr die Gründe darlegt? Wenn ja bitte verlinken. Könnte für Communitys die noch wachsen hilfreich sein wenn die später auch in diese Probleme laufen.

3

Also in Rheinufer haben wir diese Panics auch und haben bis jetzt keine Lösung dafür. Die automatischen Reboots sind nur ein Workaround.
Warum diese Panics auftreten kann ich auch nicht beantworten. Dies scheint aber vermehrt aufzutreten wenn man z.b. Fastd neu startet auf den Supernodes. (Auch einer der Gründe warum ich dafür lieber Reboots mache :wink: )

4

Bei uns in Aachen stellt sich die Sache so dar, dass wir bei einem Rechenzentrum keine Probleme haben und beim anderen RZ ebenfalls diese Probleme haben.

Beides sind KVM Hosts.

Die paravirtualisierten XEN Hosts die das Kernel Modul bereits von der dom0 bekommen funktionieren ebenfalls problemlos.

Wir erstellen bei den betroffenen Systemen jetzt Crash Dumps, wäre spannend eure zum Vergleich zu haben:
https://wiki.ubuntu.com/Kernel/CrashdumpRecipe

5

Leider bringen die Crash-Logs für die alte Batman Version nicht viel. Diese Bugs werden nämlich nicht mehr gefixt von den Devs. Diese arbeiten nur an der aktuellen Version. (Compat 15)

6

Hat sich schon mal jemand Gedanken gemacht wie möglichst ohne Komplettausfall und so schmerzfrei wie möglich die Umstellung auf neuere BATMAN_adv Versionen von statten gehen soll?

7

Parallele Server mit der neuen Version.

Aber bevor das nicht als stable vom Team Gluon freigegeben ist, ist mir das Risiko zu groß zu wechseln…

8

Genau und dann entsprechende Blacklist für Nodes mit Uplink die ihr update erst bekommen dürfen wenn ihre Satelliten ihres schon haben.

Hat in Aachen gut funktioniert, sollte aber noch mehr Automatisierung bekommen:

9

Ich muss jetzt doch mal eine DAU-Frage stellen. Ich möchte mich dafür schon mal entschuldigen.

Warum nutzen die Freifunker eine legacy/unsupported BATMAN Version und nicht die z.Z. aktuelle? Welche „Nachteile“/Bugs hat diese?

10

Weil die neue Version unstable ist und noch nicht in größeren Setups getestet wurde. Außerdem bietet diese Version momentan noch keine Vorteile weil z,b. die Multicast Verbesserungen nicht die gewünschte Wirkung erzielt haben.
Daher warten die Communities noch mit der Umstellung auf die neue Version.