Это да. Если каждый юзер в умный свитч воткнут отдельно. А если нет?.. И как "управлять доступом" админам частных ресурсов? По каждому бану звонить провайдеру и просить узнать что такого-то числа во столько-то накакал на его форуме?.. А потом просить его залочить?Arti писал(а):Управлять доступом нужно на порту свича. Т.е. клиент однозначно идентифицируется парой айди свича (обычно ip адрес) порт свича.
Например баланс ушел в ноль - дальше "личного кабинета" пользователь не уйдет, даже к соседу в этом же доме.
Напишу полноценный DHCP сервер работающий с SQL СУБД.
RomanCh, вы напишите DHCP-Server с хранением лизов, параметров пользователя в БД, будет просто супер. Как вы наверное уже поняли, очень многие нуждаются в подобном решении.
Авторизация абонентов: Opt82 и MAC, это достаточно, в любом случае других вариантов практически нет. Разумеется нужно предусмотреть возможность работы без привязки к Opt82 или MAC (например для публичных сетей).
очень пригодилось бы, наличие информации о том, когда последний раз клиент (по id свитча + порт или MAC) обращался к DHCP.
Ну и главное на мой взгляд, предусмотреть возможность самому писать SQL запросы для получения необходимых параметров для работы сервер DHCP. Данная фишка позволит адаптировать сервер практически к любому биллингу.
Авторизация абонентов: Opt82 и MAC, это достаточно, в любом случае других вариантов практически нет. Разумеется нужно предусмотреть возможность работы без привязки к Opt82 или MAC (например для публичных сетей).
очень пригодилось бы, наличие информации о том, когда последний раз клиент (по id свитча + порт или MAC) обращался к DHCP.
Ну и главное на мой взгляд, предусмотреть возможность самому писать SQL запросы для получения необходимых параметров для работы сервер DHCP. Данная фишка позволит адаптировать сервер практически к любому биллингу.
Т.е. обычный динамический пул? Ну это само собой подразумевается.AndrewE писал(а):Разумеется нужно предусмотреть возможность работы без привязки к Opt82 или MAC (например для публичных сетей).
Это тоже обязательно. Как в логах сервера, так и в БД.AndrewE писал(а): очень пригодилось бы, наличие информации о том, когда последний раз клиент (по id свитча + порт или MAC) обращался к DHCP.
На мой взгляд в любом случае придётся унифицировать ответы сервера БД. Т.е. выдавать их в формате аналогичном формату RADIUS БД: первая колонка - код опции, вторая - значение опции. На сколько я понимаю - это можно будет сформировать на любой БД.AndrewE писал(а): Ну и главное на мой взгляд, предусмотреть возможность самому писать SQL запросы для получения необходимых параметров для работы сервер DHCP. Данная фишка позволит адаптировать сервер практически к любому биллингу.
Сами SQL-запросы разумеется задаются пользователем.
Кстати кто что думает на тему IPv6? Я так полагаю что поддержку надо хотя бы заложить в обязательном порядке. Вроде как недолго IPv4 жить осталось.
ну мб в dhcpd.confRomanCh писал(а): На мой взгляд в любом случае придётся унифицировать ответы сервера БД. Т.е. выдавать их в формате аналогичном формату RADIUS БД: первая колонка - код опции, вторая - значение опции. На сколько я понимаю - это можно будет сформировать на любой БД.
Сами SQL-запросы разумеется задаются пользователем.
сделать что -то типа такого:
sql_get_client_params = "SELECT ... as client_ip, ... as client_netmask, ... as client_gateway FROM... WHERE ...."
т.е. SQL запросы к БД должны быть настраивамые с возвратом предопределеных полей. Разумеется в качестве примера, можно сделать демонстрационную БД с примерами запросов к ней.
IPv4 осталось жить еще минумум лет 10, но основу для IPv6 заложить конечно нужно.RomanCh писал(а): Кстати кто что думает на тему IPv6? Я так полагаю что поддержку надо хотя бы заложить в обязательном порядке. Вроде как недолго IPv4 жить осталось.
Если я могу чем-то помочь, пишите на shicoy () mail.ru
т.е. можем помочь с разработкой web-admin для DHCPd, проектированием DB, тестированием.
Не не, думаю это как раз не верное решение. Теоретически мы можем в БД закладывать десятки параметров для клиентов. И динамически изменять их число. Следовательно придётся каждый раз лезть в конфиг и изменять его. Помоему надо придеживаться концепцииAndrewE писал(а): сделать что -то типа такого:
sql_get_client_params = "SELECT ... as client_ip, ... as client_netmask, ... as client_gateway FROM... WHERE ...."
т.е. SQL запросы к БД должны быть настраивамые с возвратом предопределеных полей. Разумеется в качестве примера, можно сделать демонстрационную БД с примерами запросов к ней.
Код: Выделить всё
SELECT option_id, option_value FROM ...
Спасибо, буду иметь ввиду. Сообщу как только будет что-нибудь мало-мальски рабочее.AndrewE писал(а): Если я могу чем-то помочь, пишите на shicoy () mail.ru
т.е. можем помочь с разработкой web-admin для DHCPd, проектированием DB, тестированием.
Ещё всплыл вопрос. В каких обычно форматах передаются опции 82 различными моделями устройств? Совершенно очевидно что парсинг 82й опции так же нужно делать настраиваевым. Хочется увидеть возможные варианты представления этих опций в разных моделях сетевого оборудования от различных вендоров.
Ну в патче к dhcpd как раз это и реализовано. Без кэша сервер конечно начал бы загинаться достаточно быстро. Непосредственно запрос к БД идёт только в случае получения DHCPDISCOVER.JAO писал(а):Включайте кэш запросов, тогда не загнется. В этом случае обращений на чтение в разы больше чем на запись. А когда так, есть смысл включить кэш.
Это ИМХО какой-то совсем странный путь решенияJAO писал(а): Если конечно база не считывается целиком в память по факту ее изменения. Тогда единственное что может загнуться - это сам dhcpd.
Тем не менее шустро будет бегать. Когда давят запросами, начинается пора оптимизаций типа кто быстрее - тот и тащит. Быстрее обычно оказывается оперативка, медленнее - диск. Чем больше обращений в оперативку и чем меньше на диск - тем лучше, большую нагрузку выдержит. Это верно как для однопроцессорных машин, так и для SMP. Чем шустрее отдельные ноды в кластере, тем лучше. Поэтому появились memcached, nginx, буферизация чтения-записи и много тому подобного.
Именно потому и организовано кэширование запросов но на уровне DHCP протокола, а не полного дампа БДJAO писал(а):Тем не менее шустро будет бегать. Когда давят запросами, начинается пора оптимизаций типа кто быстрее - тот и тащит. Быстрее обычно оказывается оперативка, медленнее - диск. Чем больше обращений в оперативку и чем меньше на диск - тем лучше, большую нагрузку выдержит.
Это и правильно. Но в том посте имелся в виду кэш запросов MySQL, я его включаю везде, где запросов на чтение больше чем на запись. Тогда фактическое обращение к базе идет только если была в нее запись, а так все летит из кэша. Если же нет гарантии, что какой-то конкретный движок БД (или сервер) умеет кэшировать запросы, то лучше нечто свое слепить.