“nf_conntrack: tabela cheia, perdendo pacote” mesmo que nf_conntrack_count seja muito menor que nf_conntrack_max

Question

Eu tenho um nó em nosso cluster que recebe muitas mensagens "nf_conntrack: table full, soltando pacotes" no syslog. Eu verifiquei o nf_conntrack_count e ele estava correndo 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 de filtros de rede "brutos".

$ 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 pairando em torno de 13000 ou mais, e nf_conntrack_max está definido como 65535. No entanto, continuo recebendo as mensagens de pacotes descartados. A maior parte do restante dos pacotes é UDP, e eu configuro o nf_conntrack_udp_timeout tão baixo quanto 1 segundo, deixando o nf_conntrack_count por volta de 1000. No entanto, eu ainda recebo a mensagem que está solta.

A partir daqui, se eu aumentar o max, ele irá parar as mensagens de pacotes descartados, no entanto, 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 estiver executando o elasticsearch). Não tenho certeza se é relevante, mas o nó tem 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 do que a máxima?

    

Answer 1

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

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

Por padrão, o net.netfilter.nf_conntrack_tcp_timeout_established está definido como 432000. É 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 a alteração seja persistente, adicione a linha a /etc/sysctl.conf .

Depois de reduzir esse valor para 600, a contagem de conntrack foi diminuindo gradualmente ao longo de alguns dias.

Não sei como você verificou as configurações de contagem e máx. da tabela conntrack, mas usei sysctl netfilter.nf_conntrack_max e sysctl net.netfilter.nf_conntrack_count para obter os valores.