Непонятная ситуация с l4-redirect-on-reject

Questions related to general functionality
Post Reply
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Непонятная ситуация с l4-redirect-on-reject

Post by KovAl »

Конфигурация - только IPoE.
Использую функционал l4-redirect-on-reject в процедуре регистрации нового оборудования абонента.
Т.е. если абонент подключает к сети новую железку, радиус его не авторизует и отправляет Reject в accel.
Последний выдаёт IP из пула "незарегистрированных" (l4-redirect-ip-pool=guest).
Далее этот IP iptables DNAT-ом заворачивает на страницу с необходимой информацией.
Всё красиво, но...
Если вдруг радиус просто НЕ отвечает (тупо упал), accel переводит ВСЕХ активных абонентов в статус "не зарегистрированных",
выдавая им IP из "гостевой" подсети.
Соответственно ВСЕ абоненты видят сообщение, что им необходимо произвести регистрацию нового оборудования,
что естественно не соответствует действительности.
Вопрос - почему так? Почему accel считает полное отсутствие отклика от радиуса равным его ответу "Reject"?
В mpd5 например, такая ситуация (падение радиуса) не создаёт глобальных проблем.
В этом случае активные абоненты продолжают работать, отказывает только регистрация новых подключений.
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: Непонятная ситуация с l4-redirect-on-reject

Post by dimka88 »

Добрый день, в секции [radius] есть параметр

Code: Select all

acct-timeout=n
Specifies timeout of accounting interim update.
Если в течении этого времени радиус не ответит, то сессия завершается. Можете поставить 0 для отключения данного функционала (будет как в случае с MPD5), но таким образом могут возникнуть другие нюансы, на стороне биллинга (типо на NAS сессия есть, а в биллинге нет)
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Re: Непонятная ситуация с l4-redirect-on-reject

Post by KovAl »

dimka88 wrote: 19 Sep 2018, 09:55 Добрый день, в секции [radius] есть параметр

Code: Select all

acct-timeout=n
Specifies timeout of accounting interim update.
Есть такое - acct-timeout=30
dimka88 wrote: 19 Sep 2018, 09:55 Если в течении этого времени радиус не ответит, то сессия завершается. Можете поставить 0 для отключения данного функционала (будет как в случае с MPD5), но таким образом могут возникнуть другие нюансы, на стороне биллинга (типо на NAS сессия есть, а в биллинге нет)
Это как раз не проблема. После прихода первого алива в биллинг, тот сделает reopened by ALIVE "пропавшей" сессии.
Вот если наоборот - на NAS-е уже нет сессии, а в биллинге она почему-то присутствует как активная (бывает такое) - тогда она переходит в статус "зависшей". Но это ТОЛЬКО в биллинге и это проблема только для одного, максимум нескольких клиентов, а не для ВСЕХ, как в данном случае.
И это тоже решается на стороне биллинга.
А вот то, что происходит в случае с accel - это совсем не хорошо, т.к. проблема из "одиночной" переходит в "массовую"..
Кстати.. В mpd5 есть такой параметр - set radius timeout 30. Это случаем не тоже самое что и acct-timeout=30 ?
Похоже, что оно самое. Однако, как я уже писал, в случае с mpd, падение радиуса не приводит к массовому переводу клиентов в другой статус.
В mpd он тоже присутствует. Правда, не по reject, а по отсутствию framed IP при авторизации.
mpd вообще не замечает его (радиуса) отсутствия. И я считаю, это правильно. NAS не должен реагировать на отсутствие радиуса.
Нет его (радиуса) - ну и Бог с ним - работаем дальше, появился - будем работать.
ИМХО, в accel этот алгоритм (работа с радиусом) неверный..
Или я всё же ошибаюсь? И возможность настроить нужное поведение accel имеется?
Post Reply