On Fri, Jul 12, 2013 at 05:33:42PM +0300, Hleb Valoshka wrote: > Итак, -j TRACE особенно не помог, т.е. он только паказал, что 6 и 7 пакеты > уходят почемуто в INPUT вместо FORWARD, но не дал ответа на вопрос почему > это происходит.
Если все цепочки, которые проходятся пакетами перед INPUT/FORWARD, дают идентичные части трассы, то это великолепный результат, который другими способами вряд ли было бы возможно получить... Видно, что бага скорее всего в трэкере коннекций, в том месте, где принимается решение о маршрутизации. > Коллеги были убеждены, что во всём виновата esx, и нужно перенести > виртуалку на другой узел. Перенесли, ситуация чуть-чуть изменилась, т.е. > если вначале проблема возникала в 98%, то после переноса, наверное, в 75%. > Для проверки развернули ещё один squeeze, там RST летели чуть реже (может в > 50% случаев). > > Поставил ядро из squeeze-backports на проверочной виртуалке -- всё работает > отлично. Видно, что проблема "плавающая". Изменение поведения при переносе в другую среду виртуализации, или при изменении нагрузки -- картина, характерная для проблем управления памятью (неинициализированные переменные и т.п.). Дублирование виртуалки связано, наверное, с применением других ip-адресов на клоне, что наверняка приводит к изменению значений хэшей. Думаю, бага где-то в области вычисления хэшей контрака. Со времён 2.6.32 Эрик несколько раз что-то там лопатил, но я не вникал и деталей не помню. В 2.6.32 был какой-то неприяный баг в tcp_output(), из-за которого нельзя было держать это ядро на нагруженных серверах. Для роутинга оно вроде было пригодно... > В результате, после изменения tcp_rmem на 4096 87380 1033696, всё работает > (или, по крайней мере, частота обрывов уменьшилась до единиц %). ... > По-дефолту у 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." Т.е. чем больше, тем должно быть > лучше, а тут наоборот. Значение tcp_rmem относится к размеру буферов для сокетов и не должно иметь отношения к маршрутизации. Но оно может неявно влиять на размер различных таблиц и значений хэшей, и потому вызывать спорадические проявления багов. > А ещё более непонятно, почему пакету уходили в INPUT на шлюзе, при этом > только 6-й и 7-й, после них все проходили нормально, и даже их копии, > посланные из-за ретрансмита. > > Я ничего не понимаю. Чтобы понять, нужно копать глубже. Обработка копии пакета иным образом может быть вызвана спорадической порчей памяти, неинициализированными переменными и прочим. Если есть время, желание и навыки для ковыряния в коде ядра -- всё можно выяснить... Если нет, ставьте ядро поновее и работайте дальше. Для содержательного общения с netdev'ом лучше всего иметь горячую версию ядра из git'a. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
