Aktueller Stand Supernodes und L2TP

Community Troisdorf
1

Hallo Zusammen,

ich wollte mal einen Aktuellen Stand der Supernode umbauten durchgeben.

Wir haben die letzten Wochen sehr viel gebastelt. Leider ließ es sich nicht immer ohne Störungen im Netz durchführen. Mittlerweile sollte aber alles wieder normal laufen.

Die Supernodes werden nun alle per Ansibe Verwaltet und Ausgerollt. So haben wir immer die Möglichkeit schnell einen Supernode zu ersetzen.

Aktiv sind im moment 4 Stück. Alle 4 sind Hetzner vServer mit 1-Kern. Alle Supernodes laufen mit Kernel 3.16 auf Debian und dem Tunneldigger Broker als L2TP endpunkt.

Das Abschmeißen des Traffics ist nun unser nächstes Projekt. Im moment wird der gesammte Traffic Lokal abgeworfen und wir (Ich und Roman) haften mit unseren Firmen für den Traffic. Das soll aber nur eine Übergangslösung sein bis wir bei uns Intern die FFRL Backbone anbindung umgesetzt haben. (Also erstmal nicht über den Netzprovider Hetzner Online wundern)

Leider Spielt Batman adv15 nicht so 100%ig mit wenn es um L2TP geht und die Supernodes halten alle nur ca. 1 Tag durch und booten dann einmal durch. Das macht aber kaum was aus. Wir hoffen dafür in zukunft eine Lösung zu finden.

Die 4 Supernodes machen alle fast ihre 2TB Traffic Grenze im Monat voll. Bis jetzt mussten wir noch nicht nachkaufen. Wir sind mal gespannt ob das so bleibt :wink:

1 „Gefällt mir“
2

Hi @stefan

Welche Probleme habt ihr denn das die Supernodes häufiger abstürzen?
Ich hatte bis jetzt beobachtet das es manchmal zu Probleme kommen kann wenn neue Interfaces hinzugefügt oder entfernt werden. Allerdings ist dies völlig unabhängig von L2TP sondern ist wohl ein Fehler im Code von Batman-Advanced.
Alternativ hatte ich überlegt die Nodes via Bridge in das Bat0 Interface zu hängen, dann muss man nur sicherstellen das mittels Ebtables die einzelnen Switchports untereinander isoliert sind. Dies sollte diesem Problem entgegenwirken da die Interfaces so niemals direkt dem Batman Interface hinzugefügt werden.
Allerdings lässt sich so das Rebroadcasting nicht auf der Server Seite abschalten, aber wie ich sehe nutzt ihr dies anscheinend nicht.

Gruß
Linus

3

Hi Linus,

ja den Verdacht habe ich auch. Ich habe auch mal das mit der bridge versucht, allerdings hat er da auch neu gebootet.

Hier Stürzen die Supernodes z.b. IMMER ab wenn man den tunneldigger neustartet oder beendet. Daher kam mein Verdacht auch.

Ja wie du richtig geraten hast nutzen wir das momentan nicht.

Wie die Supernodes aufgebaut sind kann man ganz gut an der Ansible Config sehen: https://github.com/rojoka/ansible.fftdf.supernode

4

Moin,

wir haben seit Anfang November unser Eventnetz mit tunneldigger am laufen. Die erwähnten Abstürze können wir hier nicht bestätigen.

Das Ganze läuft auf 2 KVM VMs mit 3.16er Kernel. Batman ist in der Version 2015.1 mit der no rebroadcast Option aktiv. Die VMs haben sogar 4 Cores. Auch nach einem tunneldigger Restart friert die VM nicht ein.

Im upscript wird einfach nur das L2TP Interface ins br-mesh gehangen. Funktioniert problemlos

5

Hier Stürzen die Supernodes z.b. IMMER ab wenn man den tunneldigger neustartet oder beendet. Daher kam mein Verdacht auch.

Das Problem hatte ich anfangs, aber dies lag an einem Bug in Batman-Advanced. Die Interfaces wurden nicht freigegeben daher gab es tonnenweise Spam im Kernel-Log und man musste die Maschine komplett neu starten.
Ich bezweifele aber das dies der selbe Bug ist.

Bei uns läuft Tunneldigger super stabil :slight_smile:

6

Ich habe gerade mal den Auto Reboot bei Kernel Panic abgeschaltet. Leider alles was ich sehen kann…

Bildschirmfoto47.png729×424 20.2 KB

7

hast Du oder der Tunneldigger mit batctl if del »Schnittstelle« eine Schnittstelle von Batman entfernt. Wenn ja, dann mutmaße ich, dass man in diesem Bereich den Fehler eingrenzen kann. Ist es ein SMP-Kernel? Wenn ja, versuche die Maschine nicht im SMP-Modus zu betreiben und versuche dann den Fehler zu reproduzieren. Bit Du vertraut mit dem Crashkernel und mit Kerneldups? Mit einem Kerneldump können die Entwickler etwas anfangen und bei Zeit den Fehler beseitigen.

8

Yes, service tunneldigger restart …

So wie ich sehe nicht. Wir haben smp in den Boot Parametern abgeschaltet.

root@troisdorf1:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Common KVM processor
stepping        : 1
microcode       : 0x1
cpu MHz         : 3399.996
cache size      : 4096 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl pni cx16 x2apic hypervisor lahf_lm
bogomips        : 6799.99
clflush size    : 64
cache_alignment : 128
address sizes   : 40 bits physical, 48 bits virtual
power management:

Leider nein

9

ich kenne den tunnelartiger leider nicht, deshalb weiß ich nicht, wie Tunneldigger das intern handhabt. Sieht man bei batctl if mehrere Schnittstellen und kommen welche hinzu, wenn neue Tunnel gegraben werden?

steht bei dmesg | head -n100 | grep SMP irgendetwas vom Aktivierten SMP? á la:

Freeing SMP alternatives memory: 20K (ffffffff81c56000 - ffffffff81c5b000)
x86: Booting SMP configuration:

Steht bei cat /proc/cmdline irgendetwas von

maxcpus=1 nosmp

Ich versuche auf die Schnelle eine Anleitung zu schreiben.

10

ja:Im batctl if sind alle tunneldigger Interfaces sichtbar.

dmesg | head -n100 | grep SMP
[    0.000000] Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09)
[    0.000000] found SMP MP-table at [mem 0x000f0e80-0x000f0e8f] mapped at [ffff8800000f0e80]

BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=20f3faee-1344-429d-834e-5a59fd8c21f0 ro quiet maxcpus=0 nosmp
11

tut mir leid, mit head habe ich es zu sehr eingeschränkt – noch mal bitte: dmesg | grep SMP und dmesg| grep "Booting SMP" -A20 verschafft endgültig klarheit

12

Also maxcpus=0 und nosmp sind das gleiche. Versuchs mal nur mit nosmp oder maxcpus=0

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

Quelle: bootparam(7) - Linux manual page

13

Gibt’s hierzu schon einen Zeitplan ?

14 
root@troisdorf1:~# dmesg | grep SMP
[    0.000000] Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09)
[    0.000000] found SMP MP-table at [mem 0x000f0e80-0x000f0e8f] mapped at [ffff8800000f0e80]
[    0.014363] Freeing SMP alternatives memory: 20K (ffffffff81a1b000 - ffffffff81a20000)
[    0.020070] smpboot: SMP mode deactivated
[    0.020120] smpboot: SMP disabled

dmesg | grep „Booting SMP“ -A20 gibt nix wieder

15

Schon versucht. Brigt keine änderrung. Aber SMP ist ja aus …

16

Nein. Aber bald möglichst

17

perfekt, dann kann man die Ursache debuggen. Ich habe dazu einen neuen Thread gestartet.

1 „Gefällt mir“