MPD unter Last
Wird der MPD als LNS unter Hochlast gesetzt, können die L2TP Verbindungen wegbrechen. Die Gründe dafür sind manigfaltig, exemplarisch werden hier einige betrachtet.
Schadensmaximierung
Im Code des MPD sind verschiedenste Asserts verteilt. Wenn davon einer zuschlägt, beendet sich der MPD kontrolliert. Und wenn sich der MPD beendet, fliegen alle Nutzer raus. Ein typischer Assert ist:
ASSERT "new == PHASE_DEAD || new == PHASE_TERMINATE || new == PHASE_AUTHENTICATE" failed: file "lcp.c", line 418
Auslöser der Bedingung ist eine Nutzeranmeldung, die nicht protokollkonform abläuft. Das kann immer mal passieren.
Abstürzen darf eine Software deswegen aber nicht. Was könnte man stattdessen tun?
Man sollte diese eine Anmeldung abbrechen, den einzelnen Kanal herunterfahren und einfach weiter machen.
Interface dicht
Wenn es richtig brummt, geht viel Datenvolumen in Richtung der Endgeräte über den L2TP Tunnel. Auf der Datenleitung mischen sich L2TP-Datenpakete und L2TP-Steuerbefehle.
L2TP: Control connection terminated: 6 (No buffer space available)
Wenn ein Interface ausgehend unter Volllast steht, kann es nicht mehr die Daten von den einliefernden Prozessen abnehmen. Die Unmöglichkeit Daten abzunehmen, signalisiert das Unix mit ENOBUFS.
Der MPD beendet daraufhin sofort den L2TP Kanal und wirft alle Nutzer raus. Eine viel bessere Lösung gibt es vermutlich nicht: Man könnte etwas warten und die Aussendung erneut probieren. Für den L2TP Kanal sollte es einem die Mühe wert sein.
Andererseits kann man die Netzwerkkarte effektiver konfigurieren. Denn die hat wirklich ein Problem.
# sysctl dev.igb | fgrep no_desc_avail dev.igb.1.queue0.no_desc_avail: 19 dev.igb.1.queue1.no_desc_avail: 0 dev.igb.1.queue2.no_desc_avail: 9 dev.igb.1.queue3.no_desc_avail: 0
Die Defaulteinstellung von hw.igb.txd und hw.igb.rxd kann und sollte man von 1024 auf 4096 erhöhen. Das entschärft das Problem.
Darüberhinaus ist besonders eine Karte mit mehreren Queues anfällig für dieses Problem: Der MPD handelt alle L2TP Verbindungen in einem Thread ab und so landen diese alle in der gleichen Sendequeue. Da vier Sendequeues vorhanden sind, werden diese nur mit einem Viertel der möglichen Geschwindigkeit geleert.
Mehrere LNS laufen unter igb, andere unter em-Treibern. Der em-Treiber hat nur eine ausgehende Warteschlange und diese Maschinen sind deutlich unauffälliger gegen diese Abbrüche. Also wechseln alle LNS von igb auf em.