Hi,
eines unserer schärfsten Issues auf den Supernodes ist aktuell das Problem,
dass manchmal durch irgendeine Magic keine DHCP-Adressen mehr verteilt werden.
Ich würde in diesem Thread gerne die Problemlösung anstoßen.
Kann zu Beginn nochmal jemand (Björn?) das Problem erläutern und wann/wie es
auftritt?
LG
Clemens
Hi,
eines unserer schärfsten Issues auf den Supernodes ist aktuell das Problem,
dass manchmal durch irgendeine Magic keine DHCP-Adressen mehr verteilt werden.
Ich würde in diesem Thread gerne die Problemlösung anstoßen.Kann zu Beginn nochmal jemand (Björn?) das Problem erläutern und wann/wie es
auftritt?
Das Problem ist nicht der dhcp selbst. Die Server kriegen manchmal eine
kernelpanic und rebooten dann. Bei Server neustarts gibt es öfter mal
Fehler bei der Initialisierung von Interfaces oder so sachen wie das die
rc.local ~20 mal ausgeführt wird. Da liegen die haubt Probleme.
Wir müssen zum einen evaluieren warum die Kernelpanics entstehen, aber
meiner Meinung nach wichtiger wäre dir config so zu härten das ein
reboot vernünftig von statten geht.
Ich hab hier mal ein pad[0] angelegt in dem wir mal reinschreiben können
was alles beim Neustart schief läuft. Daran können wir einzelne Problem
fälle besser evaluieren. Zudem möchte ich Bjo da einfach mal stärker
entlasten da der gute quasi nix anderes mehr macht außer hinter
Problemen hinterher zu rennen. Das geht mir natürlich nicht anders aber
das ist ein anders Bier 
Schöne Grüße
Tarek
Hey,
Das Problem ist nicht der dhcp selbst. Die Server kriegen manchmal
eine
kernelpanic und rebooten dann. Bei Server neustarts gibt es öfter mal
Fehler bei der Initialisierung von Interfaces oder so sachen wie das
die
rc.local ~20 mal ausgeführt wird. Da liegen die haubt Probleme.Wir müssen zum einen evaluieren warum die Kernelpanics entstehen,
aber
meiner Meinung nach wichtiger wäre dir config so zu härten das ein
reboot vernünftig von statten geht.Ich hab hier mal ein pad[0] angelegt in dem wir mal reinschreiben
können
was alles beim Neustart schief läuft. Daran können wir einzelne
Problem
fälle besser evaluieren. Zudem möchte ich Bjo da einfach mal stärker
entlasten da der gute quasi nix anderes mehr macht außer hinter
Problemen hinterher zu rennen. Das geht mir natürlich nicht anders
aber
das ist ein anders Bier
Tarek und ich sind diesbezüglich etwas weiter gekommen. Eine
Überarbeitung der Config des bat0-Interfaces in /etc/network/interfaces
führt dazu, dass nach einem Reboot die Bridge sauber up ist und dnsmasq
problemlos läuft.
Allein auf srv06 scheint bird nicht korrekt hochzukommen, als
workaround sollte es da aber ein 'post-up systemctl restart bird' tun.
Im IRC gabs gerade beschwerden, dass DNS auf srv10 nicht geht.
Grund:
Maximale Anzahl an nebenläufiger DNS-Anfragen erreicht (Max: 150)
Erhöhung auf max. dns-forwards und Cache-Einträge auf 1500 in der
dnsmasq-config schuf Abhilfe.
vg
Haben wir das Problem mit dem DHCP max. Anzahl auch eventuell auf anderen Gateways?
Davon gehe ich mal aus, entsprechend auch die Config auf 06, 11 und 12
angepasst.
vg
Und auf den anderen VPNs nicht?
Welchen anderen?
02, wobei da ja nur paar sich rumtreiben. 04 ist ja grade kaputt. Sorry 
war genug für heute
Vielleicht sollten wir im Netz ein paar Recursor (bspw. unbound)
hinstellen und die dann verwenden, sodass dnsmasq keine DNS-Auflösungen
mehr machen muss? Ggf. könnten wir auch wieder den ISC-DHCP-Server
nutzen.
vg
Vielleicht wäre es eine Idee, 09 oder 03 nicht als supernode sondern only dhcp?
Im nächsten Schritt müssen wir dann evtl. das Grundrauschen mal an und nehmen. Die Systeme brauchen hier doch sehr viel an Traffic nur für interne Sachen.
Problem in Teilen weiterhin vorhanden. Auf 10 und 11 werden die post-up
Befehle (batctl it 5000, batctl nc 0, batctl mm 0) nicht ausgeführt,
auf 06 dagegen schon. Folge: 11 flutete in einem wesentlich höheren
Intervall das Mesh mit OGM-Paketen.
Und diese direkt beim Starten des Interfaces angeben?
Genau da stehen sie doch, bei post-up - also wenn das Interface geupped wurde.Bei srv06 und srv12 klappt das ja auch.
Haben 10 und 11 evtl. einen anderen Kernel?
Nein.
Andere HW?
Und deswegen verhalten sich virtuelle Interfaces anders?
Ich kann die Frage nicht beantworten.
Möchte antworten mit, ich stell es mir bei anderer HW vor das interfaces durch die anderen HW Treiber dann auch anders reagieren.