Wie @MPW schreibt: Ich bin in einer Nacht und Nebel Aktion erstmal zurück zu fastd, versuche jetzt aber einen neuen Anlauf und nehme erstmal nur eine paar Knoten, die mit viel Last, wieder ins l2tp zurück.
Ich hatte in L2TP in Warendorf äußerst instabil berichtet, aber leider nirgends feedback erhalten. Vielleicht können wir da gemeinsam ran? Ich arbeite jetzt mit batman v2015.2 ohne patches.
Die beiden bat0 Interfaces sind jetzt direkt über gretap miteinander verbunden. Zuvor hatte ich die bat0 jeweils in einer bridge und die bridges mit einem gretap verbunden.
batctl ping klappt dabei aber wunderbar. Und batctl traceroute zeigt den richtigen Weg.
Auf srv1 läuft ein smokeping, der bei die Verluste bei dem einen oder anderen visualisiert.
Frage: gibt es irgendwo einen stabil laufende l2tp-Umgebung? Wenn ja, welche Pakete werden eingesetzt? Ich nutze derzeit a68ed8eddc17652e37687c518341ac6075376683 (link zum modules) auf dem ffrl-packages. Wie sieht es bei dir aus?
Ich hab nur ein paar Infos mal hier und da aufgeschnappt. Eventuell stelle ich es falsch dar, aber ich schreibe es einfach trotzdem mal auf:
Wenn ein Interface aus Batman rausfällt oder entfernt wird, ist die Absturzwahrscheinlichkeit ziemlich hoch. Eventuell trifft das auch auf L2TP-Tunnel zu?
Manche Hoster kommen von der Virtualisierung her nicht mit unserem Anwendungsfall klar und die VMs stürzen ab, weil die Netzwerkkarte nicht mehr reagiert
Ziemlich sicher ist, dass Batman nicht mit Mehrkern-VMs oder Systemen klarkommt
Das hängt denke ich nicht von den Paketen ab.
Und dann gibt es noch eine neue Patchserie für das Batmanabsturz-Problem, zu der ich noch keine Rückmeldungen gehört habe:
Man könnte natürlich versuchen die l2tp-Interfaces alle, statt ins batman, in eine bridge zu schieben, die dann wiederum im bat0 hängt. Wahrscheinlich sehen sich die Knoten aber alle direkt, was (zumindest für die Karte) nicht im Sinn des Erfinders wäre… Könnte man mal versuchen …
Mein Problem: das lief über Wochen super. Die Crahes kamen dann plötzlich … Ich bin aber zuversichtlich: im batman sollte das jetzt ja nicht mehr sterben, denn aus dem Teil vom Code ist das Paket dann ja schon raus und flitzt irgendwo in der Bridge rum …
Es geht hauptsächlich darum das Batman wohl nicht gut mit vielen Interfaces umgehen kann.
Irgendwo im Batman Code spielt dann was verrückt wenn die Interfaces plötzlich verschwinden.
Dem wird ja dadurch entgegen gewirkt das die Bridge nicht andauernd entfernt oder hinzugefügt wird.
Auf den Supernodes in Düsseldorf haben wir die Bridge als normales Interface in der Debian Config hinzugefügt, Tunneldigger entfernt also nur die Interfaces aus der Bridge wenn wir diesen neu starten. Die Bridge selbst bleibt im Bat0 Interface vorhanden.
Edit mit Beispiel:
# Tunneldigger VPN Interface
auto tunneldigger
iface tunneldigger inet manual
## Bring up interface
pre-up brctl addbr $IFACE
pre-up ip link set address 0A:BE:EF:25:00:01 dev $IFACE
pre-up ip link set dev $IFACE mtu 1364
pre-up ip link set $IFACE promisc on
up ip link set dev $IFACE up
post-up ebtables -A FORWARD --logical-in $IFACE -j DROP
post-up batctl if add $IFACE
# Shutdown interface
pre-down batctl if del $IFACE
pre-down ebtables -D FORWARD --logical-in $IFACE -j DROP
down ip link set dev $IFACE down
post-down brctl delbr $IFACE
Es gibt ein paar Bugfixes für Tunneldigger welche ich bereits für 2015.1.2 backported habe.
Außerdem gibt es nun das Paket „gluon-tunneldigger-watchdog“, dies ist ein cronjob welcher prüft ob Tunneldigger läuft und ggf. neu startet. Dies ist nur der Fall wenn Tunneldigger aktiviert ist.
Dies muss einfach nur in die site.mk eingefügt werden.
Hier ein Beispiel modules config für Gluon 2015.1.2
Für die Entwicklerversion einfach wie gewohnt den master branch verwenden.
# This file allows specifying additional repositories to use
# when building gluon.
#
# In most cases, it is not required so don't add it.
## GLUON_SITE_FEEDS
# for each feed name given, add the corresponding PACKAGES_* lines
# documented below
GLUON_SITE_FEEDS='ffrl_packages'
## PACKAGES_$feedname_REPO
# the git repository from where to clone the package feed
PACKAGES_FFRL_PACKAGES_REPO=https://github.com/ffrl/ffrl-packages.git
## PACKAGES_$feedname_COMMIT
# the version/commit of the git repository to clone
PACKAGES_FFRL_PACKAGES_COMMIT=646c8155fb4753294a548676917003c522ffb674
## PACKAGES_$feedname_BRANCH
# the branch to check out
PACKAGES_FFRL_PACKAGES_BRANCH=backports_2015.1.2
Vermutlich wie bei fastd: gar nicht.
Router blacklisten und Server neu starten, damit alle anderen sich erneut verbinden.
(Wobei mir die Serverseite nach wie vor etwas unklar ist. Die Dokumentationslage im Wiki ist nicht so toll. Eventuell ist es einfach noch nicht ausgereift wie fastd.)