Re: Непонятные RST
On Sun, Jul 14, 2013 at 07:55:46PM +0300, Hleb Valoshka wrote:
> Нет, дело не в айпишниках, я проверял.
>
> >> В результате, после изменения tcp_rmem на 4096 87380 1033696, всё
> >> работает
> > Значение tcp_rmem относится к размеру буферов для сокетов и не должно
> > иметь отношения к маршрутизации. Но оно может неявно влиять на размер
> > различных таблиц и значений хэшей, и потому вызывать спорадические
> > проявления багов.
>
> Не-а, вы не поняли, кажется, я изменил tcp_rmem на _клиенте_. Шлюз
> остался нетронутый. В том-то и прикол.
Прикол приколом, конечно, но... непонятно, что именно Вы пытались изменить.
Кроме размера окна клиента в заголовках пакетов ничего меняться не должно.
Коннекция находится в стадии разгона на максимальном MTU, ограничение
на размер буфера нигде не достигается (да и нет шлюзу дела до него),
поэтому у всех пакетов в последовательности должны в точности повторяться
размеры и данные.
Но если подозревать баги в контраке, где-то в области сопоставления
пакетов коннекции, то "хорошая" и "плохая" коннекции из присланных дампов
далеко не идентичны: различаются ip-шники и порты клиентов, а это значит,
что хэши для этих коннекций тоже будут отличаться. Если подозревается
ещё и порча памяти, то нельзя считать поведение шлюза детерминированным
и нужно набирать статистику отказов.
Думаю, что утверждение о корреляции бага с клиентским tcp_rmem может
быть ошибочным, а "прикол" -- случайным выбросом на малой статистике.
> Если симитировать на виртуалках удастся, то можно и покопать. А если
> нет, то гори оно гаром, обошёл, задокументировал, и ладно. Не сидеть
> же по ночам на работе?
Всё зависит от того, чего хочется достичь. :) Если понимания ситуации
и выработки правильной модели мира в голове -- это одно, если побыстрее
отбиться от проблемы любой ценой, даже через нелепое, непонятно каким
образом работающее "решение" -- это совсем другое.
--
Eugene Berdnikov
Reply to: