Jump to content
Калькуляторы

DHCP server with SQL support on Perl DHCP сервер с базой SQL на Perl, с опцией 82, маршрутами и прочим

Если вот эта строка:

IP: 192.168.239.1 (00:0e:aa:4b:eb:bf) > 255.255.255.255 (00:15:aa:64:50:00)

тогда уходит на мак шлюза самой системы =)

Можно ли это поправить?

 

added:

Попытался сам найти - безуспешно...

 

added:

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

dhcpd.txt

Edited by BlackSnow

Share this post


Link to post
Share on other sites

Самое простое поднять релей агента, хоть на том же самом компе, для связи использовать 127.0.0.1

Share this post


Link to post
Share on other sites

dhcpdump -i lo0

Ignored non IPv4 packet: 4416

 

dhcrelay em0 127.0.0.1 -d

Forwarded BOOTREQUEST for 00:0c:ff:ab:32:0f to 127.0.0.1

 

tcpdump -i lo0

19:58:25.152925 IP localhost.bootps > localhost.bootps: BOOTP/DHCP, Request from 00:0c:ff:ab:32:0f (oui Unknown), length 300

19:58:25.185842 IP localhost.bootps > 192.168.239.1.bootps: BOOTP/DHCP, Reply, length 300

 

./dhcpd.pl -b 127.0.0.1 -v 2 -id 127.0.0.1

[07/Nov/2011 20:04:40] Sending response to = 192.168.239.1:67 length = 300

 

Так что не очень получается =(

Совсем не хочется L3 свитч искать для релея =)

Share this post


Link to post
Share on other sites

id - должен указывать реальный адрес, на который клиенты будут слать запросы на продление аренды и тп.

Share this post


Link to post
Share on other sites

id - должен указывать реальный адрес, на который клиенты будут слать запросы на продление аренды и тп.

Все равно Ignored non IPv4 packet: 4416... :'(

Share this post


Link to post
Share on other sites

Давайте более подробно что вводите, куда и что вылазит.

Share this post


Link to post
Share on other sites

Ну я же чуть выше написал что как запускаю и что вылазит =)

По поводу "Ignored non IPv4 packet: 4416" - не исключаю что это dhcpdump глючит на интерфейсе lo0.

Сам сервер, видимо, работает нормально.

Правда, в логе dhcrelay не видно чтоб до него доходили reply...

Значит, может, сервер какие то не верные ответы отправляет, которые relay просто не воспринимает?

С другой стороны dhcpdump на интерфейсе lo0 не может расшифровать и запрос на получение.

Прикладываю полный ответ сервера...

 

Может, все же есть возможность поменять dst mac на ff::ff, мне кажется это все проблемы решило бы на много быстрей =)

dhcpd.txt

Edited by BlackSnow

Share this post


Link to post
Share on other sites

По идее можно, но сокет должен быть броадкастовым.

Share this post


Link to post
Share on other sites

Может вы поделитесь тем, что у вас получится?)

В архиве:

dhcp.sql - база без данных (структура).

/lib/dhcp-perl/ - сам скрипт на перле + вспомогательные скрипты (импорт-экспорт, очистка логов). Запускать по крону или по необходимости. Очищаются логи старше 30 дней.

/var/www/ - веб-морда. Там-же скрипт для выуживания маков (get_arp, в скрипте принято, что управляющая подсеть 10.156.0.0/16, используются для автоматического заполнения MAC адресов свичей в веб-формах).

/etc/init.d/ - скрипт start/stop/restart в стандартном формате для Debian. В начале управляющие переменные с комментариями.

 

По поводу структуры данных.

Т.к. время от времени приходится свичи менять, пришлось ввести сущность "Расположение свича" - таблица locations.

В результате, при смене свича достаточно изменить одну запись в базе - соответствие расположение-свич.

В каждой таблице (кроме логов) поле "Примечание" уникальное. Если делать фильтрацию по примечанию, то поиск по части строки.

Мы приняли у себя примечание - улица-дом-подъезд (свич или расположение) или улица-дом-квартира (клиент).

В результате поиск "k81-" дает все свичи/расположения/клиенты дома k81. (k - проспект Комсомольский)

 

В самом перл скрипте жестко задано время аренды адреса - 1 час, переменная $dhcp_lease_time. Можно задать свое значение.

Также в скрипте жестко заданы 2 DNS сервера (192.168.1.249 и 192.168.1.250) и сервер времени 192.168.1.242 - поставьте свои.

 

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

Поиск во всех формах регистро-независимый, формат MAC адреса свободный (разделители - точка, двоеточие, тире; регистр любой).

При вводе MAC адрес преобразуется в нижний регистр, разделители двоеточие, сообщение.

Клиент задается по расположению и порту. Дополнительно, можно указать MAC клиента (если не указан, то игнорируется).

Если указан MAC клиента, то IP выдается только этому MAC.

 

Логируются только запросы. Иногда полезно - узнать, а запрашивает-ли клиент. Возможна фильтрация по MAC/IP свича/клиента, по ID VLAN, по имени клиента (что клиент сообщает).

 

При заполнении данных везде контролируется формат MAC и IP. Если неверный, то сообщение. Если удалось преобразовать к верному формату, что сообщение + в форме получившееся значение. Запись данных только если введенные значения в правильном формате.

 

В свойствах клиента параметр "Отключен". Если пусто (или 0), то IP выдается. Если 1, то демон не отвечает.

 

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

 

Данный демон работает уже более 3 месяцев. На данный момент обслуживает порядка 500 клиентов. Проблем (кроме вышеназванной) не выявлено.

 

PS. Доступ к базе - localhost, dhcp, dhcp.

PPS. Работает на Debian-5.

dhcp-perl.zip

Edited by Инкогнито

Share this post


Link to post
Share on other sites

Спасибо что отписались и выложили результаты своих трудов!

Share this post


Link to post
Share on other sites

Приветствую!!

Интересует данная разработка для внедрения в сети порядка 5к хостов.

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

За ранее благодарен за ответы.

Share this post


Link to post
Share on other sites

Резервирование - поднимайте сколько хотите, единственное что они должны одно и тоже отдавать (либо вы должны сами обрабатывать ситуацию когда n dhcp серверов выдало юзеру n адресов, а юзер выбрал из них какой то). Для дхцп наличие нескольких серверов нормальная практика.

 

Попробуйте по ветке поискать, точных цифр уже не помню, у меня упиралось в производительность самой бд, если без неё вроде было 1000+ на селероне 3400, и несколько тысяч запросов/секунду на Е5300.

 

 

Share this post


Link to post
Share on other sites

Перечитал тему не нашел...

Хотелось бы уточнить на какой БД работало и в чем был упор?

Share this post


Link to post
Share on other sites

MySQL не держал столько запросов в секунду сколько выдавала утилита которой тестил. Когда без него, чтобы посмотреть насколько сам код в перле быстро исполняется, то упирался в проц.

 

Самое тяжёлое, ИМХО, это обработка запросов на сервере MySQL.

 

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

 

 

Share this post


Link to post
Share on other sites

По поводу статистики.

В данный момент, 2 таких сервера (см. мой пост выше) обслуживают чуть меньше 500 клиентов. Постепенно переводим клиентов на DHCP.

Поднято 2 таких сервера. Первый - основной, на нем веб-морда. Второй - регулярно (каждые 5 минут в рабочее время) обновляет базу с первого.

За месяц на первом обработано 237450 и на втором 456559 запросов.

Т.к. было замечено, что служба иногда падает, - каждые 10 минут рестарт сервиса. Если при рестарте служба не работала (упала), то сыпется сообщение на мыло (отрабатывает крон). За месяц было 2 таких сообщения.

 

Для синхронизации:

1. На основном сервере поднят HTTP (все равно нужен для веб-морды), расшарена /lib/dhcp-perl/data/.

2. На основном сервере каждые 5 минут (в рабочее время, когда могут изменяться данные) запускается

/lib/dhcp-perl#cat export

#! /bin/sh

 

data_dir="/lib/dhcp-perl/data/"

 

echo > /lib/dhcp-perl/data/flag

 

mysqldump --user=dhcp --password=dhcp dhcp clients > ${data_dir}clients.sql

mysqldump --user=dhcp --password=dhcp dhcp locations > ${data_dir}locations.sql

mysqldump --user=dhcp --password=dhcp dhcp switch > ${data_dir}switch.sql

mysqldump --user=dhcp --password=dhcp dhcp vlans > ${data_dir}vlans.sql

 

cp -f ${data_dir}*sql ${data_dir}copy/

 

rm -f /lib/dhcp-perl/data/flag

 

3. На втором сервере

В файле /etc/hosts прописан адрес "1.dhcp" с IP первого сервера. Я решил, что так проще.

/lib/dhcp-perl/get# cat get_sql

#! /bin/sh

 

cd /lib/dhcp-perl/get

rm -f flag

rm -f flag.*

wget -q http://1.dhcp/data/flag'>http://1.dhcp/data/flag && sleep 10

wget -rq http://1.dhcp/data/

 

cmp -s /lib/dhcp-perl/get/1.dhcp/data/clients.sql /lib/dhcp-perl/get/1.dhcp/data/copy/clients.sql || exit 1

cmp -s /lib/dhcp-perl/get/1.dhcp/data/locations.sql /lib/dhcp-perl/get/1.dhcp/data/copy/locations.sql || exit 1

cmp -s /lib/dhcp-perl/get/1.dhcp/data/switch.sql /lib/dhcp-perl/get/1.dhcp/data/copy/switch.sql || exit 1

cmp -s /lib/dhcp-perl/get/1.dhcp/data/vlans.sql /lib/dhcp-perl/get/1.dhcp/data/copy/vlans.sql || exit 1

 

cp -f /lib/dhcp-perl/get/1.dhcp/data/*.sql /lib/dhcp-perl/data/

rm -f flag

rm -f flag.*

exit 0

 

Регулярно в рабочее время, каждые 5 минут, со сдвигом относительно первого сервера запускается

/lib/dhcp-perl# cat import

#! /bin/sh

 

/lib/dhcp-perl/get/get_sql || exit

 

#echo "Import"

data_dir="/lib/dhcp-perl/data/"

 

mysql --user=dhcp --password=dhcp dhcp < ${data_dir}clients.sql

mysql --user=dhcp --password=dhcp dhcp < ${data_dir}locations.sql

mysql --user=dhcp --password=dhcp dhcp < ${data_dir}switch.sql

mysql --user=dhcp --password=dhcp dhcp < ${data_dir}vlans.sql

 

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

Если в какой-то момент времени (кратковременно) DHCP будет недоступен, - ничего страшного.

На сервере настроено время аренды адреса 1 час. Через 30 минут клиент начинает пытаться продлить аренду.

Чтобы за оставшиеся 30 минут клиент не смог "достучаться"... Это шибко маловероятно.

Единственно, возможна проблема при первом получении адреса. Но 2 сервера (на свичах обычно можно указать 4), да клиент посылает несколько запросов...

В общем, пока проблем не было.

Были проблемы, но связаны с некорректными настройками интерфейса у клиента. В винде это лечится удалением сетевой карты в диспетчере устройств. Потом винда находит устройство и прописывает все параметры по-умолчанию.

 

PS.

500 запросов в секунду...

Клиент при получении адреса отправляет 3-8 запросов (зависит от OS). Будем считать 10.

50 клиентов в секунду получают адреса (500/10).

Аренда - 1 час, обновление через 30 минут.

Т.е. за 30 минут сервер выдаст 30*60*50=90000 адресов.

Т.е. в нормальном режиме, при производительности 500 запросов/сек сервер способен обслужить 90к клиентов.

Делим это на 2 (всякие форс-мажор) и получаем 45к.

 

Так что насчет производительности, думаю, заморачиваться особо смысла нет. Но второй (а может 3 и 4) сервера имеет смысл иметь ради надежности.

 

PPS. Для справки.

Первый сервер - на той-же машине, что и биллинг (так удобнее для интеграции), - 2 камня по 4 физических ядра, памяти ... много.

Второй сервер - на виртуалке, 2 виртуальных камня по 2 виртуальных ядра, 512 МБ памяти. Больше на этом сервере ничего нет (виртуальная машина специально для DHCP).

В top процессов DHCP и не видно. На втором сервере, в данный момент, используется 311 МБ и 0-2 %% CPU.

Edited by Инкогнито

Share this post


Link to post
Share on other sites

Настроили сервер под свою базу. Получает и выдает адреса нормально. Но вот с продлением есть проблемы, cвитчи DES-3028 не добавляют Opt82 в юникастовый пакет. На сервер приходит только МАС, который он успешно игнорирует.

Собственно интересует когда будет отвечать на прямые запросы, или подскажите где выполняется проверка на наличие Opt82? Городить костыль с добавлением опции на L3 и потом обработкой этого не хочется.

Share this post


Link to post
Share on other sites

Почитайте доку от свичей, там есть особенность с добавлением опции82, чтобы она вставлялась во все пакеты.

Share this post


Link to post
Share on other sites

В том то и дело. DES-3200 добавляет ее во все пакеты. DES-3028 только в бродкастовый, добавление в юникаст еще не реализовано, а у нас их еще не менее 4-х десятков.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

DHCP сервер находится в отдельной сети. На свитчах доступа используем DHCP Local Relay внутри нужного влана. На L3 включен Relay для интерфейса.

Но все же...

интересует когда будет отвечать на прямые запросы, или подскажите где выполняется проверка на наличие Opt82?

 

По теме http://forum.dlink.ru/viewtopic.php?f=2&t=149954

Edited by DMiTRONiK

Share this post


Link to post
Share on other sites

Настроили сервер под свою базу. Получает и выдает адреса нормально. Но вот с продлением есть проблемы, cвитчи DES-3028 не добавляют Opt82 в юникастовый пакет. На сервер приходит только МАС, который он успешно игнорирует.

Собственно интересует когда будет отвечать на прямые запросы, или подскажите где выполняется проверка на наличие Opt82? Городить костыль с добавлением опции на L3 и потом обработкой этого не хочется.

Логи включите, и смотрите до демона доходит пакет или нет.

Если доходит - смотреть handle_request и далее db_get_requested_data.

Если нет - то либо ставить релей агента хоть локально либо пытаться вешать на другой интерфейс: " -b <ip> ip address to bind (def: 0.0.0.0)"

Share this post


Link to post
Share on other sites

Привет труженикам. Вопрос, вроде писали про хранение опций в базе, а в варианте от инкогнито ничего такого нет.

 

а то интересует вопрос как выдавать статические маршруты клиентам и другие параметры.

Edited by Cramac

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

жаль, что с перлом не дружу :(

 

Хотя я не правильно наверное выразился, интересует возможность отправки клиенту статических маршрутов:

 

option rfc3442-classless-static-routes 16 , 172, 20 , 172 , 20 , 1 , 254 ,16 , 10 , 10 , 172 , 20 , 1 , 254;

option ms-classless-static-routes 16 , 172, 20 , 172 , 20 , 1 , 254, 16 , 10 , 10 , 172 , 20 , 1 , 254;

Edited by Cramac

Share this post


Link to post
Share on other sites

Есть там такое и даже работает.

см db_get_routing

Она распихивает /32 маршруты в опцию 33, а остальное в 121/249 (в зависимости о того что клиент запросил).

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this