ip_conntrack table full

[mbo]

Hallo zusammen,

ich vermute mal, ich bin nicht der einzige, der im laufe der Zeit dieses Problem schon hatte ;)
Im Moment bin ich auf der Suche nach Q&D-Lösungen, bzw. eine Strukturierung des K-Falles.

Kleine Vorgeschichte: Der Rechner ist ein alter IBM mit 32 MB RAM, auf dem nur Bind9 und iptables läuft. ip-conntrack hatte mittlerweile 3 Werte: 2048, 10240, 15560; die ersten beiden sind geplatzt und schon lief die dropped-Parade.

Der einfachste Weg:


ich@bei mir#> /proc/net/ip_conntrack

Macht sich nicht wirklich gut, wenn man gerade selbst per SSH drauf ist

Ich habe mir jetzt zwei Möglichkeiten ausgedacht:
ip_conntrack-Wert ${limit} +1 erfordert eine iptables-Regel, die alle "NEWS" blockt, bis ip_conntrack-Wert ${limit} - 100
Logischer Weise ist das Limit ein paar Verbindungen unter der Grenze, und per iptables werden noch bestimmte Zugriffe erlaubt

Die zweite Möglichkeit:
Nach 24 Std. alle Verbindungen aus der ip_conntrack schmeißen, die älter als 24 Stunden sind.

Sauber wäre es natülich, wenn man iptables neu kompiliert und den Wert für die Verbindungen auf 3 Tage runter setzt, oder auch 1 Tag ... aber bei wirklichen Langläufern wird es unangenehm, wohl aber nicht unangenehmer als Lösung 2.

Und den ganzen Text habe ich eigentlich nur geschrieben, um Anregungen zu bekommen.
Ich hoffe auf gute Ideen ... beschimpfungen gegenüber meines Intellekts und meiner Logik bitte nur in höflicher Form ;)

cu/2 iae

[LINUXRH7]

Hi mbo,

am WE waren wir ja alle ohne Idee oder ähnlichem zu Deinem Problem. Aber vielleicht hilft
das hier ja weiter. Ich wiess, hätte ich auch per Mail machen können, aber da der Thread hier schon auf ist, kann man für die Nachkommen hier Ideen und vielleicht eine Lösung Archivieren :D

Den Ersten Abschnitt kannst du überlesen, das wirst du selber schon wissen.

Die Anzahl in /proc/sys/net/ipv4/ip_conntrack_max ist vom Speicher abhängig. 64MB: 4096, 128MB: 8192. Bei 32 MB könnte ich mir gut vorstellen, dass das System da nicht mehr so richtig nach kommt. Denn die Zahl maximal getrackten Verbindungen kann zwar leicht erhöht werden, aber beachte, daß jede Verbindung ungefähr 350 Bytes des nicht dynamischen Kernelgespeichers frißt!

was hällst du denn von:

echo 120 >/proc/sys/net/ipv4/tcp_keepalive_time oder kleiner.

Wenn man das dann noch in der/dem Applikation/Dienst einzustellen kann, auch da herunter drehen.
Denn wenn man einstellt, dass der Prozess viele Verbindungen händelt, kann dieser Verbindungen blockieren.
Setzt man hier die Anzahl der User herunter, kann je nach Application nach einer bestimmten Anzahl von Threads ein neuer Prozess Starten.

Auch mal nach tcp_keepalive_probes gucken. Vielleicht die auch herunter setzen.

/proc/sys/net/unix
Im Unterverzeichnis existieren drei Dateien. delete_delay gibt die Zeit in Sekunden an, nachdem ein geschlossener Socket aus der Tabelle entfernt wird. Sein reservierter Speicher wird nach der in destroy_delay festgelegten Spanne frei gegeben. max_dgram_qlen gibt die Länge der Warteschlange an, die eintreffende Daten am Socket zwischenspeichern kann.

Gruss
LiNUXrh7