[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Непонятные RST



2013/7/10 Hleb Valoshka <375gnu@gmail.com>

>  Если правил больше одного, то интересно, где именно теряется тот
>  недоставленный клиенту пакет. Предлагаю включить трассировку для пакетов,
>  которые интересны (через iptables -t raw ... -j TRACE) и попытаться
>  понять, где ломается нормальная последовательность прохождения пакетов
>  по цепочкам iptables.

Итак, -j TRACE особенно не помог, т.е. он только паказал, что 6 и 7 пакеты уходят почемуто в INPUT вместо FORWARD, но не дал ответа на вопрос почему это происходит.

Коллеги были убеждены, что во всём виновата esx, и нужно перенести виртуалку на другой узел. Перенесли, ситуация чуть-чуть изменилась, т.е. если вначале проблема возникала в 98%, то после переноса, наверное, в 75%. Для проверки развернули ещё один squeeze, там RST летели чуть реже (может в 50% случаев).

Поставил ядро из squeeze-backports на проверочной виртуалке -- всё работает отлично.

Из явных различий: с ядром 2.6.32 window == 5840, с 3.2 == 14800. Но меньшее окно я ставил ограничивая скорость скачивания, и на моём wheezy это никак не влияло. Тем более, ядерных настроек для настройки размера окна не нашёл.

Записываю все настройки из /proc/sys/net/ipv4 под этими двумя ядрами, прогоняю diff, меняю настройки по одному и смотрю на поведение.

В результате, после изменения tcp_rmem на 4096 87380 1033696, всё работает (или, по крайней мере, частота обрывов уменьшилась до единиц %).

Прописываю это в sysctl.conf, reboot -- всё работает как надо.

На squeeze, установленом на "голое" железо, без "тюнинга" обрывы тоже есть, но с намного меньшей частотой -- 9 обрывов за 100 скачиваний, приэтом обрыв только один раз за сеанс, после первых 7 кб, в изначальной же виртуалке обрыв  был _каждые_ 7 кб.

По-дефолту у 2.6.32 net.ipv4.tcp_rmem = 4096 87380 4194304. "The third and last value specified in this variable specifies the maximum receive buffer that can be allocated for a TCP socket." Т.е. чем больше, тем должно быть лучше, а тут наоборот.

А ещё более непонятно, почему пакету уходили в INPUT на шлюзе, при этом только 6-й и 7-й, после них все проходили нормально, и даже их копии, посланные из-за ретрансмита.

Я ничего не понимаю.

Reply to: