ACCT_TERMINATE_CAUSE 3 : Lost-Service

ran
Сообщения: 2298
Зарегистрирован: Вс окт 21, 2007 2:29 pm

Re: ACCT_TERMINATE_CAUSE 3 : Lost-Service

Сообщение ran »

Получается, что случайным образом (особенно при неуверенном покрытии сети) от юзера не приходят алайвы, биллинг закрывает его сессию с ACCT_TERMINATE_CAUSE=Lost-Service
та не... если по причине сбоев сети теряются LCP echo request/replay то радиусклиент посылает радиуссерверу стоп пакет с ACCT_TERMINATE_CAUSE=Lost-Carrier (при этом разумеется прибивая туннель) и сессия закрывается корректно... тут дело не в этом... тут именно теряется связь между радиуссервером и радиусклиентом... конечный усер здесь абсолютно ни причём

ЗЫ: и проблема здесь собсно не в абиллсе а в протоколе обмена радусклиента с радиуссервером... это UDP протокол а значит без гарантированной доставки... получается что при потере связи между радисклиентом и радиуссервером радиусклиент не знает, получил ли сервер алайв или нет... и продолжает держать поднятый туннель (у негото всё пучком)... и слать алайвы (в никуда)... а сервер их не получает и рвёт сессию по лост-сервис... мдя... неаккуратненько... и броться с этим похоже невозможно (такой протокол) :(

ЗЫ2: хотя нет... я думаю на уровне абиллса можно организовать каким-то образом посылку "подтверждений" от сервера клиенту на принятый алайв... чото мне так кажется ;)

ЗЫ3: о! выход есть!!! просто абиллс при обрыве сессии по лост-сервис должен сделать (так на всякий случай) хенгап этого усера и тада будет всё пучком :D
Любой тупик - это тщательно замаскированный выход.

Dozz
Сообщения: 63
Зарегистрирован: Пт окт 10, 2008 9:30 am
Откуда: Киев
Контактная информация:

Re: ACCT_TERMINATE_CAUSE 3 : Lost-Service

Сообщение Dozz »

ran писал(а):
Получается, что случайным образом (особенно при неуверенном покрытии сети) от юзера не приходят алайвы, биллинг закрывает его сессию с ACCT_TERMINATE_CAUSE=Lost-Service
та не... если по причине сбоев сети теряются LCP echo request/replay то радиусклиент посылает радиуссерверу стоп пакет с ACCT_TERMINATE_CAUSE=Lost-Carrier (при этом разумеется прибивая туннель) и сессия закрывается корректно... тут дело не в этом... тут именно теряется связь между радиуссервером и радиусклиентом... конечный усер здесь абсолютно ни причём

ЗЫ: и проблема здесь собсно не в абиллсе а в протоколе обмена радусклиента с радиуссервером... это UDP протокол а значит без гарантированной доставки... получается что при потере связи между радисклиентом и радиуссервером радиусклиент не знает, получил ли сервер алайв или нет... и продолжает держать поднятый туннель (у негото всё пучком)... и слать алайвы (в никуда)... а сервер их не получает и рвёт сессию по лост-сервис... мдя... неаккуратненько... и броться с этим похоже невозможно (такой протокол) :(

ЗЫ2: хотя нет... я думаю на уровне абиллса можно организовать каким-то образом посылку "подтверждений" от сервера клиенту на принятый алайв... чото мне так кажется ;)

ЗЫ3: о! выход есть!!! просто абиллс при обрыве сессии по лост-сервис должен сделать (так на всякий случай) хенгап этого усера и тада будет всё пучком :D
Вот это доступно объяснил! Спасибо большое, ran! Теперь ясна суть проблемы. остается выяснить почему может теряться связь между радиус-клиентом и радиус-сервером, если оба эти демона запущены на одной машине. Не может ли быть, что радиуссервер (freeradius 1.1.7) отбрасывает пакеты от клиента при большой загрузке (например, если запустить сервер в однопоточном режиме)?

ran
Сообщения: 2298
Зарегистрирован: Вс окт 21, 2007 2:29 pm

Re: ACCT_TERMINATE_CAUSE 3 : Lost-Service

Сообщение ran »

Не может ли быть, что радиуссервер (freeradius 1.1.7) отбрасывает пакеты от клиента при большой загрузке
может... проверено! но дело даже не в этом... с этим можно бороться ;)

я просто хочу обратить внимание Автора на это
ran писал(а):абиллс при обрыве сессии по лост-сервис должен сделать (так на всякий случай) хенгап этого усера и тада будет всё пучком
Любой тупик - это тщательно замаскированный выход.

Dozz
Сообщения: 63
Зарегистрирован: Пт окт 10, 2008 9:30 am
Откуда: Киев
Контактная информация:

Re: ACCT_TERMINATE_CAUSE 3 : Lost-Service

Сообщение Dozz »

NiTr0 писал(а):
Dozz писал(а):Acct-Interim-Interval - это ж время, через которое биллинг делает пересчет статистики пользователя, инициированное радиусом. Разве оно как-то связано с алайв-пакетами, которые клиент обязуется посылать каждые 60 (в данном случае) секунд для оповещения сервера о своем присутствии. Исправьте меня, если я неправ.
Acct-Interim-Interval - это атрибут, передаваемый радиус-клиенту. Который как раз и указывает, как часто клиент будет слать алайв-пакеты.
Поле алайв - только для биллинга актуально, клиент о его существовании даже не подозревает ;)
Совсем я запутался.

У меня в настройках mpd5 есть такие строчки:

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

radius:
    set auth acct-update 300
...
pptp:
    set link keep-alive 30 120
    load radius
...
"acct-update 300" - это есть параметр Acct-Interim-Interval, который инициирует каждые 300 сек аккаунтинг конечного юзера. Но кем? Действительно ли клиентом, как утверждается, а не НАСом посредством передачи радиус-сервером НАСу этой радиус-пары? - не верю! :)

А вот "link keep-alive 30 120" - это как раз инструкция НАСу посылать алайв-запросы (LCP echo request/replay, о которых писал ran) с периодичностью в 30 сек, а при неполучении алайв-ответа в течении 120 сек сбрасывать юзера с линии.

Параметр же Alive (он же NAS_ALIVE) в билинге присутсвует лишь для скрипта billd, который по крну запускается и проверяет сессии. Если какие-либо подвисли на время большее, чем NAS_ALIVE*ERROR_ALIVE_COUNT, то сессия переноситься в ZAP (Lost Alive), если же ответа нет больше чем 2*NAS_ALIVE*ERROR_ALIVE_COUNT, то сессия обрывается с ошибкой "Error: Session Calculate".

Что верно, а что, как говорил ran, "тришечки не так"? Помогите разобраться ху із ху.

NiTr0
Сообщения: 767
Зарегистрирован: Пт фев 08, 2008 4:46 pm

Re: ACCT_TERMINATE_CAUSE 3 : Lost-Service

Сообщение NiTr0 »

Dozz писал(а):"acct-update 300" - это есть параметр Acct-Interim-Interval, который инициирует каждые 300 сек аккаунтинг конечного юзера. Но кем? Действительно ли клиентом, как утверждается, а не НАСом посредством передачи радиус-сервером НАСу этой радиус-пары? - не верю! :)
Кто задаст этот интервал - конфиг mpd или нас - без разницы.
Dozz писал(а):А вот "link keep-alive 30 120" - это как раз инструкция НАСу посылать алайв-запросы (LCP echo request/replay, о которых писал ran) с периодичностью в 30 сек, а при неполучении алайв-ответа в течении 120 сек сбрасывать юзера с линии.
Да, только это называется не алайв-запросы, а эхо-запросы, подобие пинга. Которые никакого отношения к "вышестоящим инстанциям" не имеют, и о существовании которых биллинг даже и не подозревает.
Dozz писал(а):Параметр же Alive (он же NAS_ALIVE) в билинге присутсвует лишь для скрипта billd, который по крну запускается и проверяет сессии. Если какие-либо подвисли на время большее, чем NAS_ALIVE*ERROR_ALIVE_COUNT, то сессия переноситься в ZAP (Lost Alive), если же ответа нет больше чем 2*NAS_ALIVE*ERROR_ALIVE_COUNT, то сессия обрывается с ошибкой "Error: Session Calculate".
Не совсем так. Если биллинг не получал NAS_ALIVE*ERROR_ALIVE_COUNT времени Alive-пакеты (они же аккаунтинг-пакеты) от наса - он помещает сессию в зап. Что у вас и получилось с вашим конфигом.

Dozz
Сообщения: 63
Зарегистрирован: Пт окт 10, 2008 9:30 am
Откуда: Киев
Контактная информация:

Re: ACCT_TERMINATE_CAUSE 3 : Lost-Service

Сообщение Dozz »

NiTr0 писал(а):
Dozz писал(а):А вот "link keep-alive 30 120" - это как раз инструкция НАСу посылать алайв-запросы (LCP echo request/replay, о которых писал ran) с периодичностью в 30 сек, а при неполучении алайв-ответа в течении 120 сек сбрасывать юзера с линии.
Да, только это называется не алайв-запросы, а эхо-запросы, подобие пинга. Которые никакого отношения к "вышестоящим инстанциям" не имеют, и о существовании которых биллинг даже и не подозревает.
Вот в этом и была моя ошибка - считал, что алайв пакетами называются в том числе и LCP пакеты. Спасибо за разъяснение!

Ответить