☰

„nf_conntrack: Tabelle voll, Paket wird gelöscht“, obwohl nf_conntrack_count viel kleiner ist als nf_conntrack_max

tag-icon • tag-icon iptables conntrack
„nf_conntrack: Tabelle voll, Paket wird gelöscht“, obwohl nf_conntrack_count viel kleiner ist als nf_conntrack_max

Ich habe einen Knoten in unserem Cluster, der viele „nf_conntrack: Tabelle voll, Paket wird gelöscht“-Meldungen im Syslog erhält. Ich habe den nf_conntrack_count überprüft und er war genau im Vergleich zum nf_conntrack_max. Als ich mir die Tabelle ansah, sah ich, dass die meisten Einträge DNS-Anfragen waren, also habe ich diese Regeln zur „rohen“ Netfilter-Tabelle hinzugefügt.

$ sudo iptables -t raw -vnL
Chain PREROUTING (policy ACCEPT 146M packets, 19G bytes)
pkts bytes target     prot opt in     out     source               destination
33M 4144M CT         udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:53 CT notrack
33M 2805M CT         udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 CT notrack
Chain OUTPUT (policy ACCEPT 73M packets, 8311M bytes)
pkts bytes target     prot opt in     out     source               destination         
10785  882K CT         udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 CT notrack
0     0 CT         udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:53 CT notrack

Der Zähler liegt nun bei etwa 13000 und nf_conntrack_max ist auf 65535 eingestellt. Ich erhalte jedoch weiterhin die Meldung „Paket verworfen“. Die meisten anderen Pakete sind UDP und ich habe nf_conntrack_udp_timeout auf 1 Sekunde eingestellt, sodass der nf_conntrack_count bei etwa 1000 liegt. Ich erhalte jedoch weiterhin die Meldung „Paket verworfen“.

Wenn ich von hier aus den Höchstwert erhöhe, werden die gelöschten Paketmeldungen gestoppt, ich sehe jedoch nicht, warum das notwendig ist.

Ich verwende Docker und es gibt einen Elasticsearch-Container (dieses Problem scheint auf jedem Knoten aufzutreten, auf dem Elasticsearch ausgeführt wird). Ich bin nicht sicher, ob es relevant ist, aber der Knoten hat 48 Kerne.

$ uname -a
Linux qtausc-pphd0128 3.19.0-26-generic #28~14.04.1-Ubuntu SMP Wed Aug 12 14:09:17 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Warum werden also Pakete gelöscht, wenn die Anzahl weit unter dem Maximum liegt?

Antwort1

Ich hatte vor einiger Zeit dasselbe Problem auf einem Squid-System.

Eine der effektivsten Möglichkeiten, die Größe des Conntracks zu reduzieren, bestand meiner Meinung nach darin, das standardmäßige TCP-Timeout im Kernel zu reduzieren.

Der net.netfilter.nf_conntrack_tcp_timeout_establishedStandardwert ist 432000. Das stimmt... das sind 5 Tage.

Um den Wert festzulegen, können Sie den folgenden Befehl eingeben:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=X

Und wenn die Änderung dauerhaft sein soll, müssen Sie die Zeile hinzufügen /etc/sysctl.conf.

Nachdem dieser Wert auf 600 reduziert wurde, ging die Conntrack-Anzahl einige Tage lang stetig zurück.

Ich habe sysctl net.netfilter.nf_conntrack_maxund verwendet sysctl net.netfilter.nf_conntrack_count, um die Werte zu erhalten.

verwandte Informationen