Срок действия аренды dhcp

Как изменить время аренды ip адреса в DHCP в Windows Server 2008R2

Как изменить время аренды ip адреса в DHCP в Windows Server 2008R2

Как создать область ip адресов DHCP в Windows Server 2008R2-01

Добрый день, продолжим настройку нашего dhcp сервера и разберем как изменить время аренды ip адреса в DHCP в Windows Server 2008R2. Ранее мы с вами рассмотрели один из вариантов защиты dhcp сервера за счет фильтрации mac адресов, данная статья, тоже в какой то мере работает на защиту вашей сети, предположим, что у вас стоит по умолчанию 8 дней аренда ip адреса и сетка у вас 254 адреса, из которых раздается только 200, у вас 50 мобильных пользователей и 180 постоянных назовем их локальными, допустим у вас 50 пользователей из числа мобильных забрали 50 ip адресов на 8 дней, и оставшиеся 180 придя на работы все не смогут к ней приступить так как у DHCP сервера не хватит ip адресов, вот тут нам и будет полезно настроить время аренды на более меньшее значение.

Открываем оснастку DHCP и выбираем интересующую нас область. Щелкаем по ней правым кликом и выбираем свойства.

Как изменить время аренды ip адреса в DHCP в Windows Server 2008R2-01

В открывшемся окне видим пункт Срок действия аренды адреса для DHCP клиентов. По умолчанию стоит 8 дней советую поставить часов 8.

Как изменить время аренды ip адреса в DHCP в Windows Server 2008R2-02

Жмем применить. Вот так вот просто изменить время аренды ip адреса в DHCP в Windows Server 2008R2.

Как изменить время аренды IP адресов DHCP в Windows Server 2016

Чаще всего в качестве DHCP сервера используется отдельный программный или аппаратный комплекс. Например какой-нибудь межсетевой экран ну скажем Kerio Control или если взять аппаратный продукт то это чаще всего Mikrotik. Мало кто отдает данную роль серверам на базе Windows. Хотя с этой задачей они справляются не хуже. Сегодня поговорим о сроке аренды IP адресов. Мало кто производит настройку данного параметры и оставляет все по умолчанию. Но если у вас DHCP сервер развернут на базе Windows Server 2016 и вам необходимо изменить срок аренды то сделать это достаточно проста.

Настройка времени аренды IP адресов в Windows Server 2016

И так для начала нужно зайти в DHCP. Найти его можно либо через пуск либо через Диспетчер серверов.

Далее нужно выбрать Область кликнуть правой кнопкой и зайти в Свойства.

На вкладке Общие в низу будет пункт Срок действия аренды адресов для DHCP клиентов. Как видите можно указать период действия от минут до нескольких дней. А также вообще можно отключить срок аренды. Но делать это категорически не советую так как в этом случае IP адреса будут выдаваться клиентам на всегда и вскоре вы столкнетесь с проблемой не хватки адресов. Так как они не будут освобождаться по истечению срока аренды. Самые оптимальный период срока аренды составляет 48 часов.

Так же хочу немного рассказать как это работает. Допустим вы указали срок аренды адресов 48 часов по истечению половины этого времени клиент выполнит попытку продлить срок аренды. Если в течении этого времени клиент будет не активен то выданный IP адрес освободиться. И при следующем запросе он получить уже новый.

Посмотреть на какое время выдан IP адрес клиенту можно в настройки сетевого подключения. Там будет две строчки Аренда Получена и Аренда истекает.

В общем нет ни какой сложности в настройки времени аренды IP адресов DHCP сервера который развернут на базе Windows Server 2016.

Меняем период аренды IP-адреса DHCP

Для изменения времени аренды адреса, предоставляемого сервером DHCP, сделайте следующее.

1. Откройте оснастку DHCP (Пуск > Программы > Администрирование > DHCP (Start > Programs > Administrative Tools > DHCP)).

2. Раскройте раздел сервера.

3. Кликните правой кнопкой на области, время аренды адреса в которой необходимо изменить и выберите в контекстном меню команду Свойства (Properties).

4. Перескочите на вкладку Общие (General).

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

6. Кликните на кнопке Применить (Apply) и кликните на кнопке OK.

Срок действия аренды dhcp

В качестве предисловия. При общении с коллегами, отвечая на их вопросы о совместной настройке DNS и DHCP, часто отсылаю их к замечательной статье Шона Айви на Technet. К сожалению, аналогичного материала на русском языке я не находил. В очередной раз, устно переведя её знакомому, я решил оформить письменный перевод, чтобы иметь возможность отсылать к нему.

Привет всем, меня зовут Шон Айви и я US PFE (Premier Field Engineer). Моя специализация — операционная система Windows и службы Active Directory. Проще говоря, я специализируюсь на Active Directory и связанных с ней сетевых службах. Недавно, у трёх разных клиентов, я помогал SCCM-администраторам, у которых была проблема с установкой SCCM агента. В логе ccm.log значилась ошибка Failed to get token for current process (5). Мы обнаружили, что проблема была не в SCCM, а во взаимодействии DNS и DHCP. Как оказалось, другие службы тоже испытывали связанные с этим проблемы, просто либо демонстрировали иные симптомы, либо не демонстрировали их совсем. Давайте поговорим о том почему так получалось и как это можно предотвратить!

Рассмотрим следующий сценарий:

  • В DHCP настроена область IP адресов, со сроком аренды 8 дней
  • В области DHCP осталось мало свободных IP адресов
  • Клиент А не обновлял аренду своего адреса 8 дней и она истекла
  • Клиент Б запрашивает новый IP адрес
  • DHCP сервер отдаёт Клиенту Б адрес, которым раньше пользовался Клиент А

Пока всё хорошо. Это довольно типовой сценарий работы DHCP сервера и всё происходит именно так, как мы ожидаем. Давайте теперь добавим сюда DNS сервер.

  • Интегрированная с Active Directory зона DNS с настроенной очисткой зоны
  • Настройки очитски по умолчанию: “Интервал блокирования = 7 дней” и “Интервал обновления = 7 дней”
  • Настройки сервера также по умолчанию: “Период очистки = 7 дней”
  • Клиент А обновил DNS запись 8 дней назад (в тот самый день, когда получил свой адрес)
  • Клиент А является владельцем своей DNS записи и она не может быть удалена DHCP сервером (при настройках по умолчанию)
  • Клиент Б пытается зарегистрировать DNS запись с новым адресом, который он получил от DHCP сервера
  • Это тот же самый IP адрес, который использовал Клиент А!
  • DNS сервер не сможет вычистить старую запись Клиента А еще 6 дней!
Смотрите так же:  Усн для ип патент

(Если, вдруг, вы не знаете, что такое “очистка зоны”, “интервал блокирования/обновления”, то рекомендую вам почитать блог моего коллеги. Он шикарен! Примечание: раз вы читаете перевод оригинальной статьи, то, возможно, вам проще будет ознакомиться с русскоязычным материалом)
Вот теперь всё уже не так хорошо. Такое случается гораздо чаще, чем вы можете подумать. Теперь у Клиентов А и Б DNS записи ссылаются на одинаковый IP адрес.


Рисунок 1

Итак, у нас в DNS есть два разных имени, ссылающихся на одинаковый IP адрес. И, скорее всего, всё именно так и останется еще минимум 6 дней, пока не истекут описанные выше интервалы. Какие проблемы это может вызвать? Давайте посмотрим.

Я уже упомянул, что симптомом этой ситуации была проблема с установкой SCCM клиента, но, на самом деле, мы можем использовать для демонстрации более простой пример — доступ к общей папке. Принцип один и тот же.

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


Рисунок 2

А вот это уже интересно. Во первых, клиент А даже не включен… но мы получаем ответ от его имени. И это ошибка аутентификации! Некоторые из вас уже догадались, что это происходит, когда вы посылаете сеансовый ключ Kerberos предназначенный для одного компьютера другому, но давайте по порядку.

Мы видим, что наш компьютер (Infra-App1) посылает в DNS запрос на имя client-a.corp.contoso.com. В ответ он получает IP адрес 10.0.0.100.


Рисунок 3

Насколько знает DNS, так оно и есть. Клиент А действительно имеет адрес 10.0.0.100, но точно такой же адрес имеет Клиент Б.

Отлично, теперь мы получаем сеансовый ключ Kerberos. Вот только DNS запрос был на имя Клиента А, так что ответ от службы Kerberos также будет на имя клиента А.


Рисунок 4

Рисунок 5

Мы видим запрос на Рисунке 4 и ответ контроллера домена на Рисунке 5.

Теперь, получив ключ, мы можем попытаться подключиться, к тому, что мы считаем Клиентом А.


Рисунок 6

Здесь мы видим сеансовый ключ Kerberos.

И, наконец, мы видим сообщение об ошибке от Клиента А. Почему? Потому, что клиент А это не Клиент А, а Клиент Б.


Рисунок 7

Всё это только подтверждает то, что вы, вероятно, и так знали. Для того чтобы Kerberos отработал нормально, вы должны обратиться с правильным сеансовым ключом к правильному адресату (Если вы хотите узнать больше о Kerberos, почитайте блог Роба Грина «Kerberos для занятых админов» Примечание: аналогичного материала на русском я не нашёл, но с общими сведениями можно ознакомиться вот здесь).

Конечно, всё отлично сработает, если вместо FQDN имени мы обратимся по IP адресу. Почему? Потому, что в этому случае вместо Kerberos будет использована аутентификация NTLM. Используя IP адрес, мы не делаем никаких предположений о том, к какому клиенту мы подключаемся. Мы просто подключаемся по определённому IP адресу. Некоторые из вас могут подумать, что и для FQDN должно сработать. В конце концов, получив ошибку при использовании Kerberos, мы должны переключиться на NTLM, верно? Не совсем. Я не буду углубляться в детали, но мы переключимся на NTLM, только если мы не смогли договориться об использовании Kerberos. Вы можете прочитать об этом подробнее здесь. В любом случае, Kerberos не возвращал нам ошибки, он штатно ответил нам сеансовым ключом.

Как предотвратить

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

Примечание: я рекомендую уменьшить интервал очистки для каждого из этих способов до 1-3 дней. Интервал в 7 дней, используемый по умолчанию, позволяет проблемным записям оставаться в DNS чересчур долго.

    Увеличить длительность аренды DHCP, чтобы она соответствовала сумме интервалов обновления и блокирования. В нашем примере, мы увеличим его до 14 дней.

Преимущества:

  1. К тому времени, как DHCP сможет выдать адрес новому клиенту, DNS запись старого уже может быть удалена
  2. Простота реализации

Недостатки:

  1. Если у вас уже осталось мало свободных IP адресов в DHCP, то они могут просто закончится
  2. Момент очистки зоны не обязательно совпадёт с моментом истечение интервалов обновления и блокирования (а значит и времени аренды DHCP) и мы на небольшой промежуток времени можем получить ситуацию описанную выше. Чтобы уменьшить число таких проблем мы можем уменьшить интервал очистки до 1 дня.

  • Уменьшить интервалы обновления и блокирования, чтобы их сумма совпадала с длительностью аренды DHCP. В нашем примере, мы сократим оба интервала до 4 дней.

    Преимущества:

    1. Существующая DNS запись будет очищена раньше. По сути, результат будет аналогичен предыдущему варианту
    2. Простота реализации

    Недостатки:

    1. Несколько увеличиться нагрузка на Active Directory репликацию (если, конечно, это Active Directory интегрированная зона). Это вызвано тем, что клиенты будут чаще обновлять свои DNS записи (в нашем случае, каждые 4 дня вместо 7)
    2. Момент очистки зоны не обязательно совпадёт с моментом истечение интервалов обновления и блокирования (а значит и времени аренды DHCP) и мы на небольшой промежуток времени можем получить ситуацию описанную выше. Чтобы уменьшить число таких проблем мы можем уменьшить интервал очистки до 1 дня.

  • Настроить DHCP сервер, чтобы он регистрировал DNS записи от имени клиентов (почитать как это настроить можно здесьПримечание: а на русском, здесь)

    Преимущества:

    1. DHCP сервер будет удалять записи в DNS сразу по истечении аренды IP адреса
    2. При правильной настройке у вас никогда не появится таких проблемных записей

    Недостатки:

    1. Более сложная настройка требует вовлечения более квалифицированного персонала
    2. Настройка дополнительно усложняется тем, что потребуется сервисная учётная запись, от имени которой будут работать DHCP сервера или все DHCP сервера нужно будет добавить в группу DNSUpdateProxy (менее безопасный вариант)

  • Попробуйте поэкспериментировать с интервалами обновления и блокирования и длительностью аренды DHCP. Вы можете обнаружить, что изменение интервалов по умолчанию благотворно сказывается на работе ваших сетевых служб. Короткий срок аренды DHCP часто используются для беспроводных сетей. В то же время, не забывайте о дополнительной нагрузке, которую вы возлагаете на сервер, особенно если вы настраиваете частую (раз в несколько часов) очистку для очень большой DNS зоны.

    Поиск DNS записей с одинаковыми IP адресами

    Почти всё! Теперь мы понимаем, почему происходит такая ситуация, когда возникает проблема и как её предотвратить. Но как нам легко и быстро найти такие записи, если беда уже случилась? Вы можете легко найти такие парные записи в DNS используя несложный PowerShell скрипт (это, конечно же, не единственный способ).

    Смотрите так же:  Возврат товара магазином поставщику

    Ниже приведён образец вывода этого скрипта:


    Рисунок 8

    Скрипт очень простой. Рассматривайте его только как пример. Он вернёт дублированные IP адреса зарегистрированные для компьютерных учётных записей в Active Directory. Помните, что он запросит все компьютерные объекты из Active Directory домена и проверит в DNS IP адрес каждого из них. Если у вас много компьютеров, то используйте ключ -searchbase вместе с командой get-adcomputer, чтобы ограничить количество опрашиваемых каждый раз объектов. Если ваш компьютер не включен в Active Directory домен, то вы не сможете найти его командой get-adcomputer. Мой скрипт специально заточен на то, чтобы получить дублированные записи DNS для сценария, который я описал выше.

    Есть очень много статей о настройке интеграции DHCP и DNS. Цель этой — обобщить сведения о том, как эти две службы работает вместе, чтобы вам было проще это понять. Подведём итог:

    • Длительность аренды адреса в DHCP и интервалы обновления и блокирования по умолчанию = устаревшие DNS записи

  • Симптомы

    • SCCM: “Failed to get token for current process (5)”
    • Общие папки: “Logon Failure: The target account name is incorrect”
    • Любые другие службы использующие Kerberos также могут выдавать различные ошибки

  • Проблема

    • Корректная работа Kerberos требует, чтобы сеансовый ключ был выдан именно для того компьютера, с которым мы пытаемся установить соединение. Устаревшие DNS записи могут приводить к ситуациям, когда мы будем обращаться к одному компьютеру с ключом для другого

  • Решение

    • Изменение интервалов обновления и блокирования и/или длительности аренды DHCP
    • Настройка DHCP, чтобы сервер регистрировал DNS записи от имени клиентов
    • Поиск и удаление дублированных записей

  • Надеюсь, что статья была вам полезна! Правильная настройка интеграции DNS и DHCP избавит вас от такого рода проблем в вашей сети!

    Сисадмин должен быть ленив. DHCP и динамический DNS

    Архив номеров / 2009 / Выпуск №8 (81) / Сисадмин должен быть ленив. DHCP и динамический DNS

    СЕРГЕЙ СУПРУНОВ, инженер электросвязи «широкого ИТ-профиля». В свободное время изучает FreeBSD и Python и пытается осмыслить свою нелюбовь к KDE

    Сисадмин должен быть ленив
    DHCP и динамический DNS

    Настраивать каждый компьютер локальной сети в отдельности не обязательно. Эту работу можно доверить серверу.

    В наши дни невозможно представить себе предприятие, пусть даже небольшое, компьютеры которого не объединены в локальную сеть и не используют общие ресурсы, не обмениваются между собой файлами и т.п. Безусловно, всё это «хозяйство» можно настраивать и вручную, но по мере роста парка машин это становится всё более обременительным занятием. Да и вероятность ошибок возрастает пропорционально числу компьютеров. Поэтому и были придуманы протоколы, позволяющие выполнять настройку подключённых к сети машин автоматически.

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

    Часто упоминают также экономию адресного пространства (когда 30 человек, работающих посменно, смогут довольствоваться 12-ю адресами), но поскольку сети на реальных IP‑адресах сейчас строят крайне редко, а в «серых» недостатка не бывает, более актуальной выглядит проблема простоя компьютеров, а не экономии адресов.

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

    В больших Windows-сетях нет нужды «изобретать велосипед» – Active Directory и прочие достижения компьютерной мысли позволяют получить высокоавтоматизированную и глубоко интегрированную сетевую инфраструктуру если и не прямо «из коробки», то при минимуме усилий. Конечно, свои особенности и хитрости есть и там, но этим вопросам были (и, уверен, ещё будут) посвящены другие статьи.

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

    Основы протокола DHCP

    Начнём с рассмотрения общих принципов протокола динамической конфигурации хостов – DHCP. Этот протокол описан в RFC 2131 (некоторым расширениям посвящён RFC 2132 и другие документы) и решает задачу снабжения компьютеров необходимыми для работы в сети параметрами, такими как IP-адрес, маска подсети, шлюз по умолчанию, адреса DNS-серверов.

    DHCP является клиент-серверным протоколом. Один или несколько серверов, размещённых в сети, отвечают за выдачу клиентам IP-адресов и всех сопутствующих параметров. Адрес может выдаваться клиенту либо динамически на некоторое время (назначается любой свободный адрес из некоторого пула IP-адресов) – данная процедура называется «арендой», либо статически (если администратор сервера явно указал в настройках, какой адрес следует отдавать данному клиенту; распознавание клиента обычно выполняется по его MAC-адресу). Выделяют также «автоматическое» назначение IP-адресов, когда клиент получает от DHCP-сервера любой свободный адрес из пула (как при динамическом назначении), но не на время, а «навсегда». Технически этот способ редко отличается от динамического назначения, в некоторых реализациях его вообще не выделяют отдельно.

    В случае «аренды», что является основным режимом работы DHCP, IP-адрес выдаётся клиенту временно. Обычно в настройках сервера задаются два параметра – время аренды по умолчанию и максимальное время аренды. Первое используется, когда клиент, запрашивая адрес, не высказывает никаких пожеланий на этот счёт. Второе необходимо для ограничения аппетитов клиентов, не позволяя им владеть адресом слишком долго. Вообще вопрос времени аренды адресов обычно не играет принципиального значения, и указанные параметры иногда выбираются «с потолка». Но необходимо помнить, что именно от выбора времени аренды зависят такие вопросы, как устойчивость сети к непродолжительным сбоям, нагрузка на DHCP-сервер и скорость распространения изменений. Очевидно, что чем реже клиенты будут обращаться к серверу за адресами, тем меньше будет нагрузка на него и тем ниже вероятность, что какому-нибудь компьютеру потребуется обновить адрес именно в тот момент, когда сервер будет перегружаться. Однако при этом при любой корректировке параметров (скажем, изменении DNS-сервера или вообще переключении на другую подсеть) «переходный период» может заметно затянуться.

    Стандартные рекомендации в этих случаях – для «динамичных» (например, тестовых или лабораторных) сетей задавать по возможности небольшое время аренды (один час или даже десять-пятнадцать минут); для стабильно работающих офисных сетей адреса можно выдавать и на неделю или даже месяц (за месяц перед предстоящей сменой параметров сети можно будет уменьшить максимальное время аренды до одного дня, а после изменений – вернуть обратно увеличенное время аренды). В любом случае имеет смысл пересмотреть значения по умолчанию (например, сервер ISC изначально использует 10-минутную аренду при максимальном времени владения IP-адресом 2 часа; для большинства сетей эти значения трудно назвать оптимальными).

    Смотрите так же:  Коллективный договор регулируется

    Впрочем, невысокое время аренды не означает, что по его истечении клиент будет «отлучён от сети». Протокол DHCP предусматривает процедуру «продления аренды» клиентом, когда срок аренды истекает, но клиент ещё продолжает работать.

    Рассмотрим в общих чертах, как происходит процесс получения сетевых параметров (см. рис. 1):

    • После загрузки система клиента отправляет широковещательный (по адресу 255.255.255.255) запрос DHCPDISCOVER, цель которого – поиск доступных в данной сети DHCP-серверов. В качестве транспорта используется протокол UDP; серверы ожидают запросы на порту 67, клиенты используют 68-й порт.
    • Все DHCP-серверы, получившие этот запрос (как правило, распространение широковещательных запросов ограничивается одним сегментом локальной сети, поэтому речь идёт о серверах, размещённых в том же сегменте, хотя возможно и «проксирование» запросов в другие сегменты, о чём мы поговорим отдельно), отправляют (опять-таки, широковещательным пакетом, так как клиент ещё не имеет адреса) свои «предложения» DHCPOFFER, в которых указывают предлагаемый клиенту IP-адрес.
    • Клиент выбирает одно из поступивших предложений (как правило, предпочтение отдаётся первому полученному ответу) и направляет запрос DHCPREQUEST, указывая, какой из предложенных адресов он хотел бы получить, а также сообщая свои «пожелания» по дополнительным параметрам.
    • Сервер, направивший предложение, устроившее клиентскую систему, отвечает либо пакетом DHCPACK, подтверждающим, что клиенту выдан данный IP-адрес, либо пакетом DHCPNAK, в случае, если выделение данного адреса уже невозможно по тем или иным причинам. В последнем случае клиент будет вынужден начинать процесс получения адреса заново.

    Рисунок 1. Обмен пакетами между клиентом и сервером

    Если компьютер-клиент уже работал ранее в сети и когда-то получал IP-адрес, то в этом случае, как правило, он сразу начинает процесс получения сетевых параметров с запроса DHCPREQUEST, указывая свой «старый» адрес в надежде на то, что он свободен и сразу будет выдан снова тем же DHCP-сервером, с которым шла работа раньше. Если адрес действительно свободен и сервер готов предложить его этому же клиенту, клиент сразу получит DHCPACK и сможет приступать к работе.

    В противном случае (IP-адрес занят другим клиентом либо DHCP-сервер, обслуживающий его, недоступен) клиенту придётся проходить всю процедуру, начиная с DHCPDISCOVER.

    Ещё один момент – продление аренды. В процессе работы клиент не ждёт, когда аренда выданного ему адреса истечёт, и пытается продлить время его использования заранее, для чего отправляется всё тот же пакет DHCPREQUEST спустя некоторый интервал времени (renewal-time), часто называемый T1 (обычно составляет 50% от времени аренды). Если сервер, отвечающий за данный адрес, доступен и не имеет причин отказать в продлении аренды, то клиент получает DHCPACK и начинает «отсчитывать» срок аренды заново.

    Если же ответ сервера отсутствует, то клиент продолжает использование адреса до истечения срока первоначальной аренды, но время от времени предпринимает попытки её продлить. Если к некоторому моменту времени (rebinding-time, или T2, обычно около 90% от времени аренды) попытки продления не увенчались успехом, клиент отправляет запрос DHCPDISCOVER, чтобы получить хоть какой-нибудь адрес до того, как он лишится возможности работать в сети.

    Таким образом, относительно времени аренды можно сказать следующее:

    • интенсивность запросов к DHCP-серверу будет обратно пропорциональна интервалу T1: чем он меньше, тем чаще клиенты будут обращаться за продлением аренды;
    • продолжительность допустимого перерыва в работе сервера можно определить как разницу между временем аренды и значением T1: если клиент получает адрес на 48 часов, а запрашивать продление аренды начинает через 24 часа, то у администратора сети остаётся ещё 24 часа в запасе на решение проблем с сервером;
    • «переходный период», в течение которого все клиенты гарантированно получат обновлённые параметры, равен времени аренды IP-адреса.

    Помимо вышеупомянутых пакетов DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK и DHCPNAK, протоколом предусмотрены ещё три:

    DHCPRELEASE – им клиент может освободить выданный ему адрес до истечения срока аренды;

    DHCPDECLINE – так клиент сообщает серверу, что предложенный им адрес кем-то уже занят, проверка занятости адреса осуществляется ARP-запросом;

    DHCPINFORM – этот пакет используется, если клиент уже получил IP-адрес из других источников, а у DHCP-сервера запрашивает лишь дополнительные параметры, такие как адреса шлюзов, DNS-серверов и т.п.

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

    Рассмотрим более подробно утилиту dhclient, входящую в состав FreeBSD. В простейшем случае её использование сводится к команде:

    Работа может сопровождаться диагностическими сообщениями, например:

    DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 6

    Вопрос: ISC DHCP бесконечное время аренды

    Как настроить ISC DHCP-сервер на бесконечное время аренды для всех клиентов?

    Срок аренды Аренда DHCP может быть назначена почти любой длиной от нуля до бесконечности. Какая длина аренды имеет смысл для любого подсети или для любой установки варьируются в зависимости от вида обслуживаемых хостов.

    но dhcpd полностью не работает с нулевым значением времени аренды:

    Он явно не упоминается в man-странице, но устанавливает время аренды -1 в любом из вариантов, которые вы упоминаете,

    эффективно отключает время истечения срока аренды, поэтому их срок действия будет эффективно установлен «на бесконечность».

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

    Я бы предложил указать время аренды. Так где:

    default-lease-time 600; This being two minutes
    max-lease-time 7200; This being two hours

    по умолчанию-лиз время 86400; This being one day
    макс-лиз время 604800; This being one week

    Вы можете попробовать 2592000 which is 30 days ,

      Я бы этого не превысил.