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

DHCP минимальный lease

Добрый день, возникла необходимость в dhcp сервере с очень коротким lease time, порядка 10 минут ( а может и одной минуты).

Те клиентские железки, что смог потестить, (роутеры mikrotik-951, tplink-741, виндузы 7/xp воткнутые на прямую), вроде относятся к этому нормально,

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

Есть у кого опыт с такими "короткопамятными" dhcp ?

Share this post


Link to post
Share on other sites

У нас DHCP на 15 минут, проблем отмечено не было.

Share this post


Link to post
Share on other sites

У нас DHCP на 15 минут, проблем отмечено не было.

+1

Share this post


Link to post
Share on other sites

А у нас 10, пробовали и 5 минут ставить, тоже нормально.

Share this post


Link to post
Share on other sites

подтверждаю, что и 5 и 10 минут работают нормально.

Share this post


Link to post
Share on other sites

Всем ответившим спасибо, ответы радуют)

Share this post


Link to post
Share on other sites

У нас 5 минут, полет нормальный. Пробовали 30с, тоже работает, но это уже реальный экстрим - за 15с клиент вполне может и не успеть переполучить IP, будут постоянные микрообрывы.

Share this post


Link to post
Share on other sites

А зачем такой маленький lease time?

У нас неделя например.

Share this post


Link to post
Share on other sites

для клиентов-перетыкальщиков без роутера

 

При условии, что DHCP-сервер держит лизу, а не тупо выдает адрес всем кто подошел под правила классификации.

Например, в случае самописного сервера, можно и не парится с этим гемороем в 15 минут, а выдать на неделю.

Share this post


Link to post
Share on other sites

для клиентов-перетыкальщиков без роутера

Дхцп-сервер на запрос от клиента должен просто залезть в БД и по опции 82 вынуть данные для пары свич+порт. Не зависимо от времени лизы. Тогда любой перетыкальщик получает адрес сразу и без проблем, хоть и лиза при этом может быть выставлена на месяц. К чему усложнять себе жизнь "фиксацией" лизы на стороне сервера? Или "мы не ищем легких путей"(с) ?

Share this post


Link to post
Share on other sites

А зачем такой маленький lease time?

У нас неделя например.

 

Это позволяет гибко раздавать адреса, особенно если они белые. Т.к. клиент выключил компьютер и через 5-10 минут его адрес уже свободен. Кроме этого предостерегает его от частой смены устройств. Например переключив кабель из одного устройства в другое, он не получит интернет, пока время на освобождение старого адреса не закончится.

Share this post


Link to post
Share on other sites
для клиентов-перетыкальщиков без роутера

Для ISC-DHCPD есть патч от ~dd~

ищите на форуме.

Кроме этого есть несколько реализаций DHCP серверов на этом форуме, которые этим не страдают.

Есть еще решения для клиентов- перетыкальщиков.

Выставлять lease-time в 1 минуту -явно бред и лишняя бесполезная нагрузка на сеть, сервер и прочее.

Share this post


Link to post
Share on other sites

Все это верно, только если абоненту разрешено подключать 1 устройство в сеть. Мы разрешаем подключать 8, поэтому фиксирование времени аренды нам необходимо. Сейчас время аренды для активного абонента 8 часов, для неактивного - 10 минут. Имеем неплохую нагрузку на БД, где копятся логи выданных адресов. Точных цифр не помню, но вроде как вырастает на 10-12 гигабайт в месяц.

 

p.s. А насчет патча мысль интересная, но она под конкретную схему.

Share this post


Link to post
Share on other sites

Я тоже долго парился с оптимальным значением лиза, т.к. жалобы были и на короткий и на длинный лиз, в итоге поступил так - лиз на неделю, по крону удаление dhcpd_leases и рестарт dhcp сервера каждые 10 минут.

Edited by denis_vid

Share this post


Link to post
Share on other sites

рестарт dhcp сервера каждые 10 минут.

У меня он целых 7 минут перезапускался - конфиг огромный. :)

Share this post


Link to post
Share on other sites

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

 

То, что вы формируете в гигантском текстовом конфиге, мы формируем в табличке БД. Сервер дхцп при этом минимален и прост - он лишь анализирует дхцп-запрос, лезет в таблицу и вынимает из нее абсолютно все настройки для клиента. Быстродействие сумасшедшее, потребление памяти мизерное, аптайм - вечность. Если нам вдруг приспичило что-то принудительно поменять клиенту, вносятся изменения в табличку БД и либо клиент сам получит новые настройки по истечению времени лизы, либо (если уж совсем срочно надо) моргается порт доступа на свиче. Все просто как 5 копеек. Дхцп-сервер не прерывает работу никогда. Ибо незачем.

 

В итоге, никаких фиксаций лиз и ограничений по количеству перетыкаемых устройств. Абсолютное удобство для абонента - втыкай кабель провайдера в любую дырку, эта дырка тут же без проблем получит IP. Надо чтобы 8 устройств в квартире сразу в инет выходило? Не вопрос! Конечно, можно абоненту поставить свич, а нам изобрести костыль для дхцп, который "разрешит" абоненту получать до 8-ми разных IP на один аккаунт. НО ЗАЧЕМ?! Человечество изобрело для этого гениальное поделие - сохо-роутеры. Дешево и сердито.

 

Думайте и заботьтесь о своих абоннетах, и они отблагодарят вас.

Edited by Alexandr Ovcharenko

Share this post


Link to post
Share on other sites

рестарт dhcp сервера каждые 10 минут.

У меня он целых 7 минут перезапускался - конфиг огромный. :)

Порядка 600 коммутаторов по 24 порта op82, конфиги свичей в основной конфиг инклюдом, секунд 15-20.

Edited by denis_vid

Share this post


Link to post
Share on other sites
Я тоже долго парился с оптимальным значением лиза, т.к. жалобы были и на короткий и на длинный лиз, в итоге поступил так - лиз на неделю, по крону удаление dhcpd_leases и рестарт dhcp сервера каждые 10 минут.

 

Пробовали мы и так. dhcpd.leases и вовсе можно в /dev/null отправлять. Но это не совсем правильно.

Файл leases нужен для корректного функционирования dhcp сервера.

У нас на нем не только клиенты висят, а еще и приставки.

Сейчас пользуемся патчем от ~dd~. Проблем по большому счету нет. Есть некоторые тонкости при настройке коммутаторов.

Если вы выдаете 8 адресов на порт - то проблем тоже быть не должно при смене железок(если конечно у абонента не 8 компов и он их постоянно не меняет)

Самым правильным решением будет наверное использовать специальный dhcp сервер работающий с базой.

 

Порядка 600 коммутаторов по 24 порта op82, конфиги свичей в основной конфиг инклюдом, секунд 15-20.

+1.

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

 

 

 

То, что вы формируете в гигантском текстовом конфиге, мы формируем в табличке БД. Сервер дхцп при этом минимален и прост - он лишь анализирует дхцп-запрос, лезет в таблицу и вынимает из нее абсолютно все настройки для клиента. Быстродействие сумасшедшее, потребление памяти мизерное, аптайм - вечность. Если нам вдруг приспичило что-то принудительно поменять клиенту, вносятся изменения в табличку БД и либо клиент сам получит новые настройки по истечению времени лизы, либо (если уж совсем срочно надо) моргается порт доступа на свиче. Все просто как 5 копеек. Дхцп-сервер не прерывает работу никогда. Ибо незачем.

 

Есть пара вопросов.

1. Сколько пользователей коммутаторов? Какая нагрузка на сервер, базу?

2.Собственно каким решением пользуетесь? Самописным или готовым?

3.Умеет ли dhcp отдавать статические маршруты? Обрабатывать option_82, отдавать адреса по маку, vendor_class_identifier?

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

 

 

Собственно хочется попробовать.

Share this post


Link to post
Share on other sites

ics dhcp на такие нагрузки не рассчитывали.

Весь софт ics представляет из себя эталонный образец следования спецификациям из RFC, это основная цель.

Оно нормально работает на малых и средних нагрузках.

Когда нагрузки возрастают и появляются хотелки за гранью RFC то нужно искать/создавать альтернативу.

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

Альтернатива - секс на постоянной основе с ics dhcp.

 

PS: а кому то интересен тот дхцп на перле но для IPv6?

Share this post


Link to post
Share on other sites

А что никто не рассматривает по DHCP IP адреса абонентам менять? Если дадите их на неделю то пока абонент не перезагрузит свое оборудование оператор не сможет поменять адрес.

Share this post


Link to post
Share on other sites
А что никто не рассматривает по DHCP IP адреса абонентам менять?

А ты сколько можешь назвать клиентов, которые ловят нотификации от ДХЦП сервера? (те после получения адреса и всех нужных параметров)

Венда точно не ловит. Дальше можно об этом не думать.

Share this post


Link to post
Share on other sites

То, что вы формируете в гигантском текстовом конфиге, мы формируем в табличке БД.

...

Дхцп-сервер не прерывает работу никогда. Ибо незачем.

Сейчас у нас тоже в БД, адреса выдает FreeRADIUS. Раньше было вот как:

1. Сервер1 обновляет конфигурацию, в это время работает Сервер2

2. Сервер1 чекает конфигурацию, в это время работает Сервер2

3. Если конфигурация в норме, Сервер1 перезапускается. Сервер2 по прежнему работает

4. Запускается Сервер1. Сервер2 начинает обновлять конфигурацию и дальше по циклу

 

Отсюда и большие интервалы перезапуска. Абоненты получают IP либо с одного сервера, либо с другого. Еще раньше было не так, но падение производительности isc dhcpd не линейно, а с разбегу внедрить другую систему мы не могли.

Почему надо перезапускать сервер? Потому что надо обновлять конфигурацию, а isc dhcpd без этого никак. А обновлять ее надо, т.к. сервер не просто раздает адреса, а еще решает несколько интересных задач, таких как:

Умеет ли dhcp отдавать статические маршруты? Обрабатывать option_82, отдавать адреса по маку, vendor_class_identifier?

и не только.

 

На момент, когда от isc dhcpd отказались, он обслуживал около 2800 коммутаторов. Под каждый порт свои настройки.

НО ЗАЧЕМ?! Человечество изобрело для этого гениальное поделие - сохо-роутеры. Дешево и сердито.

Поделие - лучше и не скажешь. :)

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

Share this post


Link to post
Share on other sites
Коммутатор удобнее и ползователю (дешевле, стабильнее и не требует настройки) и оператору (все устройства абонента винды, можно зайти на приставку и т.д., провести удаленную диагностику).

ну ну.

Есть одно но:

99% людей у которых больше 1 компа подключают второй по wi-fi.

А для этого кроме свича нужна еще и точка доступа. А это уже 2 железки, которые нафиг не нужны дома.

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

 

Коммутатор удобнее и ползователю (дешевле, стабильнее и не требует настройки) и оператору (все устройства абонента винды, можно зайти на приставку и т.д., провести удаленную диагностику).

ну ну.

Есть одно но:

99% людей у которых больше 1 компа подключают второй по wi-fi.

А для этого кроме свича нужна еще и точка доступа. А это уже 2 железки, которые нафиг не нужны дома.

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

 

P.S. какой сервер из представленных здесь посоветуете? Или у Вас самописный?

Share this post


Link to post
Share on other sites
А что никто не рассматривает по DHCP IP адреса абонентам менять?

А ты сколько можешь назвать клиентов, которые ловят нотификации от ДХЦП сервера? (те после получения адреса и всех нужных параметров)

Венда точно не ловит. Дальше можно об этом не думать.

 

Зачем нотификация? Если абоненту выдали адрес 10.0.0.1 на 5 минут, то он сам по истечении этого времени запросит обновление адреса, и если ему выдадут 10.10.10.1 то он уже будет работать с ним.

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