Сглючил utm5_radius

[sbbs]

версия УТМ - 008u3, радиус родной.
версия ОС - Centos5.3

Подвис радиус.
в логах pptp сервера периодически появлялись сообщения вида:
Feb 14 15:27:28 vpn1 pptp[19395]: rc_send_server: no reply from RADIUS server utm.comp.ru:1813
Feb 14 15:27:28 vpn1 pptp[19395]: Interim accounting failed for sena
Feb 14 15:27:28 vpn1 pptp[13635]: rc_send_server: no reply from RADIUS server utm.comp.ru:1813
Feb 14 15:27:28 vpn1 pptp[13635]: Interim accounting failed for masum
Feb 14 15:27:28 vpn1 pptp[26558]: rc_send_server: no reply from RADIUS server utm.comp.ru:1813
Feb 14 15:27:28 vpn1 pptp[26558]: Interim accounting failed for yuon

Лог самого радиуса:
?Debug : Feb 14 15:30:15 b605bb90 RadiusSocket: socket disconnect found, it's strange
?Debug : Feb 14 15:30:15 b605bb90 RadiusSocket: socket disconnect found, it's strange
?Debug : Feb 14 15:30:15 b605bb90 RadiusSocket: socket disconnect found, it's strange

На портах 1812 и 1813 только входящие пакеты.

Вылечилось перезагрузкой радиуса.
Случилось первый раз за долгое время работы с УТМ. Кто с таким раньше встречался?

[kaN5300]

версия УТМ - utm5-2.1.008-update4, радиус родной.
версия ОС - FreeBSD 7.4-STABLE
субд на отдельной тачке

У нас тоже вечером 14-го числа случилось одновременно несколько очень странных событий:

1) CPU на коммутатере ядра (онже bgp-роутер) резко подскочило
2) Два из шести серверов доступа сказали "пока!" и ушли в ребут
3) utm5_radius вдруг стал занимать всё процессорное время
4) Юзеры, которые соскочили с двух ушедших NAS не смогли полностью перелезть на оставшиеся насы, т.к. радиус в таком состоянии работал очень странно. Со стороны пользователя это выглядело так: коннект, 30-сек pptp сессия работает, потом дисконнект.

--

1) Логи не записали, было не до этого. А ротируются они с сумасшедшей скоростью.
2) Мы используем радиус-аккаунтинг параллельно с ip-аккаунтингом. interim_update_interval выставлен в 61.
3) Данная авария наступила примерно в 18:55.