3 необычных кейса о сетевой подсистеме Linux

[tgz]

> net.ipv4.tcp_tw_recycle = 1

Я бы за таое выписал леща. Почитайте почему с 4.12 этого параметра нет в ядре.

[acmnu]

Я бы за таое выписал леща.

К сожалению другого выхода иногда нет. Это дешевый способ, не переписывая ПО заставить его работать с большим количеством исходящих соединений.

[acmnu]

Для начала у меня для вас плохие новости:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4396e46187ca5070219b81773c4e65088dac50cc

А во-вторых, на сколько я помню tcp_tw_reuse требует поддержки в ПО: нужно использовать другую функцию открытия соединения.

[gserge]

Это хорошие новости. Потому что мы его в своих проектах выключаем. Нет, reuse не требует какого-то специального механизма работы с сокетами.

[badc0de]

По поводу tcp_tw_recycle, думаю стоит обратить внимание на вот эту статью https://habr.com/ru/company/flant/blog/332432/

и возможно поправить приведенные в статье параметры sysctl в самом конце.

[gserge]

Я посмотрел статью, там нет никакого внятного объяснения, зачем включают tcp_tw_recycle, просто включили и все. Кроме того, его просто таки нет в новых ядрах уже два года.

[EvilMan]

По-моему, диагностику лучше всего начинать с просмотра статистики через nstat -az. В кейсе 1 сразу можно было бы увидеть инкрементирование счётчика TcpExtIPReversePathFilter (количество отброшенных rp_filter-ом пакетов), а в кейсе 2 — TcpExtTCPTimeWaitOverflow. Третий кейс интересный, и я когда-то тоже натыкался на это ограничение по-умолчанию на сервере, который работал с кучей мультикаст групп.

[Oakum]

Словить третий кейс проще некуда, vpn концентратор с ospf на каждом туннеле, суммарно 60 клиентов, перезапуск ospfd, и чудеса с соседями гарантированы.

[EvilMan]

Хуже всего, что никаких метрик на этот случай не предусмотрели. Отловить источник проблемы можно лишь догадавшись, почему такое странное ограничение (20), или через запуск strace на процессе, который лишь покажет, что setsockopt с опцией IP_ADD_MEMBERSHIP по какой-то причине возвращает ошибку ENOBUFS.

[gserge]

Не совсем так. В sysctl.conf нужно прописать для всех устройств, в том числе для тех, которые не существуют во время загрузки (например, различные VPN). А скрипт позволяет сделать динамически эту штуку.

[gserge]

А это для всех вновь созданных и для всех во время загрузки. А на ходу у текущих интерфейсов не сменит.

[EvilMan]

Есть одна особенность, которая не позволяет отключить данным образом rp_filter. Дело в том, что применяется значение max(all, <iface>), т.е. если у вас в конфиге интерфейса net.ipv4.conf.${iface}.rp_filter = 1, а net.ipv4.conf.all.rp_filter = 0, то для интерфейса будет использоваться значение rp_filter = 1. Правильнее не отключать rp_filter совсем, а использовать так называемый loose-режим, который смягчает правила rp_filter, и будет отбрасывать пакеты лишь в том случае, если до источника этих пакетов вообще нет маршрута. Если же маршрут до источника есть, но он не совпадает с интерфейсом, на который пришли пакеты, то они всё равно будут пропущены, а не отброшены, как при rp_filter = 1 (strict-режим).

[EvilMan]

Используется именно MAX, а не AND. При проверке используется макрос IN_DEV_RPFILTER, который в свою очередь использует макрос IN_DEV_MAXCONF, который уже использует макрос max. У переменных sysctl подобная логика может различаться. Для уточнения лучше читать либо документацию, либо исходники.

[htol]

А где тут хоть что-то необычное? Хотя конечно молодцы что разобрались, но ощущения больше такие, что документацию изначально ни кто не читал.
1. В любом учебнике.
2. В общем-то тоже. И в RFC нет рекомендаций 2-х минут. Там по умолчанию часов 8 было, а 2 минуты для MSL просто как пример приводили.
3.

Снова углубились в чтение документации, где и был обнаружен параметр ядра igmp_max_memberships, который ограничивает количество multicast-соединений для одного сокета

К сокету он отношения не имеет, даже если вы видите socket error 105. Параметр означает количество мультикаст групп к которым может подключится хост.