FreeRadius + pppoe + Simultaneous-Use

Там есть отдельный запрос simul_count_query для этой проверки. Он выполняется ?

И потом, если сервер доступа всего один, может той же самой цели можно добиться настроив его?

Если закинуть его в SQL - выполняется, я получаю сount(*) только это не мешает пользователям повторно логиниться.

На 7204 то ли прошивка старая , то ли что еще , там про pppoe вообще ни слова. Могу скинуть настройки интерфейсов, и.т.п, что конкретно надо? У меня по link там только для multippp есть ограничение на кол-во линий...

Romka_Kharkov, ну там еще в десятке мест можно ошибиться. отладка и анализ кода и ничего больше.

проверь еще что Simultaneous-Use := 1 действительно подгребается из ранних этапов и модуль sql указан в блоке session { }, что на поздних этапах идет обработка этого атрибута.

я стараюсь в эту гадость больше не погружаться. может и нельзя. к конце концов, у кого циско на аватаре?

гугл говорит, что нужно использовать group-policy и vpn-simultaneous-logins .

В session {} указан sql, при этом Radutmp отключен вовсе. С базой вроде бы все в порядке.. Странная особенность проблемы заключается в том, что в radacct сессия для клиента одна, а вот "sh users | in username" показывает нуу.. допустим 5-6 :D Причем из них 3-4 адреса пингаются даже... т.е явно на линии....

Simultaneous-Use := 1 , вот это где указывать? Я почитал доки когда пишут в "users", я описал там:

DEFAULT NAS-IP-Address == x.x.x.x, Pool-Name := poolname
        Fall-Through = Yes

DEFAULT Simultaneous-Use := 1
        Fall-Through = Yes

Пробовал аналогичную штуку только Group="groupname" и следом в radgroupreply запись.... тоже не помогло, пробовал в radreply даже добавлять "Simultaneous-Use := 1" для конкретного клиента..... нифига вообще :D :D :D Но теперь у меня возник уже другой вопрос как же произошло так что сессия пингается и в онлайне а о ней нет записи в радиусе? Либо !!! как я вижу по логам , эта сессия была закрыта, на радиусе я получил сигнал "Release IP", т.е на сколько я понимаю 7204 сообщила радиусу о том, что такая-то сессия завершилась... Если подтвердить это логом - все есть.... т.е выглядит весь процесс так:

1) смотрю в терминале sh users, выясняю все интерфейсы по его логину, делаю clear для всех, все ушли с линии, мои радиусы получили "окончание сессии" и сделали "Release IP"

2) жду пару минут...

3) далее последовательность: Login OK / Release IP / Login Ok.... и так несколько раз.... (например 5), в итоге я получаю 5 сесий по этому клиенту в радиусе, 4 из которых закрыты, а 1 открыта и она последняя судя по логу авторизации......

4) Но при этом !!!!! в терминале 7204 продолжают светиться в sh users поднятые интерфейсы для этих клиентов..... и они даже пингаются в некоторых случаях.

У меня такое впечатление , что 7204 засылает какие-то ложные пакеты на радиусы \ либо получает их сама от l2tp upstream.

Интересно, что может быть на стороне клиента такого, что могло бы pppoe Устанавливать во много потоков... ? У них DSL Modems / Routers.... Выглядит как будто клиент из одного места физического рождает 3-4-5 подключений... Как-то так....

Да вот в том то и дело что у меня ))) сижу голову ломаю , уже долго.... :)

По идее, в users, но это если файл "подбирается" вместе с SQL и не конфликтует. Ну можете и в SQL выдать этот атрибут на всякий случай.

Может на этот IP уже другой вошел?

Вообще, как и что происходит видно в довольно подробной отладочной информации. Из логов можно даже пакеты воссоздать, имитировать работу сервера доступа с помощью radiusclient. Копайте и докопаетесь. В конфигурации с одним радиусом случайно не становится лучше ?

Для более надежного учета сессии я помнится включал обновления раз в минуту, но это ведь повышенная нагрузка на радиус. Нужно это было исключительно чтобы радиус и бд спокойно переживали перезагрузку, либо длительное пропадание связи.

Есть multilink ppp, но это экзотика. Они не смогут его настроить.

Скорее там кто-то быстро жмет разъединение и быстро переподключается.

Да знаю про клиент, все понятно, тут и пробую, но могу и клиента какогонить на реконект послать, суть особо не меняется.

Нет, при выключении любого из радиусов оставшийся работает так же, т.е никаких проверок не выполняется или выполняются но без необходимого результата.

Это вы сейчас о каком параметре?

Multilink PPP у меня отдельные клиенты есть и у них все работает, вот ту есть настройка в Template для MLPP Bundle на самой 7204... там у меня стоит не более 4х и не менее 2х клинтов, те у кого 2 линии нормально поднимают мультилинк, с ними вопросов вообще пока что нет, вопросы с обычными PPPOE клиентами....

Насчет "быстро переподключиться" согласен, но почему в таком случае на самой 7204 сессия продолжает быть активной и мало того, пингуется и мало того, байтики на интерфейсе бегут.....

Я вот за последний час анализа выяснил что у меня такие по какой-то причине происходит "accounting_stop_query", т.е те IP адреса которые были выданы конкретному клиенту и до сих пор висят на циске уже в радиусе помечены как "завершенные сессии" протяженностью 1-2 минута..... то есть по факту, 7204 отправляет STOP пакет на Radius и радиус по честному делает UPDATE в radacct, только вот не ясно или условие не совпадает какое-то или как же так, вот привожу пример:

       accounting_stop_query = " \

          UPDATE ${acct_table2} SET \

             acctstoptime       = '%S', \

             acctsessiontime    = '%{Acct-Session-Time}', \

             acctinputoctets    = '%{%{Acct-Input-Gigawords}:-0}' << 32 | \

                                  '%{%{Acct-Input-Octets}:-0}', \

             acctoutputoctets   = '%{%{Acct-Output-Gigawords}:-0}' << 32 | \

                                  '%{%{Acct-Output-Octets}:-0}', \

             acctterminatecause = '%{Acct-Terminate-Cause}', \

             acctstopdelay      = '%{%{Acct-Delay-Time}:-0}', \

             connectinfo_stop   = '%{Connect-Info}' \

          WHERE acctsessionid   = '%{Acct-Session-Id}' \

          AND username          = '%{SQL-User-Name}' \

          AND nasipaddress      = '%{NAS-IP-Address}'"

В частности:

          WHERE acctsessionid   = '%{Acct-Session-Id}' \

По идее уникальная для каждого соединения.

иду в SQL, делаю Select:

Фактически Одна открытая сессия согласно радиусу, иду на 7204

В действительности один из этих коннектов соответствует сессии которая в radacct (сверяю по IP), теперь я беру иделаю clear interface для интерфейса который НЕ СОВПАДАЕТ с radacct, т.е для интерфейса для которого нет открытой сессии в radacct.

Моя сессия которая описана выше , закрывается !!! какого хрена в общем-то? если совсем другой IP/ID ?!?!?? А вместо нее клиент видимо переконекчивается обратно на линию и я уже получаю новую сессию:

При этом , старая сессия остается на 7204 висеть как ни в чем не бывало + новая сессия вот с новым IP.

Вот что это за мазафака, может ли мне мой Upstream слать какой-то мусор о клиентах который моя 7204 могла бы расценить как STOP Пакеты или что-то в этом роде, как думаете?

---------- Добавлено 17.04.2012 в 21:21 ----------

Еще одно умозаключение приведу, если разобраться в сути проблемы, то в момент вторичной авторизации RAdius должен открыть вторую сессию в SQL, таким образом мой Select по racacct где стоптайм =0 должен выдавать мне >1 строки..... так как сессий больше, но вот как-то это не происходит, у клиента в radacct вроде как всегда 1 запись, отсюда наверное и Simul не срабатывает в принципе? Что-то меня совсем запутало это дело все...

Еще б я команды зубрил. Там можно включить отправку пакетов аккаунтинга не только для начала и конца сессии, но и в середине. Только это позволяет надежно работать с перегруженным сервером доступа или радиусом или сетью.

По всему остальному - поздравляю. Добавить больше нечего, кроме как советовать делать проще. Или взять готовый биллинг, который все эти проблемы на практике отладил и порешал.

Вся работа цисковода и заключается в поиске глюков софта, переписке с сапортом, тестированием новых иосов и тд. Собственно поэтому я ее и не люблю.

Вот я уже в очереди за иосом встал посвежее :) Но не думаю что в этом проблема.... У меня конечно не в простое железка стоит , но 50-60% постоянной нагрузки для cisco не должно быть проблемой, ладно бы там у меня 99% фигачило постоянно ..... так и не такие глюки отловить можно :D

P.S: Еще кто-то может что-то сказать по теме, а то она как и ряд других в интернете останется без решения и ответа.... а хотелось бы найти таки решение или разобраться в проблеме как минимум.

netwind - может дело как-раз в обработке сессий, или просто не контролируются ?

Логически предположить, если включен Simultaneous-Use := 1 = а подключаются более одного значит либо Alive пакеты не обрабатываются вовсе , либо пакет не обрабатывается о попытке подключения нового клиента. сверяя старую сессию, активную.

Romka_Kharkov - ещё включи у радиуса дебуг и покажи ( файлом выложи )