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

isc dhcpd и клиенты "перетыкальщики", кто как решает проблему

...

Поэтому я перестал выдавать патч - так как он был изначально делан не для себя, а для зарабатывания.

Если бы у меня была сеть и я бы делал его для себя, я бы скорее всего просто отдал бы его в общественность.

В общем опрометчиво было ожидать взаимопонимания от коллег - админов, а жаль. Знания и опыт стОит денег.

Знакомо и печально.

 

истинный русский менталитет.

Это вы в каком смысле?

Share this post


Link to post
Share on other sites

в том смысле что все хотят все на халяву и мало кто хочет платить за чужой труд. Сам такое же заметил, делал скрипт для сетей, пожертвовал только 1 человек :) а пользуют 10-ки

Share this post


Link to post
Share on other sites

ну так может стоит изменить подход и адаптироваться к существующим условия.

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

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

Edited by Megas

Share this post


Link to post
Share on other sites

ну так может стоит изменить подход и адаптироваться к существующим условия.

 

--------- читайте следующий мой пост ---------

Edited by (= dd =)

Share this post


Link to post
Share on other sites

2 Alexandr Ovcharenko, а статич маршруты выдавали?

Нет. Мы раздаем сразу белые адреса, статически привязанные в биллинге к связке порт/свич (опция 82). При этом нет нужды что-то роутить - дефолта достаточно.

Share this post


Link to post
Share on other sites

Ребят, мне б ваши проблемы! :-D

 

Проведу эксперимент. Даю готовый DHCP-сервер с MySQL: http://goo.gl/3TxNq . Самописный. Местами костылявый, но свою работу вот уже больше полугода делает на отлично. Ни разу не глючил, ни разу не падал. Интересно, мне денег за это кто-то даст? :-D Специально даю ссылку через goo.gl, чтобы посчитать скачивания. Потом выложу статистику.

Share this post


Link to post
Share on other sites

Ребят, мне б ваши проблемы! :-D

 

Проведу эксперимент. Даю готовый DHCP-сервер с MySQL: http://goo.gl/3TxNq . Самописный. Местами костылявый, но свою работу вот уже больше полугода делает на отлично. Ни разу не глючил, ни разу не падал. Интересно, мне денег за это кто-то даст? :-D Специально даю ссылку через goo.gl, чтобы посчитать скачивания. Потом выложу статистику.

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

Share this post


Link to post
Share on other sites

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

Опции задаются в конфиге. Конфиг с коментариями, в 10 строчек. Запутаться невозможно.

В БД создаем свитчи (IP, MAC, кол-во портов), пулы адресов (начало, конец пула). Все адреса в int (ф-ция в php - ip2long, ф-ция в MySQL - INET_ATON).

Привязываем свитчи к пулам (id-to-id, к нескольким свитчам может быть привязано несколько пулов адресов).

При первом запросе с порта сервер возьмет адрес из пула и создаст лизу. Для ручной выдачи можно создать лизы вручную, таблица leases.

Вообще ко всему этому у меня есть веб-морда, но она страшненькая, поэтому выкладывать не стал.

 

P.S.: Уже 11 скачиваний :).

Share this post


Link to post
Share on other sites

Специально даю ссылку через goo.gl, чтобы посчитать скачивания. Потом выложу статистику.

-1 от статы

Я только посмотреть внутренности %)

Share this post


Link to post
Share on other sites

Специально даю ссылку через goo.gl, чтобы посчитать скачивания. Потом выложу статистику.

-1 от статы

Я только посмотреть внутренности %)

Да ты уже вроде всё видел ;).

UP: 19-1 = 18.

Share this post


Link to post
Share on other sites

Отдалённо напоминает мою версию - perl:DHCP всё же )

У тебя также только с релей агентами пашет или умеет на 0.0.0.0 по маку клиента слать ответ?

Share this post


Link to post
Share on other sites

Отдалённо напоминает мою версию - perl:DHCP всё же )

У тебя также только с релей агентами пашет или умеет на 0.0.0.0 по маку клиента слать ответ?

Так же, только релей.

Share this post


Link to post
Share on other sites

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

В результате был написан свой DHCP сервер на Perl (да-да, еще один :).

Он умеет отвечать на 0.0.0.0, формат конфига как ISC DHCP.

Option 82 поддерживает через плагин куда вынесена логика работы с базой (используется postgres), без него может по идее работать как простой DHCP сервер.

 

Поделка конечно кривовата, но может кому пригодится код. Никаких донейтов не прошу :)

Исходники можно слить тут: http://gibbon.kinnet.ru/kindhcpd.tar.bz2

Share this post


Link to post
Share on other sites

gibbon,

Ай маладца! Срочно пива этому господину!

 

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

Скинулись?

Статистика по моему серверу: 24 скачивания, минус одно моё, одно Ivan_83. Итого - 22. Количество "синувшихся" - 0. В процентном соотношении - тоже 0. Видать, не выгорело :-D.

 

Подводим итог:

%D0%BA%D0%BE%D1%82%D1%8D-124068.jpeg

 

Let the srach begin!

Share this post


Link to post
Share on other sites

Abram, Ваш пост был вчера, вы хотите чтобы люди за сутки обкатали и запустили в продакшин? дамс. тогда сочувствую.

так дела не делаются.

Share this post


Link to post
Share on other sites

В результате был написан свой DHCP сервер на Perl (да-да, еще один :). Он умеет отвечать на 0.0.0.0, формат конфига как ISC DHCP.

Свой, - то-то буквы знакомые :)))

Покажите на место в коде где собирается ethernet фрейм с dst mac - клиента, в котором собирается ip dst=0.0.0.0 в котором собирается udp пакет с ответом.... ?

 

PS: я видел на форуме перловый код для работы с эзернет фреймами, но пока необходимости нет в прямой работе с клиентами, без релей агентов.

PPS: приятно видеть что пригодилось и дальше развилось.

Share this post


Link to post
Share on other sites

Весь код и сопроводительное письмо, которое я высылал: http://goo.gl/Ur0Pq

Тещщено на разных линуксах и на фре.

 

Приятного пользования.

 

PS Чуть не забыл, пароль test123

Edited by (= dd =)

Share this post


Link to post
Share on other sites

(= dd =) спасибо, отправил вам подарок.

 

И сразу вопрос. Судя по описанию, работать одновременно как обычный (выдавать из пула) и с опцией (без учета мака) не получится?

Share this post


Link to post
Share on other sites

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

 

Ps за "подарок" спасибо

Edited by (= dd =)

Share this post


Link to post
Share on other sites

В результате был написан свой DHCP сервер на Perl (да-да, еще один :). Он умеет отвечать на 0.0.0.0, формат конфига как ISC DHCP.

Свой, - то-то буквы знакомые :)))

Покажите на место в коде где собирается ethernet фрейм с dst mac - клиента, в котором собирается ip dst=0.0.0.0 в котором собирается udp пакет с ответом.... ?

 

PS: я видел на форуме перловый код для работы с эзернет фреймами, но пока необходимости нет в прямой работе с клиентами, без релей агентов.

PPS: приятно видеть что пригодилось и дальше развилось.

 

Увы мой код не умеет слать unicast ответы клиентам в локальной сети, в не через relay agent.

Он просто шлет broadcast с интерфейса с котрого получен запрос. Но винда адрес получает, я проверял.

Share this post


Link to post
Share on other sites

(= dd =)

Спасибо за патчик. Правда пока попробую на продакшене свой черезж0пный костыль.

ЗЫЖ кинул скромную компенсацию за труды на киви :)

Share this post


Link to post
Share on other sites

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

...

Let the srach begin!

Начнем срач)

DHCP, похоже, проклятый протокол. :)

Клиентская часть реализована мутно, разные клиенты ведут себя по-разному и к этому надо приспосабливаться. Функционал relay-агента на железках тоже реализован абы как. На форуме D-Link'а на каждой странице по 3-4 темы, посвященные проблемам с dhcp/dhcp_relay. Да и сервера нет такого, который бы всех устраивал. Выдать адрес, по большому счету, не проблема. А вот когда надо выдать адрес 30-50К клиентам со всевозможными vendor-specific и иными произвольно конфигурируемыми опциями, да еще чтобы из БД брал настройки, да еще чтобы туда писал логи/ивенты, да чтоб обработчики произвольные имел на различные ситуации... Вот тогда и начинаются танцы с бубном. И вроде бы и кактус жрем, но он уже какой то привычный даже стал, родной. А за эти три решения кто может поручиться? Больно темные лошадки то:)

Share this post


Link to post
Share on other sites

Начнём с того, что чисто бинарных протоколов очень мало. (Отбросим транспортные типа ip, tcp - там относительно мало параметров которые нужно обрабатывать, помимо данных)

 

Реализовывать бинарные протоколы программисты пипец как не любят, ибо сложно.

Текстовый - с телнета хрень серверу написал, он тебя послал накуй и всё видно и понятно, вот он, первый результат на 30 секунде изучения протокола.

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

 

Ещё одна особенность бинарных протоколов - обилие параметров и значений. Те если взять готовый фреймворк с примерами - чё то вроде заработает, но всё равно нихера не понятно и чтобы что то (кроме: "Привет, сервер!") написать придётся втыкать в документацию как по фреймворку так и по самому протоколу.

 

Я реализовал DNS (без DNSSec - оно мне не нужно пока) и DHCP фреймворки на си под себя, и понял что костыльность протокола напрямую зависит от начального планирования и от того как и насколько изменились условия его применения.

 

DHCPv4 (DHCPv6 - делали с нуля) вырос из BOOTP, и унаследовал много не нужного и вредного, но оно нужно было для обратной совместимости.

У самого протокола ппц как много всяких разных параметров(опций), и под параметров(субопций):

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml#bootp-dhcp-parameters-1

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

 

А вот когда надо выдать адрес 30-50К клиентам со всевозможными vendor-specific и иными произвольно конфигурируемыми опциями, да еще чтобы из БД брал настройки, да еще чтобы туда писал логи/ивенты, да чтоб обработчики произвольные имел на различные ситуации... Вот тогда и начинаются танцы с бубном. И вроде бы и кактус жрем, но он уже какой то привычный даже стал, родной. А за эти три решения кто может поручиться? Больно темные лошадки то:)

Оформите в голове план того что вам нужно и начинайте реализацию :)

Почти все DHCP сервера доступны в исходниках (под винду только редко с исходниками), документация по всем основным опциям тоже свободно доступна - что тёмного?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.