From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3F9C519D.5060104@yauza.ru> Date: Mon, 27 Oct 2003 01:58:37 +0300 From: "Pavel S. Khmelinsky" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030710 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: community@altlinux.ru X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: [Comm] kernel: Neighbour table overflow. X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: community@altlinux.ru List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 22:58:37 -0000 X-List-Received-Date: Sun, 26 Oct 2003 22:58:37 -0000 Archived-At: List-Archive: List-Post: Тут недавно после подключения к серверу еще одного интерфейса с кучей пользователей в логи начало сыпаться примерно следующие: kernel: Neighbour table overflow. Клиентов порядка 400 все они статически и жестко привязываются к своим макам командой: ip nei replace to $ip lladdr $mac dev eth2 nud permanent Причем делает это скрипт, который периодически перезапускается. Причем чем чаще его перезапускать тем быстрее с момента загрузки начинает сыпаться эта дрянь. Пробовал вопросить в kernel-devel -- не вышло. Сложилось ощущение что ответ знают почти все, но в воспитательных целях молчат %) Возился и так и сяк, прочитал все что нашел про настройки /proc которые могли бы повлиять на размер арп таблицы.... Кароче пошел на крайнюю меру -- полез в ядро и вот до чего довело мое небольшое расследование: Есть такая структура: net/ipv4/arp.c: struct neigh_table arp_tbl = { family: AF_INET, entry_size: sizeof(struct neighbour) + 4, .... gc_thresh3: 1024, }; Дошел я до нее по цепочке: net/ipv4/route.c:rt_intern_hash -> net/ipv4/arp.c:arp_bind_neighbour -> include/net/neighbour.h:__neigh_lookup_errno -> net/core/neighbour.c:neigh_create -> net/core/neighbour.c:neigh_alloc там есть код сравнения gc_thresh3 и entries, дальше глянул где задается это значение. При создании новой записи (neigh_create ф-ия) вызывается ф-ия neigh_alloc в которой есть проверка tbl->entries > tbl->gc_thresh3 т.е. сравнивается кол-во существующих записей с этим самым числом. Хотя есть и другие проверки и кандитаты в возможные причины появления сообщения kernel: Neighbour table overflow. мне почему-то кажется что срабатывает именно эта проверка...... И что? Да ничего gc_thresh3: 1024 и все. Константа.... Ни тебе выхода в #define ни в /proc .... 1024 роста на растоянии прямой видимости (имеется ввиду в одном физическом эзернет сегменте) это чего предел что-ли?! Вобщем гуру, развейте мои сомнения скажите что я где-то чего-то недоконфигурил или еще чего-то. Следующим шагом будет пересборка ядра, а делать мне это на боевых серверах ой как не охота а нигде более это дело у меня не проявляется. P.S.: Интересно... А у бзди такие проблемы есть?