RADIUS-сервер и его параметры

[taf]

Господа нетаповцы, объясните, плз такой момент:

С каких это пор параметр radius_ippool_timeout задает время жизни сессии клиента? По описанию это:

## Description: A time interval during which the IP address is labeled as
## occupied after receiving Accounting-Start.

собственно, в документации написано то же самое. Если выставить этот таймаут в некое значение, меньшее чем interim_update_interval, то получаем забавный спецэффект - в отчетах по VPN-соединениями у нас на одного клиента будет набегать до 600-700 сессий. То есть по прохождению Interim-Update радиус закрывает существующую сессию в БД, выставив ей статус 3, и тут же создает новую запись с другим id но с тем же самым acct_session_id

на BRAS'е соединение как было, так и осталось.

Ребята, я понимаю у вас сейчас идет потребление прошлогоднего запаса грибов, но каким надо быть гением, чтобы назвать такое поведение НОРМОЙ?

Для чего пришлось выставлять этот несчастный параметр radius_ippool_timeout в весьма малые значения. А для того, чтобы в случае аварийного завершения работы BRAS'а, когда он в силу непреодолимых причин не смог отправить Accounting-Stop, клиент мог оперативно переподключиться на соседнем BRAS'е, а не безуспешно долбиться до interim_update_interval*3 секунд, засирая логи и добавляя нагрузку на саппорт. Адреса у нас клиентам присваиваются статично в сервисных связках.

[basker]

Присоединяюсь к вопросу. Так и не смог параметры при которых бы radius разрешал бы после перезагрузки BRAS'а сразу же поднимать сессии (даже если они были не закрыты корректно) и при этом сессии бы в логе не множились. Думал в 11-м апдейте исправят, а его всё нет и нет...

[taf]

Кое-что на воротник, а не фикс в 11-м. Саппорт сказал что "Это нормальное поведение в полном соответствии с настройками".

Кстати, юмор еще в том, что каким-то особой магией Stop-пакеты пролюбливаются самим utm5_radius, со всеми последтсвиями в виде невыдачи адреса и последующей долбежкой клиента длительностью до interim_update_interval.

Блин, почему в том же FreeRADIUS можно настроить чтобы такая ситуация разруливалась на раз-два: шлем в сторону предыдущей сессии Disconnect-ACK и создаем новую. Тут же цирк с понями вокруг черного ящика с неверно поименованными крутилками.