Route hash chain too long! Adjust your secret_interval!

Столкнулись с такой проблемой, что OpenVZ ядра 164й ветки (точно: RHEL5 2.6.18-164.2.1.el5 028stab066.7 и RHEL5 2.6.18-164.2.1.el5 028stab066.10) виснут, сопровождая зависание вот такими логами:

Dec 18 00:15:03 CentOS-54-64-minimal kernel: Route hash chain too long!
Dec 18 00:15:03 CentOS-54-64-minimal kernel: Adjust your secret_interval!

Более подробно:

Dec 17 14:15:32 CentOS-54-64-minimal dhclient: parse_option_buffer: option time-offset (255) larger than buffer.
Dec 17 20:50:19 CentOS-54-64-minimal kernel: unregister_netdevice: waiting for venet0=ffff81023f457800 to become free. Usage count
= 3 ve=1730
Dec 17 20:50:50 CentOS-54-64-minimal last message repeated 3 times
Dec 17 20:51:00 CentOS-54-64-minimal kernel: unregister_netdevice: waiting for venet0=ffff81023f457800 to become free. Usage count
= 3 ve=1730
Dec 17 20:51:00 CentOS-54-64-minimal kernel: unregister_netdevice: device ffff81023f457800 marked to leak
Dec 17 20:51:00 CentOS-54-64-minimal kernel: free_netdev: device venet0=ffff81023f457800 leaked
Dec 17 20:51:00 CentOS-54-64-minimal kernel: neighbour leakage
Dec 17 20:51:00 CentOS-54-64-minimal kernel: CT: 1730: stopped
Dec 17 20:51:02 CentOS-54-64-minimal kernel: CT: 1730: started
Dec 18 00:15:03 CentOS-54-64-minimal kernel: Route hash chain too long!
Dec 18 00:15:03 CentOS-54-64-minimal kernel: Adjust your secret_interval!
Dec 18 01:15:20 CentOS-54-64-minimal syslogd 1.4.1: restart.

Сейчас откатились на 128 ядро (OpenVZ, 2.6.18-128.2.1) и тестируем на нем, пока, вроде, полет нормальный и сообщений о free/leak нету, как и зависаний.

Судя по поиску, обе строки из сабжа выдает функция rt_emergency_hash_rebuild из файла net/ipv4/route.c

Как и ожидалось, в ядре 2.6.18-128.2.1 ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/kernel-2.6.18-128.2.1.el5.src.rpm этой функции нету и никаких упоминаний строк из сабжа. Так что можно спать спокойно на 128 ядре :)

Сейчас проверю 164е: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/kernel-2.6.18-164.el5.src.rpm. Да, этот патч от RHEL 5.4 (O-Subject: [RHEL 5.4 PATCH]: allow for on demand emergency route cache flushing): linux-2.6-net-allow-for-on-demand-emergency-route-cache-flushing.patch, суть его сводится к следующему:

Several customer have pointed out that Linux has this periodic latency
resulting from us flushing the route cache. We do this purposefully, since we
don't want to use the same hash secret too long and risk having an attacker
flood our system with carefully selected packets, creating route cache entries
that all hash to the same value. It would be nice if we could, instead of
flushing every X seconds weather we need to or not, to flush only when we detect
that a chain in our hash table is growing suspiciously long.

Как я понял это переводится так: вместо использования раут хеша почти неограниченного размера (увеличивающегося при необходимости), мы перешли к хешу ограниченного размера, который увеличивается только тогда, когда наблюдается его "подозрительно" быстрый рост.

Ап! А вот что пишут на форуме опенвз (ссылка):

As a workaround downgrade to RHEL 5.3 based kernel or decrease your /proc/sys/net/ipv4/route/secret_interval value (default 600), but not too much.

But I hope that a permanent fix is on it's way.

Update: проблема исправлена 67.4 ядре http://wiki.openvz.org/Download/kernel/rhel5/028stab067.4

Update: проблема ВНОВЬ появилась в 194 серии ядер: http://bugzilla.openvz.org/show_bug.cgi?id=1611