Der Fluch ist gebannt
Die regelmäßigen Zusammenbrüche der L2TP Tunnel haben genervt und wurden offiziell gefixt. Aber wurden sie es wirklich?
Die Kaskade im Rückblick
Am 31. Dezember war es wieder so weit. Ein Sequenzzähler hatte die 15-bit Grenze erreicht. Der L2TP Kanal blieb hängen.
Nach einigen Minuten Timeout wurden die Nutzer getrennt, weil ja – für beide Enden des Tunnels – die Gegenseite nicht mehr antwortete. Auf diese Weise bekamen die anderen Tunnel die Nutzer zugeschlagen und deren Sequenzzähler stiegen beschleunigt an.
Es ist also nicht verwunderlich, daß sich nur kurze Zeit später der nächste Tunnel der magischen Grenze näherte. Infolge des Abbruchs dieses nächsten Tunnels steigen die Sequenzzähler bei den anderen noch rascher.
An diesem Silvesternachmittag waren mehrere Tunnel kurz vor der magischen Grenze, was die Kaskade in Gang setzte. (Der breite Balken in dem Bild stammt von zwei überlappend aufgebauten L2TP Tunneln zwischen dem gleichen LAC und LNS mit gleichen IP Adressen. Dadurch erscheinen hohe und niedrige Sequenzzähler durcheinander für die gleiche Kurve.)
Zuerst fielen Nutzer aus einem Tunnel in den nächsten. Dann wurden Sie dort wieder rausgeworfen, weil auch dieser Tunnel die Grenze erreichte. So wurden die gleichen Nutzer mehrfach hintereinander getrennt, während andere Nutzer gar nicht betroffen waren.
Da der betreffende LAC nun auch die anderen Tunnel dieses LNS nicht mehr bediente (die vorzeitigen Abbrüche), verschlimmerte sich das Verhalten nur. Es wurden weitere Nutzer rausgeworfen und weitere Tunnel ins Limit getrieben.
Erst nachdem praktisch alle Tunnel abgestorben und neu gestartet waren, beruhigte sich die Situation und alle Kunden konnten sich sauber neu anmelden.
Patchen und Warten
Nach der Diagnose des Problems und einspielen des Patches, mußt sich zeigen, ob überhaupt eine Wirkung eintritt.
Nach mehr als zwei Wochen Wartezeit steht nun endgültig fest, daß dieses konkrete Problem gelöst ist: Am Wochenende haben die ersten Tunnel die 15bit Grenze ihrer Sequenzzähler überschritten.
Ein Blick in die Datenbank bestätigt die Bilder:
ippool=# SELECT Max(ns) FROM l2tp_statistik WHERE zeit > current_date
GROUP BY lac,lns ORDER BY 1 DESC LIMIT 5;
max
-------
37230
37093
37079
36761
34548
(5 rows)Damit ist der Fluch der Stabilität gebannt.
Ich hatte den gleichen Fehler mit pfSense 2.1.4 (FreeBSD 8) und habe über zwei Wochen gebraucht um die Ursache zu finden. Ein Update auf 2.2 (FreeBSD 10) hat das Problem dann gelöst.
1 Kommentare