Träum schön, kleiner Rechner
Ein Kunde beschwert sich über massive Beeinträchtigungen beim Zugriff auf zentrale Router innerhalb der Firma. Die remote Konsole ist extrem zäh, oft ist gar kein Verbindungsaufbau möglich. Die CPU des Routers ist völlig im IPv6 Input-Prozess beschäftigt. Ursache war ein Schläfer der alten Schule.
Schadensbegrenzung
Die Anzeige von show processes cpu history zeigte 100% Volllast. Und show processes cpu sorted 5min zeigte den IPv6 Input-Prozess als Verursacher.
Ja, der Router routet IPv6. Nein, er tut es nicht in Software. Die Pakete, die angekommen sind, müssen also trotzdem die CPU erreicht haben.
Zuerst stand ein ipv6 dhcp server im Verdacht, denn an dem Interface, an dem über 4000 Pakete pro Sekunde eingingen, war diese Konfiguration exklusiv vergeben.
Außerdem verschwand die CPU-Last instantan, wenn das Interface shutdown genommen wurde. Das Standby-Interface auf dem anderen Router bekam den Traffic nicht ab. Das deutet darauf hin, dass die Pakete direkt an die MAC-Adresse des physischen Interfaces geschickt wurden.
Als erste Gegenmaßnahme wurden die IPv6-ACL auf deny ipv6 any any log-input umgestellt und siehe an, die CPU Last brach auf 80% zusammen. Nun war der Hauptverursacher der ACL Logger. Wenig überraschend.
Aber die Kiste war wenigstens erst einmal wieder ansprechbar.
Als Grund stellte sich dann heraus, dass die Kiste im StandBy war. Und in diesem Zustand hat die Firmware der Netzkarte das letzte IPv6 Paket mit maximaler Geschwindigkeit raus gepumpt. Immer und immer wieder.
Das Verhalten Standby+Intel-NIC=Paketschleuder haben wir hier im Campusnetz schon öfter beobachtet. Wobei das nicht auf IPv6 beschränkt ist. In dem Zustand schickt die NIC einfach das letzte Paket im Puffer mit maximaler Kadenz ins Netz.
Lösungsmglichkeiten: auf aktuelle Treiber von Intel aktualisieren oder WoL abschalten. Danach war dann auch im Standby Ruhe.
2 Kommentare