«nf_conntrack: таблица заполнена, пакет отбрасывается», хотя nf_conntrack_count намного меньше nf_conntrack_max

«nf_conntrack: таблица заполнена, пакет отбрасывается», хотя nf_conntrack_count намного меньше nf_conntrack_max

У меня есть узел в нашем кластере, который получает много сообщений "nf_conntrack: table full, dropping packet" в syslog. Я проверил nf_conntrack_count, и он был вплотную к nf_conntrack_max. Заглянув в таблицу, я увидел, что большинство записей были DNS-запросами, поэтому я добавил эти правила в "сырую" таблицу 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

Это оставило счетчик около 13000 или около того, а nf_conntrack_max установлен на 65535. Однако я все еще получаю сообщения о потерянных пакетах. Большинство остальных пакетов — UDP, и я установил nf_conntrack_udp_timeout всего на 1 секунду, оставив nf_conntrack_count около 1000. Однако я все еще получаю сообщение о потерянных упакованных пакетах.

Если я увеличу максимум, это остановит отбрасывание сообщений о пакетах, однако я не понимаю, зачем это нужно.

Я запускаю docker, и есть контейнер elasticsearch (эта проблема, похоже, возникает на любом узле, на котором запущен elasticsearch). Не уверен, относится ли это к делу, но у узла 48 ядер.

$ 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

Так почему же пакеты теряются, если их количество намного меньше максимального?

решение1

Некоторое время назад у меня была такая же проблема в системе Squid.

Одним из наиболее эффективных способов уменьшения размера conntrack, который я нашел, было уменьшение тайм-аута TCP по умолчанию в ядре.

По умолчанию установлено net.netfilter.nf_conntrack_tcp_timeout_establishedзначение 432000. Все верно... это 5 дней.

Чтобы установить значение, вы можете выполнить следующую команду:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=X

И если вы хотите, чтобы это изменение было постоянным, вам нужно добавить строку в /etc/sysctl.conf.

После снижения этого значения до 600 количество conntrack-ов неуклонно снижалось в течение нескольких дней.

Я использовал sysctl net.netfilter.nf_conntrack_maxи sysctl net.netfilter.nf_conntrack_countдля получения значений.

Связанный контент