Pull to refresh

Comments 9

Да. Контрек дорого. Особенно, в ядре. Потому у нас и есть conntrackd. Но state — всё равно дорого и никуда вы от этого не денетесь.

conntrackd тут ничем не помогает — его единственная функция — репликация состояний в кластере файрволлов, он не может больше чем может сам netfilter в ядре. Ещё умеет делать flush и статистику — всё.

Он лучше в том смысле, что просмотр статистики не фризит трафик (как в случае попытки посмотреть в ядерные proc-файлы для conntrack).


А стейт — дорого. У всех. Даже у топовых srx'ов есть вполне себе лимиты на число wing (половинка flow).

Несмотря на слово «соединение», это всё касается и UDP тоже: привет приложениям, которые любят спрашивать «где myapp.tld» 500 раз в секунду или отправлять логи через GELF over UDP каждый раз с нового порта.

icmp тоже касается. Отключение контрека для высоконагруженных udp/icmp — это первое дело.

Не просто касается, а именно udp как раз и есть основная масса соединений, живущих до истечения таймаута. Соединения stateful протоколов грохаются сразу при обнаружении корректного закрытия соединения участниками, так что тот же tcp остаётся висеть только если никто не соизволил хотя бы FIN отправить. Что, само собой, вообще неправильно.
Поэтому странно читать про многогигабайтный conntrack, который никак не удавалось побороть. Ну перешли бы на tcp, благо memcached умеет.


Also постоянное упоминание Calico создаёт впечатление того, что это прямо его уникальная фича. На мой взгляд, можно было хотя бы вскользь упомянуть, что iptables/nftables тоже умеют conntrack для указанного трафика не задействовать.

Автор оригинала - сотрудник Tigera (создатели Calico), так что вполне резонно с их стороны держать в фокусе именно их CNI.

Вроде nftables лет 5 как актуален, а статьи о iptables продолжают клепать с завидным постоянством.

Чего там в nftables с conntrack и как с ним работать? Ж) Ну и с nfset до кучи
Там то же механизм ядра для него используется
Sign up to leave a comment.