☰

"nf_conntrack: tabela cheia, descartando pacote" mesmo que nf_conntrack_count seja muito menor que nf_conntrack_max

tag-icon • tag-icon iptables conntrack
"nf_conntrack: tabela cheia, descartando pacote" mesmo que nf_conntrack_count seja muito menor que nf_conntrack_max

Eu tenho um nó em nosso cluster que recebe muitas mensagens "nf_conntrack: tabela cheia, descartando pacote" no syslog. Eu verifiquei o nf_conntrack_count e ele estava funcionando contra o nf_conntrack_max. Olhando para a tabela, vi que a maioria das entradas eram solicitações de DNS, então adicionei essas regras à tabela "bruta" do netfilter.

$ 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

Isso deixou a contagem oscilando em torno de 13.000 ou mais, e nf_conntrack_max está definido como 65535. No entanto, ainda continuo recebendo mensagens de pacotes descartados. A maioria dos demais pacotes são UDP, e eu defino o nf_conntrack_udp_timeout para 1 segundo, deixando o nf_conntrack_count em torno de 1000. No entanto, ainda recebo a mensagem compactada descartada.

A partir daqui, se eu aumentar o máximo, isso interromperá as mensagens de pacotes descartadas, mas não vejo por que isso é necessário.

Estou executando o docker e há um contêiner elasticsearch (esse problema parece acontecer em qualquer nó que esteja executando o elasticsearch). Não tenho certeza se é relevante, mas o nó possui 48 núcleos.

$ 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

Então, por que está descartando pacotes quando a contagem é muito menor que o máximo?

Responder1

Eu tive o mesmo problema há algum tempo em um sistema Squid.

Uma das maneiras mais eficazes que encontrei para reduzir o tamanho do conntrack foi reduzir o tempo limite padrão do TCP no kernel.

O net.netfilter.nf_conntrack_tcp_timeout_establishedestá definido como 432000 por padrão. Isso mesmo... são 5 dias.

Para definir o valor você pode emitir o seguinte comando;

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=X

E se você quiser que essa mudança seja persistente, você precisa adicionar a linha em /etc/sysctl.conf.

Depois de reduzir esse valor para 600, a contagem do conntrack diminuiu continuamente ao longo de alguns dias.

Eu usei sysctl net.netfilter.nf_conntrack_maxe sysctl net.netfilter.nf_conntrack_countpara obter os valores.

informação relacionada