xplod
11.05.10, 08:42
Hallo zusammen.
Ich habe ein Problem mit meinem OpenSuse 11.1 64bit Server (Intel i7 12GB RAM):
Das Ding steht in einem Firmennetzwerk, in dem es nachts hoch her geht. In den Logbüchern stehen dutzende von DNS Anfragen, so wie versuchte Zugriffe auf die Netzlaufwerke. An sich kein Problem, nur nach mehreren Tagen steht auf einmal folgendes im Logbuch:
May 11 02:01:28 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:29 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:29 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:30 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:34 hwe-core7 kernel: __ratelimit: 4 callbacks suppressed
Wenn die Meldung im Logbuch steht, dann geht gar nichts mehr, und ich muss den Rechner hard resetten.
Leider habe ich zu diesem Problem nur Antworten für kleine Netzwerkrouter gefunden, und nicht für "richtige" Server. Beispielsweise steht schon in der nf_conntrack_max in Wert von 65536 (Suse default).
Hat jemand von euch dieses Problem auch schon gehabt? Kennt jemand werte für Timeouts, die besser funktionieren als die Standardeinstellungen?
Ein paar Werte sind:
nf_conntrack_udp_timeout 30
nf_conntrack_tcp_timeout_close 10
Welche Datei sollte man am Besten mitloggen, um den Verursacher zu finden? /proc/net/nf_conntrack liefert leider keine Uhrzeiten mit.
Danke und Gruß
_X_
Ich habe ein Problem mit meinem OpenSuse 11.1 64bit Server (Intel i7 12GB RAM):
Das Ding steht in einem Firmennetzwerk, in dem es nachts hoch her geht. In den Logbüchern stehen dutzende von DNS Anfragen, so wie versuchte Zugriffe auf die Netzlaufwerke. An sich kein Problem, nur nach mehreren Tagen steht auf einmal folgendes im Logbuch:
May 11 02:01:28 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:29 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:29 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:30 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:31 hwe-core7 kernel: nf_conntrack: table full, dropping packet.
May 11 02:01:34 hwe-core7 kernel: __ratelimit: 4 callbacks suppressed
Wenn die Meldung im Logbuch steht, dann geht gar nichts mehr, und ich muss den Rechner hard resetten.
Leider habe ich zu diesem Problem nur Antworten für kleine Netzwerkrouter gefunden, und nicht für "richtige" Server. Beispielsweise steht schon in der nf_conntrack_max in Wert von 65536 (Suse default).
Hat jemand von euch dieses Problem auch schon gehabt? Kennt jemand werte für Timeouts, die besser funktionieren als die Standardeinstellungen?
Ein paar Werte sind:
nf_conntrack_udp_timeout 30
nf_conntrack_tcp_timeout_close 10
Welche Datei sollte man am Besten mitloggen, um den Verursacher zu finden? /proc/net/nf_conntrack liefert leider keine Uhrzeiten mit.
Danke und Gruß
_X_