Neighbour table overflow (не могу сам победить...)

[blackdevil]

Добрый день! Недавно заметил, что в логах сервера под управлением Debian 5.0 Lenny сыпятся сообщения вида:

$ sudo cat /var/log/messages | tail
Feb 8 16:46:50 mail kernel: [476696.977847] __ratelimit: 27 messages suppressed
Feb 8 16:46:50 mail kernel: [476696.977852] Neighbour table overflow.
Feb 8 16:46:55 mail kernel: [476702.172754] __ratelimit: 56 messages suppressed
Feb 8 16:46:55 mail kernel: [476702.172759] Neighbour table overflow.
Feb 8 16:47:00 mail kernel: [476707.271076] __ratelimit: 24 messages suppressed
Feb 8 16:47:00 mail kernel: [476707.271081] Neighbour table overflow.
Feb 8 16:47:05 mail kernel: [476712.679283] __ratelimit: 35 messages suppressed
Feb 8 16:47:05 mail kernel: [476712.679283] Neighbour table overflow.
Feb 8 16:47:10 mail kernel: [476717.887373] __ratelimit: 36 messages suppressed
Feb 8 16:47:10 mail kernel: [476717.887373] Neighbour table overflow.

Не уверен, проявлялась ли проблема раньше...кажется, что нет. Копания в гугле показали, что есть 2 способа решения проблемы.
1) В списке рассылки дебиан советовали проверить, запущен ли loopback интерфейс. У меня запущен и все с ним в порядке:

Код: Выделить всё

$ sudo ifconfig
eth0      Link encap:Ethernet  HWaddr 00:17:31:82:95:04
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.0.0
          inet6 addr: fe80::217:31ff:fe82:9504/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:246260073 errors:0 dropped:0 overruns:0 frame:0
          TX packets:135115460 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2704355337 (2.5 GiB)  TX bytes:899494124 (857.8 MiB)
          Interrupt:17 Base address:0xd000

eth1      Link encap:Ethernet  HWaddr 00:50:22:b1:33:ac
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.0.0
          inet6 addr: fe80::250:22ff:feb1:33ac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2969630 errors:0 dropped:0 overruns:0 frame:0
          TX packets:552105 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:433243240 (413.1 MiB)  TX bytes:75079360 (71.6 MiB)
          Interrupt:22 Base address:0xd400

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3525869 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3525869 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2624806149 (2.4 GiB)  TX bytes:2624806149 (2.4 GiB)

Правда, смущает большой трафик через lo:

Код: Выделить всё

RX bytes:2624806149 (2.4 GiB)  TX bytes:2624806149 (2.4 GiB)

После обновления ядра сервер в работе:

Код: Выделить всё

$ uptime
 16:55:49 up 5 days,  1:28,  5 users,  load average: 0.06, 0.10, 0.09

По сути не так уж и много за 5 дней...
2) на linuxquestions.org советовали увеличить размер каких-то буферных файлов с использованием файловой системы /proc, что так же не дало результата.

На машине настроен pptp сервер для 20 клиентов, джаббер сервер, почтовик, файлопомойка через самбу. Нагрузки существенной нет никакой...Кто знает, с чем могут быть связаны подобные сообщения ядра? Может, это какой-то баг? Или просто кто-то сталкивался с такой же проблемой на Lenny...?

[Pchol]

Переполнение арп таблицы.
Проверьте количество записей в таблице, в тот момент когда сыпятся ошибки
arp -an | wc -l
Как самый простой вариант решения:
echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 8192 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

[blackdevil]

Спасибо, кажется, уже решил проблему. На внутреннем сетевом интерфейсе была маска 255.255.0.0 и рядом стоящий сервер с win2000 по непонятной мне причине начал кидать броадкастом arp-запросы - у кого какой мак адрес, причем спрашивал по порядку, даже для несуществующих узлов...А при такой маске узлов ого-го сколько...Поменял маску, пока все спокойно...
Ксати, способ с увеличением gc_thresh, как я уже писал выше, не помогал.