[[-Alt-]]

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

[apog]

В продолжение разговора о скриптах добавлю своих предложений, возможно ктото присоединится к моему пожеланию. С Романом мы немного обсудили его разработку, он обещал добавить в свой сервер возможность использования скриптов.

Вобщем вот как я представляю себе что мне требуется от сервера:

Имеем: Биллинг UTM5 в составе которого есть radius сервер умеющий работать с "правильными" cisco-NAS'ами (описание работы их встроенного radius сервера можно почитать здесь хотя я думаю, что логика работы там стандартная). На доступе d-link des-3526 с включенным dhcp-релеем.

Задача: при поступлении от абонента запроса на получение настроек от dhcp сервера инициировать сессию по протоколу radius, в качестве имени пользователя/пароля передавать сведения из option 82 (или как вариант передавать эти сведения в атрибуте Calling-Station-Id), затем получить от radius сервера Framed-IP-Address и остальные необходимые атрибуты (маска, шлюз, ДНС серверы) и передать их абоненту по dhcp. Также (как мне кажется) можно использовать Session-Timeout в качестве лиз-тайм. В случае пропадания абонента (не продляет лизу) инициировать завершение сессии по radius протоколу. В случае неудачной авторизации (от radius'а получен Access-Reject) - просто игнорировать запрос абонента.

Есть немного другой вариант - это когда все настройки для абонента берутся db2dhcp сервером из собственной базы данных, абоненту они выдаются после того, как пройдет авторизация по radius, но для того, чтобы возможно было считать биллингом трафик нужно по протоколу radius в атрибуте Framed-IP-Address передать биллингу выдаваемый абоненту адрес. С точки зрения биллинга это будет выглядеть как будто NAS выдал адрес абоненту из собственного пула, а не запросил его у radius сервера.

Не знаю как с остальными биллингами, (имеем только UTM5, с ним и пытаемся воевать), но в UTM5 возможность динамического назначения адреса абоненту реализована исключительно для случая работы с их radius сервером. Существует конечно много всяких костылей, например популярно решение создания конфиг-файла для isc-dhcp сервера, но в этих решениях абоненту привязывается статический адрес. Вот здесь рецепт. Или вот здесь описано решение с использованием option 82.

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

Речь о скриптах потому, что это все не обязательно впихивать в сервер db2dhcp. Достаточно будет только возможности реализовать это используя скрипты совместно с db2dhcp сервером, к тому же это будет наиболее универсальное решение. Комуто ведь такое и не надо, Ктото сможет в конце концов свои скрипты приладить, вобщем думаю это очевидно и без моих комментариев.

Изменено 25 мая, 2011 пользователем apog

[RomanCh]

Согласен, но ей далеко не по барабану, как часто это делается. В случае выполнения тяжёлого запроса одним из клиентов БД, дополнительные маленькие запросы DHCP в этот момент могут тупо уложить сервак БД на несколько минут (может и дольше), нагрузка на проц будет возрастать по экспоненте, вы сами можете себе представить вероятные последствия этого.

Включённый кэш спасёт ваш умучанный тяжкими трудами sql сервер :) Из личного опыта могу сказать что один не шибко мощный сервер без особых вопросов обслуживает порядка 10к клиентов без особых напрягов если включено кэширование. При этом он ещё и другими делами занимается.

 

А напрямую в базу... Да, красиво - поменяли мак, сразу перевыдалось... Но стоит ли? Мне как то проще использовать стандартный демон, чем писать свое ;)

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

 

' timestamp='1303757210' post=608972]

минус пока тока один, нужна поддержка в сервере резервного линка к базе.

Да, это обязательно будет доработано.

 

В продолжение разговора о скриптах добавлю своих предложений, возможно ктото присоединится к моему пожеланию

Да, было бы интересно подумать кто что хочет видеть.

 

Лично я вижу это так:

1. Скрипты могут быть pre/post типов. Т.е. запускающиеся перед выполнением запроса в БД и после запроса.

2. Выполнение скриптов может быть синхронным и асинхронным. Код возврата выполнения асинхронных скриптов не учитывается, код возврата выполнения синхронных скриптов может учитываться и на основании его может быть принято решение делать или нет запрос в БД (что-нибудь ещё может?)

3. В скрипты могут быть переданы статические параметры (задано в конфиге) и динамические - те же переменные что используются в запросах.

Изменено 26 мая, 2011 пользователем RomanCh

[apog]

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

[RomanCh]

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

Вообще-то изначально задумывалось именно как сервер работающий с СУБД. А получается правда какой-то комбайн если все пожелания выполнить :) Если скрипты только оставить - откуда данные серверу брать?

А поддержку скриптов как правильно вкрутить - подумаю, может и на этапе конфигурирования, хотя по сути там же всё будет на стандартных библиотеках, так что это не так актуально как с поддержкой БД.

а универсальный dhcp сервер.

Ну, вообще-то "универсального" изначально не задумывалось.

[apog]

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

[RomanCh]

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

[alexaaa]

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

[alexaaa]

Я как понял разработчик тестирует его на дебианах, а возможно создать дебиановский файл установочный?, и ещё вопрос а как допустим он будет общаться с базой биллинга если она на другом сервере? а dhcp и его база на другой машине

[zoro]

сВ продолжение разговора о скриптах добавлю своих предложений, возможно ктото присоединится к моему пожеланию. С Романом мы немного обсудили его разработку, он обещал добавить в свой сервер возможность использования скриптов.

Вобщем вот как я представляю себе что мне требуется от сервера:

Имеем: Биллинг UTM5 в составе которого есть radius сервер умеющий работать с "правильными" cisco-NAS'ами (описание работы их встроенного radius сервера можно почитать здесь хотя я думаю, что логика работы там стандартная). На доступе d-link des-3526 с включенным dhcp-релеем.

Задача: при поступлении от абонента запроса на получение настроек от dhcp сервера инициировать сессию по протоколу radius, в качестве имени пользователя/пароля передавать сведения из option 82 (или как вариант передавать эти сведения в атрибуте Calling-Station-Id), затем получить от radius сервера Framed-IP-Address и остальные необходимые атрибуты (маска, шлюз, ДНС серверы) и передать их абоненту по dhcp. Также (как мне кажется) можно использовать Session-Timeout в качестве лиз-тайм. В случае пропадания абонента (не продляет лизу) инициировать завершение сессии по radius протоколу. В случае неудачной авторизации (от radius'а получен Access-Reject) - просто игнорировать запрос абонента.

Эх, такое решение я просил года тому назад чтобы наконец реализовать выдачу динамических ип адресов из пула... Нету такого биллинга которые давали DHCP серверу динамические адреса, есть только по радиусу... Если еще выполнение внешних скриптов будет вложено то я так думаю многие бы перешли на DHCP-Radius

[Dark3]

Всем кому это интересно предлагаю ознакомиться с подробной документацией, собрать сервер и помочь в тестировании: <a советы по ремонту

Было бы неплохо увидеть готовые пакеты для системы. =) А то собирать не всегда удобно.

Изменено 9 июля, 2011 пользователем Dark3

[s.lobanov]

Применение opensource в ISP зачастую требует умений собирать из сырцов, накладывать патчи и пересобирать... Привыкайте.

 

И перечитайте ещё раз первый пост:

Огромная просьба: пока статус кода дико тестовый (об этом написано в документации) - стараться не пиарить на популярных ресурсах (типа опеннета, хабры и т.д.) и не пытаться делать порты/пакеты для включения в дистрибутивы. Не хочется слишком активно делиться со всем миром потенциально проблемным (а местами немного не доделанным) кодом. Да и доку надо английскую ещё написать...

[GFORGX]

Ещё раз привет!

 

Начал пытаться засунуть в продакшн, есть одна небольшая проблема. Мне кажется, было бы логичнее, если бы DHCP-сервер не обращался к базе, если в запросе содержатся переменные, которые не удалось извлечь. Можно ли такое реализовать?

Изменено 19 июля, 2011 пользователем GFORGX

[Minya]

что слышно насчет версии с поддержкой выполнения внешних скриптов?

[GFORGX]

что слышно насчет версии с поддержкой выполнения внешних скриптов?

У меня фактически пропала необходимость, хотя я изначально и реквестил - несколько пересмотрена за то время схема сети была.

 

P.S. По теме - аптайм уже около 2 недель, не падает, около 7 сегментов по 15-20 человек посадил на него.

[deepweb]

вам удалось указать несколько DNS серверов?

[alexaaa]

а как конфигурировать этот сервер при dhcp relay option 82 по vlan id, нам при vlan на абонента проще использовать vlan id

[shafiev]

Вы свою проблему как решили ?

[j@x]

Доброго времени суток.

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

Хочу узнать как обстоят дела у автора с развитием проекта, есть ли время и силы продолжать разработку/поддержку и довести начатое до конца? Вроде бы тут мелькали планы до нового года ipv6 запилить,но как вообще развивается проект понятно мало (может кто подскажет где это посмотреть?). От себя могу предложить активное участие в тестировании,благо есть где, на чем и на ком опробовать и небольшие промахи там простительны (:

[GFORGX]

Доброго времени суток.

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

Хочу узнать как обстоят дела у автора с развитием проекта, есть ли время и силы продолжать разработку/поддержку и довести начатое до конца? Вроде бы тут мелькали планы до нового года ipv6 запилить,но как вообще развивается проект понятно мало (может кто подскажет где это посмотреть?). От себя могу предложить активное участие в тестировании,благо есть где, на чем и на ком опробовать и небольшие промахи там простительны (:

Относительно IPv4 - всё работает великолепно, у нас в продакшне на половине сети сейчас (примерно 5 тыс. пользователей). MySQL. Огромное спасибо автору за его труд.

Изменено 16 сентября, 2011 пользователем GFORGX

[piston]

Чтобы знать, когда кто-то придет поддержка ip-up и ip-down скрипты

будет полезна для ограничения скорости пользователей.

[silitra]

В сервере есть несколько багов, которые автор планирует пофиксить глубокой осенью.

1) некорректная работа с клиентами с выставленным Broadcast флагом.

2) в пакетах отсутствует opt82 в случае /renew. при первом Discover опция есть.

[GFORGX]

2) в пакетах отсутствует opt82 в случае /renew. при первом Discover опция есть.

При чём тут сервер-то?

[Artem_1]

В сервере есть несколько багов, которые автор планирует пофиксить глубокой осенью.

1) некорректная работа с клиентами с выставленным Broadcast флагом.

2) в пакетах отсутствует opt82 в случае /renew. при первом Discover опция есть.

От себя добавлю +1 глюк:

В Юникаст ответах почему-то подставляется MAC адрес клиента вместо MAC адреса шлюза. ( в случае ответа L3 клиенту)

[DMiTRONiK]

2) в пакетах отсутствует opt82 в случае /renew. при первом Discover опция есть.

В новых прошивках для свитчей D-Link уже заявлена поддержка добавления Opt82 в unicast пакетах. На днях собираюсь проверить как это работает на практике.