[Vorankündigung] Troisdorf wechselt zu l2tp

Hallo Zusammen,

einige haben bestimmt gemerkt das unser Netz in letzter Zeit ein wenig Wackelt. Das liegt daran, das wir Versuchen den Supernodes l2tp beizubringen.

Dabei haben wir auf Kernel 4.2 die selben Probleme wie @phip mit Kernel Panics. Desswegen wird höchstwarscheinlich der Standard Kernel behalten, und wir Pushen per Alfred die verschiedenen MAC Adressen zur Map.

Ebenfalls werden wir unser Backbone auf GRE umstellen.

Weiteres folgt sobald wir eine Funktionierende Teststellung geschafft haben

1 Like

Hab ihr mal Kernel 4.1 versucht? :wink: Damit läuft es bei uns Stabil in Düsseldorf

Nein noch nicht … Aber der Tipp ist gut …

Wo bekomm ich den denn auf Debian 8 am einfachsten her?

jessie-backports liefert nur 4.2

Der ist bei Debian direkt in den Backports dabei :smile:

Einfach das Backports Repo in /etc/apt/sources.list hinzufügen:

deb http://http.debian.net/debian jessie-backports main

dann einmal apt-get update ausführen und das Image sowie die Header installieren:

apt-get update
apt-get install linux-image-4.1.0-0.bpo.2-amd64 linux-headers-4.1.0-0.bpo.2-amd64 linux-headers-4.1.0-0.bpo.2-common

Edit:

Hab gerade erst gelesen das du schon backports verwendest, warte ich schau mal ob der Kernel im Archiv ist :wink:

1 Like

Bei uns läuft alles rund mit SMP,Bat15,L2TP seid wir vom verstaubten Debian auf Ubuntu-Server mit 4.2 Kernel gewechselt haben :smile:
Habt ihr mal geguckt ob die Kernel Crashs aufhören wenn ihr CPU´s deaktiviert und nur noch 1 verwendet?
Bei Virtuellen Maschinen ist das ja eh wumpe, kannst ja im Hypervisor die Leistung hoch drehen.

LG

btw. Cyrus das Problem mit den Kernel Crashs trat bei uns auch mit dem 4.1bpo Debian Kernel auf,
es ist wohl auch abhängig von der anzahl der Nodes die sich in der Domäne tummeln

Wir haben hier zum Testen die Hetzner 1-Cpu vServer gemietet. Die Crashen mit 4.2.

Hmm um was für eine Virtualisierung handelt es sich denn?
Ich glaube das euer Problem eher daher kommt, evtl beißt sich der Gast-Kernel mit irgendwas auf dem Host System.
Wir haben zwar auch alle 1-2 Wochen auch mal Kernel Panics, aber die Systeme Rebooten dann direkt (Reboot on Panic)
Wie oft kommt das bei euch denn vor?

Edit: Wir haben auch zwei CPUs

Na anscheinend ist dort SMP aktiv?!
Was sagt denn

dmesg |grep smp

auf unserer oben genannten Kiste kommt das hier

root@node01-1:~# dmesg |grep smp
[ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.198123] smpboot: CPU0: Intel® Atom™ CPU N2800 @ 1.86GHz (fam: 06, model: 36, stepping: 01)
[ 0.210960] smpboot: Total of 4 processors activated (14932.43 BogoMIPS)

auf den restlichen wo SMP deaktiviert ist erfolgt keine Ausgabe.

dmesg | grep smp
[    0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[    0.050651] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-26xx (Sandy Bridge) (fam: 06, model: 2a, stepping: 01)
[    0.051998] smpboot: Total of 1 processors activated (3999.99 BogoMIPS)

Also ist SMP aktiviert, ich weiß zwar nicht warum, aber es hat bei uns auf Virtualisierten Maschinen immer zu Problemen geführt mit Bat15. Bei uns liefen die unter VMWare ESX 5.5 / 6 und auch auf HyperV.

Und ohne will er auch nicht:

update-grub
/usr/sbin/grub-mkconfig: 33: /etc/default/grub: nosmp: not found

Versuchs mal damit als boot parameter:

       'nosmp' and 'maxcpus=N'
              (Only when __SMP__ is defined.)  A command-line option of
              'nosmp' or 'maxcpus=0' will disable SMP activation entirely;
              an option 'maxcpus=N' limits the maximum number of CPUs
              activated in SMP mode to N.

Via: bootparam(7) - Linux manual page

1 Like

Genau das was Cyrus sagt sollte klappen, hat bei uns und einigen anderen Communitys Abhilfe geschafft :slight_smile:
Hier ist es noch etwas ausführlicher erklärt

https://wiki.ubuntuusers.de/Bootoptionen/no_redirect

nosmp nimmt er nicht … aber ich habe jetzt mal maxcpus=0 reingepackt

Mal sehen ob das was bringt.

Welcher Kernel kann denn jetzt L2TP vernünftig? Mit dem Standardkernel meinst du den 3.16 von Jessie?

Wir haben mit dem 3.16er nämlich leider das Problem, dass die ip rule suppress_prefixlength=0-Option nicht funktioniert und zu Abstürzen führt.

Eventuell habt ihr aber ein ip rule-System, dass ohne diese Option auskommt.