Evil Overload und der Dominoeffekt
Der MPD tut an sich zuverlässig für PPPoE Terminierung. Wenn es aber zu Abstürzen des zugrundeliegenden Systems kommt, bekommen die anderen LNS im Verbund die wegfallenden Teilnehmer mit einem Schlag ab. Und dann können andere System ebenfalls zusammenbrechen.
Genauere Beobachtung des Effektes zeigt, daß der nächste LNS ca. 10min später abstürzt. In einigen Fällen meldet er vorher noch den Verlust einer oder mehrerer L2TP Sessions. Als Gründe werden i.d.R. angegeben:
mpd: L2TP: Control connection X terminated: 6 (Control channel timeout - Remote peer dead) mpd: L2TP: Control connection Y terminated: 6 (expecting reply; none received)
Rückfrage beim Carrier ergibt, daß er kurz vorher schon einen ähnlichen Eintrag in seinem Log hat. Dort wird ebenfalls die L2TP Verbindung für tot erklärt.
Wie kommt es dazu? Der MPD arbeitet doch weiter? Er meldet aber immer wieder im Log.
mpd: Daemon overloaded, ignoring request.
Normalerweise tritt dieser Eintrag selten auf. Wenn die Maschine nachts mit den von den Kunden in vorauseilendem Gehorsam verursachten "Zwangs"-Trennungen loslegt, tritt so ein Eintrag ein bis zehnmal pro Sekunde auf.
Nach dem Absturz eines LNS werden aber schlagartig alle Kunden auf die anderen LNS verteilt. Dann ist die Überlast fast übermächtig. Vierhundert bis sechshundert Verbindungsaufbauten pro Sekunde sind dann der Normalfall.
Im MPD ist ein Überlastschutz eingebaut. Er stellt sich einfach tot:
if (OVERLOAD()) {
Log(LG_PHYS, ("Daemon overloaded, ignoring request."));
goto failed;
}Damit er nicht die Arbeit völlig einstellt, kommt eine zufällige Anzahl von Verbindungsversuchen trotzdem durch:
#define OVERLOAD() (gOverload > (random() % 100))
Allerdings erreicht der Wert von gOverload schnell die 100. Dann stellt sich der Daemon wirklich tot.
#define SETOVERLOAD(q) do { \
int t = (q); \
if (t > 60) { \
gOverload = 100; \
} else if (t > 10) { \
gOverload = (t - 10) * 2; \
} else { \
gOverload = 0; \
} \
} while (0)Und genau das fällt dem LAC auf. Er trennt die L2TP Session zu dem vermeindlich "toten" Peer. Damit antwortet er auch selbst nicht mehr auf die Pakete des LNS im gerade geschlossenen Kanal. Und nun macht auch der LNS die Pforten dicht. Wieder fallen Tausende von Kunden aus dem Netz.
Die Lösung ist so einfach wie nur möglich. Ich habe die Berechnungsvorschrift für gOverload geändert:
/* SETOVERLOAD: can reach 0 .. 98 */ gOverload = (q < 10) ? 0 : (99.0 * (1.0 - 10.0/q));
Nun gibt es immer eine Chance eine neue Verbindung durchzubekommen.
Der LAC ist happy, weil er den Tunnel nicht länger verliert. Der LNS ist happy, weil er unter Last nicht zusammenbrechen muß, sondern weiterhin Aufgaben verweigern kann.
Leider ist das Verfahren doch zu einfach gestrickt. Es kommen unter Last so viele Neuverbindungen noch durch, daß deren Behandlung das betroffene System mächtig belastet. Die LACs erkennen trotzdem auf "Dead Peer" und das Spiel geht von vorne los. Nun müßte man die Implementierung des kommerziellen LAC kennen, um zu wissen, woran ein Peer als "tot" erkannt wird. Aber das definitiv zu erfahren, ist wohl unmöglich.
Was kann man tun? Zum einen ist zu kontrollieren, ob vom Overload auch die Pakete des Control Channels betroffen sind. Andererseits sollte der LNS sich im Überlastfall nicht tot stellen, sondern eine klare Fehlermeldung an den LAC schicken. Da hilft nur, die Standards zu lesen.
Aber zuerstmal zurück zu striktem Overload:
static void
update_overload(void) {
int i,o=0;
time_t now;
static time_t last_reported = 0;
static int peak[2] = {0};
time(&now);
for(i=0; i<sizeof(queue)/sizeof(*queue); i++)
if(queue[i].port) {
int l = mesg_port_qlen(queue[i].port);
o += l * (2 + queue[i].max_workers);
if(peak[i] < l)
peak[i] = l;
}
/* SETOVERLOAD */
gOverload = (o < 10) ? 0 : (o < 110) ? o-10 : 100;
if(now > last_reported) {
Log(LG_ALWAYS, ("Queues had up to %d (serial) and %d (parallel) entries."$
peak[0], peak[1]));
peak[0] = 0;
peak[1] = 0;
last_reported = now + (60 - 1); /* 1 second due to strict less then */
}
}Wirklich tot?
Eine genauere Überprüfung des MPD-Codes ergab, daß sich hinter dem goto failed doch eine Benachrichtigung des LAC findet. Diese meldet eine temporäre Überlastung ohne weitere Angaben. Trotzdem klassifiziert der LAC den LNS als tot.
Offenbar genügt der temporäre Fehler dem LAC nicht, um einen anderen LNS zu probieren. Immer und immer wieder wirft er ein und dieselbe Anmeldung dem gleichen LNS vor.
Aber es gibt ja "LNS guided LAC" und das sollte dort wirklich stehen.
--- mpd-5.6/src/l2tp.c 2011-12-21 15:58:49.000000000 +0100
+++ mpd-5.6-lutz/src/l2tp.c 2013-06-09 16:40:35.000000000 +0200
@@ -1112,6 +1123,7 @@
Link l = NULL;
L2tpInfo pi = NULL;
int k;
+ char const * failreason = NULL;
/* Convert AVP's to friendly form */
if ((ptrs = ppp_l2tp_avp_list2ptrs(avps)) == NULL) {
@@ -1126,12 +1138,12 @@
ppp_l2tp_sess_get_serial(sess), ctrl));
if (gShutdownInProgress) {
- Log(LG_PHYS, ("Shutdown sequence in progress, ignoring request."));
+ failreason = "Shutdown sequence in progress, ignoring request.";
goto failed;
}
if (OVERLOAD()) {
- Log(LG_PHYS, ("Daemon overloaded, ignoring request."));
+ failreason ="Daemon overloaded, ignoring request.";
goto failed;
}
@@ -1194,10 +1206,10 @@
ppp_l2tp_avp_ptrs_destroy(&ptrs);
return;
}
- Log(LG_PHYS, ("L2TP: No free link with requested parameters "
- "was found"));
+ failreason = "L2TP: No free link with requested parameters was found";
failed:
- ppp_l2tp_terminate(sess, L2TP_RESULT_AVAIL_TEMP, 0, NULL);
+ Log(LG_PHYS, ("%s", failreason));
+ ppp_l2tp_terminate(sess, L2TP_RESULT_AVAIL_TEMP, L2TP_ERROR_TRY_ANOTHER, failreason);
ppp_l2tp_avp_ptrs_destroy(&ptrs);
}Bei der Überprüfung einer anderen Verbindung kam die Rückmeldung vom Carrier, er würde in seinen Logfiles folgende Einträge sehen, die da bisher nicht standen:
%L2TP-7-SES: 16646:53888 Sending ICRQ %L2TP-7-SES: 16646:53888 Rcvd CDN rid:0 (4,7) L2TP: No free link with requested parameters was found %L2TP-7-SES: 16646:53888: peer failure, rerouting session %L2TP-7-SES: 16646:53888 remote abort: peer failure, rerouting session (tc 23)
Das ist genau das, was der MPD nun dem LAC sendet. Der kommerzielle LAC (Redback) reagiert darauf genau wie gewünscht, er versucht die Session auf einem anderen L2TP Kanal abzukippen.
Damit ist die Änderung ein voller Erfolg:
- Kunden kommen deutlich schneller wieder online, weil sie im Überlastfall auf andere, höher belegte L2TP-Tunnel verschoben werden.
- Es ist nun möglich, die Annahme neuer Session gezielt zu verweigern, ohne den Carrier um Abschaltung des Tunnel bitten zu müssen. Damit kann man ein Komponente gezielt freiräumen, um unterbrechungsfrei arbeiten (z.B. Software tauschen) zu können.
Problem gelöst.