Ошибка при установке dhcp сервера

5 Июля 2021

DHCP — это клиент-серверный протокол динамической конфигурации хоста (Dynamic Host Configuration Protocol), с помощью которого в ИТ-инфраструктуре сетевые параметры каждого нового устройства прописываются автоматически. Использование DHCP существенно упрощает работу системных администраторов в случаях расширения сети.

Что такое DHCP-сервер

На фото DHCP сервер.

DHCP-сервер представляет собой фоновый процесс, использующий в качестве транспорта UDP-порт 67 и ожидающий запросы от клиентов, которые хотят подключиться к сети. Применение технологии DHCP-сервера дает возможность прописывать на каждом клиенте:

• IP-адрес
• маску сети или подсети — адресацию сети или узла в пределах IP-адреса;
• шлюз — компонент, который создает соединение между двумя системами;
• адрес DNS-сервера, который отвечает на запросы о разрешении имен в Интернете;
• время (NTP) — сервис синхронизации внутреннего времени компьютера.

Существует три режима работы DHCP-сервера:

• ручное назначение, при котором IP, указанные в конфигурации хоста, назначаются фиксированным MAC-идентификатором При этом аппаратный адрес отдельного сетевого адаптера будет уникальным для каждого устройства. IP в данном случае назначаются на постоянной основе, но дополнительные клиенты в сеть подключены быть уже не могут;
• динамическое назначение, при котором сервер определяет в своих записях, как надолго IP-адрес может быть предоставлен клиенту. Установленное администратором время называется «временем аренды». По истечении срока аренды сервер DHCP возвращает адрес в пул, где он может быть перераспределен по мере необходимости;
• автоматическое назначение, при котором протокол динамической конфигурации хоста назначает определенный диапазон IP-адресов. Как только адреса «завязываются» друг на друга, они остаются связанными на бесконечное время. Недостатком этого способа является то, что новые клиенты не получат IP, если область полностью назначена.

DHCP доступен как для IPv4 (DHCPv4), так и для IPv6 (DHCPv6).

Механизм работы DHCP — сервера

Присвоение IP-адреса проводится через DHCP-сервер в несколько этапов:

• Discover (поиск сервера). Когда клиент загружается (или хочет присоединиться к сети), он запускает процесс с широковещательным (broadcast) сообщением DHCPDISCOVER со своим собственным MAC-адресом для обнаружения доступных серверов DHCPv4. Поскольку у клиента нет способа узнать подсеть, к которой он принадлежит, у сообщения DHCPDISCOVER адресом назначения IPv4-адреса будет 255.255.255.255. А поскольку у клиента еще нет настроенного адреса IPv4, то исходными IPv4-адресом будет 0.0.0.0. Сообщение DHCPDISCOVER обнаруживает серверы DHCPv4 в сети. Поскольку у клиента не имеется IPv4 информации при загрузке, он использует для связи с сервером широковещательные адреса 2 и 3 уровня;
• Offer (предложение сервера). Когда DHCPv4-сервер получает сообщение DHCPDISCOVER, он резервирует доступный IPv4-адрес для аренды или постоянного присвоения клиенту. Сервер также создает запись ARP, состоящую из MAC-адреса клиента и предоставленного IPv4-адреса. DHCP-сервер отправляет связанное сообщение DHCPOFFER запрашивающему клиенту, как одноадресную передачу (unicast), используя MAC-адрес сервера в качестве исходного адреса и MAC-адрес клиента в качестве адреса доставки;
• Request (запрос). Когда клиент получает DHCPOFFER с сервера, он отправляет обратно сообщение DHCPREQUEST. Это сообщение используется как для получения IP-адреса, так и для продления его аренды. Когда DHCPREQUEST используется для получения аренды, оно служит уведомлением о принятии выбранных и предложенных конкретным сервером параметров, и оповещением об отклонении предложений от других серверов. Многие корпоративные сети используют несколько DHCP серверов, и сообщение DHCPREQUEST отправляется в виде широковещательной передачи, чтобы информировать все серверы о принятом предложении.
• Acknowledge (подтверждение). При получении сообщения DHCPREQUEST сервер проверяет информацию об аренде с помощью ICMP-запроса на этот адрес, чтобы убедиться, что он уже не используется, и создает новую ARP запись для аренды клиента, а затем отвечает одноадресным DHCPACK-сообщением. Это сообщение является дубликатом DHCPOFFER, за исключением изменения поля типа сообщения. Когда клиент получает сообщение DHCPACK, он регистрирует информацию и выполняет поиск ARP для назначенного адреса. Если ответа на ARP нет, клиент знает, что адрес IPv4 действителен и начинает использовать его как свой собственный.

Что необходимо знать, чтобы произвести установку требуемого сервера

Для инсталляции службы DHCP Servers на компьютеры с ОС Windows необходимо выполнить:

• вход в «Установку и удаление программ», которая располагается в «Панели управления»;
• выбор вкладки «Добавление и удаление компонентов», которая находится на панели слева. После этого начнется запуск «Мастер компонентов» (потребуется нажать на кнопку «Далее»);
• выбор раздела «Сетевые службы» и нажатие на кнопку «Состав»;
• выделение записи «Dynamic Host Configuration» и щелчок по кнопке «Ок».

После этого потребуется нажать на клавишу «Готово», а потом на пункт «Закрыть».

Как настроить DHCP-сервер

После установки DHCP-сервера необходимо его настроить. Настройка сервера предполагает создание области — диапазона допустимых IP-адресов, доступных для аренды на клиентских компьютерах в сети. При этом рекомендуется создание для каждого сервера DHCP по крайней мере одной области, которая не пересекалась бы ни с одним другим сервером DHCP в определенной ИТ-инфраструктуре.

Создание новой области проходит поэтапно и включает:

• нажатие кнопки «Начните», указание программ и административных средств, а затем нажатие кнопки DHCP;
• в дереве консоли — щелчок правой кнопкой мыши на сервер DHCP, на котором необходимо создать новую область DHCP, а затем нажатие кнопки «New Scope»;
• в Мастере новых областей — нажатие кнопки «Далее», а затем ввод имени и описания области. Имя может быть любым, но достаточно описательным, для максимально полного определения цели области в сети. Нажатие кнопки «Далее»;
• ввод диапазона адресов, которые можно арендовать в рамках этой области. Например, можно использовать ряд IP-адресов от начального IP-адреса 192.168.100.1 до конечного адреса 192.168.100.100. Поскольку эти адреса даются клиентам, все они должны быть допустимы для вашей сети и не использоваться в настоящее время. При необходимости можно ввести новую подсетевую маску. Нажатие кнопки «Далее»;
• ввод любых IP-адресов, которые необходимо исключить из введенного диапазона. Эти адреса входят в диапазон указанных в предыдущем шаге адресов, и, возможно, уже были статически назначены различным компьютерам в организации. Как правило, контроллеры домена, веб-серверы, серверы DHCP, серверы системы доменных имен (DNS) и другие серверы имеют статически заданные IP-адреса. Нажатие кнопки «Далее»;
• введите количества дней, часов и минут до истечения срока аренды IP-адресов из этой области. Этот временной диапазон определяет, как долго клиент может держать арендованный адрес без его продления. Нажатие кнопки «Далее», а затем нажатие кнопки  «Да, я хочу настроить эти параметры сейчас». Это необходимо, чтобы расширить мастер включения параметров для наиболее распространенных параметров DHCP. Нажатие кнопки «Далее»;
• ввод IP-адреса шлюза по умолчанию. Этот шлюз должен использоваться клиентами, которые получают IP-адрес из создаваемой области. Нажатие «Добавить», чтобы добавить адрес шлюза по умолчанию в списке, а затем нажатие кнопки «Далее»;
• при использовании в сети DNS-сервера необходимо ввести доменное имя организации в поле «Родительский домен». После ввода имени DNS-сервера нажимается кнопка «Разрешить», чтобы сервер DHCP смог связаться с DNS-сервером и определить его адрес. Нажатие «Добавить», чтобы включить этот сервер в список DNS-серверов, которые назначены клиентам DHCP. Нажатие кнопки «Далее» и выполнение тех же действий. При использовании сервера службы Windows (WINS) необходимо добавить его имя и IP-адрес, после чего нажать кнопку «Далее»;
• нажатие кнопки «Да, я хочу активировать эту область сейчас», для активации области и разрешения клиентам получать аренду из нее, затем — нажатие кнопок «Далее» и «Готово».

После проведения настроек в дереве консоли необходимо выбрать имя сервера и нажать кнопку «Авторизуя» в меню «Действия».

Что выбрать — Linux или Windows

Настройка DHCP-сервера в Linux включает следующие этапы:

• установка пакета dhcp3-server с помощью команды $ sudo apt install isc-dhcp-server;
• после завершения установки-редактирование файла /etc/default/isc-dhcp-server для определения интерфейсов, которые будет использовать DHCPD для обработки DHCP-запросов, при помощи опции INTERFACES;
• настройка статического IP-адреса для созданного интерфейса;
• внесение информации, отправляемой клиентам, в основной файл конфигурации DHCP — /etc/dhcp/dhcpd.conf. В данном файле выделяются два типа данных: параметры, которые указывают, как выполнять задание (например, на какое время выделять адрес), выполнять ли его вообще (например, выделять ли адреса неизвестным клиентам) или какие параметры сетевой конфигурации отправлять DHCP-клиенту, и декларации, которые определяют топологию сети, описывают клиентов и предоставляемые им адреса, или применяют группу параметров к группе деклараций;
• определение настроек DHCP-сервера через открытие и редактирование файла конфигурации: $ sudo vi /etc/dhcp/dhcpd.conf. Для этого необходимо установить в начале файла глобальные параметры, которые будут действовать для всех деклараций (и которые можно менять в соответствии с конкретными задачами). Это: имя домена domain-name, имена DNS-серверов domain-name-servers, время аренды по умолчанию в секундах default-lease-time (если клиент не запросил его сам), максимальное время аренды в секундах max-lease-time и параметр authoritative, означающий «авторитетность» сервера в сегменте сети. Данный параметр нужен в том случае если клиент запросит неправильный IP-адрес — тогда случае сервер ответит ему отказом и предложит получить новый адрес;
• указание подсети локальной сети, в которой будет использоваться DHCP-сервер. Здесь будут использоваться следующие параметры: routers — IP-адрес маршрутизатора по умолчанию; subnet-mask — маска подсети; domain-search — имя домена; domain-name-servers — имена DNS-серверов; range — диапазон IP-адресов, выделяемый клиентам.

При этом стоит отметить, что использование Linux как альтернативы или полноценной замены ОС Windows может стать невыгодным, поскольку Linux не имеет серьезных преимуществ в выборе программ (в том числе бесплатных), в подключении устройств, в безопасности, надежности и скорости работы.

Виды ошибок при установке DHCP-сервера

К типичным ошибкам, возникающим при установке сервера DHCP и приводящим к сбою его настроек, относятся:

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

Плюсы и минусы использования DHCP

Использование DHCP-серверов позволяет автоматически создавать конфигурацию для новых пользователей и встраивать в ИТ-инфраструктуру практически любые устройства, подключаемые к сети — компьютеры, коммутаторы, смартфоны. При этом динамическое назначение IP-адресов снижает вероятность того, что два устройства будут иметь один и тот же IP-адрес (что бывает достаточно часто при использовании статических IP-адресов, назначенных вручную).

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

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

Дополнительная информация о DHCP

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

Кроме того, в сети одновременно с устройствами, имеющими динамические IP-адреса, доставленные через DHCP, могут использоваться статические IP-адреса.

Какое оборудование подходит для DHCP-сервера

Присвоедие IP-адресов не является трудоемкой задачей, по-этому для данного вида серверов можно использовать самое простое, надежное оборудование. На данную роль подходят такие модели как HPE Proliant DL20 gen10 и Dell R430. В компениях с численностью более 100 сотрудников, рекомендуем развернуть несколько DHCP-серверов, что позволит обеспечить высокую отказоустойчивость.

Сотрудники Сервер Гейт помогут подобрать вам правильное оборудование и сэкономить деньги, выбирая б/у серверы.

Наши рекомендации

Неверный информационный блок

Неверный информационный блок

Неверный информационный блок

Статьи по теме

Обновлено 18.11.2022

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами разобрали способы, как изменить формат файла, рассмотрели сценарии их применения. В сегодняшней публикации я бы хотел вам рассказать свой опыт по диагностике и устранению ошибок ID 20291 и ID 20292 «A BINDING-ACK message with transaction id: 764586 was received for IP address: 192.168.31.101 with reject reason» на отказоустойчивом DHCP сервере работающем на базе Windows Server 2012 R2 и выше, так как ошибка легко встречается и на Windows Server 2019. Давайте разбираться.

Описание ошибок ID 20291 и ID 20292

И так у меня есть домен Active Directory root.pyatilistnik.org. В домене я развернул отказоустойчивый DHCP сервер на двух серверах Windows Server 2012 R2 и Windows Server 2019. Настроил балансировку 50% на 50% и оба сервера находятся в активном режиме. В какой-то момент в журналах Windows стали фиксироваться вот такие ошибки:

или

Сама Microsoft подтвердила, что была выявлена данная проблема и объяснила при каких ситуациях, она может возникать:

• У вас есть два DHCP-сервера под управлением Windows Server 2012 R2 или выше
• Вы настраиваете серверы как отказоустойчивый кластер
• Вы создаете несколько областей DHCP и несколько IP-сетей
• Вы помещаете клиентский компьютер в одну из IP-сетей и подтверждаете, что он получает IP-адрес от одной из областей
• Вы перемещаете клиентский компьютер в другую IP-сеть
• Настройка задержки IPDT на оборудовании Cisco

Еще вы можете получать ошибки ID 20291 и 20292, когда ваш отказоустойчивый сервер DHCP выдает зарезервированный IP-адрес клиенту с другим MAC-адресом.

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

• Зарезервированный IP-адрес сдается в аренду зарезервированному клиенту.
• Этот клиент высвобождает IP-адрес (сообщение DHCP RELEASE), отправляя сообщения об освобождении DHCP. Это заставляет сервер DHCP отмечать IP-адреса как доступные.
• Другой клиент отправляет пакет DISCOVER на сервер DHCP. DHCP-сервер ПРЕДЛАГАЕТ зарезервированный IP-адрес этому клиенту, хотя MAC-адрес клиента не совпадает с указанным в резервировании.
• Теперь клиент отправляет пакет REQUEST на сервер.
• DHCP-сервер теперь отправляет обратно сообщение NAK, принимая во внимание, что это зарезервированный IP-адрес.
• Клиент снова запускает последовательность DORA (ACK REQUEST OFFER REQUEST), что приводит к тем же последствиям.
• Клиент постоянно зацикливается на цикле DISCOVER-OFFER-REQUEST-NAK и никогда не получает IP-адрес.
• Со временем это может привести к тому, что многие клиенты застрянут в цикле DISCOVER-OFFER-REQUEST-NAK и потеряют сетевое соединение.

Еще одна проблема, это когда некоторые IP-адреса постоянно застревают в состоянии BAD ADDRESS на одном из серверов отработки отказа DHCP, в то время как в активном состоянии на другом сервере, этого нет. Канал администрирования DHCP-сервера содержит события отклонения BINDING ACK 20291 и 20292 для этих IP-адресов. Последовательность событий, которая приводит к этой проблеме, следующая:

• DHCP-сервер переносится на DHCP-сервер 2012 R2 и выше без переноса записей аренды. Новый DHCP-сервер не имеет аренды в своей базе данных.
• Сервер настроен на аварийное переключение, приводящее к состоянию, когда ни у одного из отказоустойчивых партнеров нет записей аренды.
• Новый клиент запрашивает IP-адрес. Один из партнеров по отказоустойчивости сдает в аренду первый бесплатный IP-адрес в своей базе данных. Этот IP-адрес уже используется другим клиентом, который получил его с сервера DHCP перед миграцией.
• Клиент выполняет тест на обнаружение дублированного адреса, который не проходит. Клиент отклоняет аренду (DHCP DECLINE), и, следовательно, адрес помечается как BAD_ADDRESS на сервере DHCP.
• Такое же обновление отправляется на партнерский сервер, и этот сервер также помечает этот IP-адрес как BAD_ADDRESS.
• Когда клиент, которому был выдан IP-адрес, первоначально отправляет запрос RENEW одному из партнеров по восстановлению после сбоя, сервер отправляет ACK и помечает IP-адрес как активный.
• Теперь, когда обновление BAD_ADDRESS в активное состояние отправляется на партнерский сервер, обновление BINDING отклоняется, что приводит к несогласованности между двумя DHCP-серверами.

Обе эти проблемы были исправлены в накопительном обновлении для Windows Server 2012 в КБ 2919393, а для Windows Server 2012 R2 — KB2919355, а так же в KB3000850.

Методы устранения ошибок ID 20291 и ID 20292

• Установка обновлений KB2919355 и KB3000850 для Windows Server 2012 R2
• Удостовериться, что у вас включены ipv6
• Удостовериться, что все настройки сервера
• Пересоздание отработки отказа на области DHCP (Deconfigure failover)
• Отключение UAC
• Обновление прошивок и драйверов на конечных устройствах

Установка и проверка наличия обновлений KB2919355 и KB3000850

Первое, что вы должны сделать, это на каждом из DHCP серверов проверить наличие установленного обновления KB2919355 и KB3000850, эти обновления обязаны быть в Windows Server 2012 R2. Прочитать про обновления вы можете по этим ссылкам:

На серверах DHCP откройте командную строку или оболочку PowerShell и введите команду:

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

Если же у вас нет нужного обновления, то скачать его можно по ссылке:

Перед установкой обновления вам необходимо разорвать отношения отработки отказа на всех областях, как это делать я покажу ниже. Далее установить обновление, перезагрузиться и уже только потом вновь настраивать отработку отказа на области ip-адресов.

Проверьте, что у вас активны IPv6

У Microsoft есть интересная статья «Почему вы отключаете IPv6«, где автор приводит ряд доводов, в пользу того, что лучше не отключать в стеке TCP/IP протокол 6 версии.

Так, что обязательно убедитесь, что у вас активен на контроллерах домена, DNS, DHCP серверах протокол IPv6.

Проверка настроек на узлах отказоустойчивого DHCP

Как ни странно, но ошибки с конфликтом IP-адресов в виде BAD_ADDRESS и появляющихся событий ID 20291-20292 могут возникать из-за отсутствия каких-то параметром на одном из DHCP партнеров Failover Relationship. Простой пример на одном сервере у вас прилетают одни DNS сервера, а на другом их может и не быть. Обязательно проведите проверку параметров DHCP сервера на обоих серверах.

Вот пример сервера DC01.root.pyatilistnik.org

и сервер svt2019s01.root.pyatilistnik.org

Пересоздание отработки отказа на области DHCP

Данное действие в большинстве случаев может полностью исправить появление ошибок ID 20291 и ID 20292, но как показала практика не на 100%. Исправление, о котором упоминает Microsoft, относится к ноябрю 2014 года и уже очень давно установлено на моем сервере. Я никогда не замечали эту ошибку еще в 2014 году, когда было установлено исправление, поэтому я не смог сначала удалить отношения отработки отказа, а уже потом установить обновление на обоих узлах DHCP и перезапустить их, а затем восстановить отношения отработки отказа, согласно статье Microsoft. Но как показала практика достаточно просто пересоздать отказоустойчивость.

В моем примере сервера DHCP dc01.root.pyatilistnik.org и svt2019s01.root.pyatilistnik.org. Разрывать конфигурацию отработки отказа я буду на первом сервере DHCP (dc01.root.pyatilistnik.org). Откройте оснастку dhcp, сделать это можно через диспетчер серверов или через окно «Выполнить», введя там dhcpmgmt.msc.

В оснастке вам необходимо для каждой области, что у вас есть выполнить вот такое действие. Щелкните правым кликом по области и из контекстного меню выберите пункт «Удаление конфигурации отработки отказа (Deconfigure failover)«.

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

Вам подтвердят, что вы успешно разорвали конфигурацию отработки отказа (Deconfigure failover).

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

Хочу отметить, что данный подход хоть и разрывает конфигурацию отработки отказа, но не удаляет кэш и настройки отказоустойчивости между серверами, а так же позволяет удалять только по одному отношению. Так, что я вам для массового удаления и чтобы было максимально приближено к  рекомендациям Microsoft, советую пройти в свойства IPv4 на DHCP сервере и пройти на вкладку «Отработка отказа». Найдите нужные отношения между DHCP серверами и удалите эту связь. Так вы очистите все старые настройки DHCP и так же удалите отношения для всех областей.

Теперь создаем отказоустойчивые отношения заново. Для этого щелкаем по нужной области правым кликом и выберите пункт «Настройка отработки отказа (Configure failover)«.

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

При необходимости выберите сервер-партнера из списка авторизованных DHCP серверов.

Продолжаем настройку в мастере.

Далее вам необходимо произвести более тонкие настройки, среди них:

• Максимальное время упреждения клиента
• Режим
• Процент распределения нагрузки
• Сервер-партнер
• Секретный ключ
• Интервал переключения состояния

Завершаем настройку отработки отказа

После этих действий на серверах DHCP у вас должны пропасть ошибки ID20291 и ID20292.

Автоматическая репликация областей отказоустойчивого DHCP сервера Windows Server

Как я написал выше, Microsoft до сих пор не решило проблему автоматической репликации данных, о зарезервированных IP-адресах, даже в Windows Server 2019. Тут у вас два варианта, первый самый топорный, это ручной запуск на сервере, где были изменены настройки. Для этого запустите PowerShell и введите команду:

• dc01.root.pyatilistnik.org — сервер с которого мы будем реплицировать настройки (DHCP сервер-партнер)

В этом примере реплицируются все области отработки отказа службы DHCP-сервера, работающей на компьютере с именем dc01.root.pyatilistnik.org, в одну или несколько соответствующих партнерских служб DHCP-сервера на основе одного или нескольких отношений отработки отказа, в которых включены службы DHCP-сервера. Обратите внимание, что у вас появится запрос на подтверждение данного действия. Если хотите его пропускать, то необходимо добавить ключ -Force.

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

В этом примере реплицируется конфигурация всех областей, которые являются частью отношения отработки отказа с именем dc01.root.pyatilistnik.org-svt2019s01 в службе DHCP-сервера, работающей на компьютере с именем dc01.root.pyatilistnik.org, в службу DHCP-сервера партнера.

Предположим, что вам необходимо выполнить репликацию отработки отказа, только для определенных областей, для этого есть параметр -ScopeId, вот пример для моих областей:

Зная теперь основные команды, вы можете создать для себя автоматический сценарий при котором у вас будет происходить репликация. Тут все просто на поможет сценарий PowerShell и планировщик заданий, который будет срабатывать на определенное событие в журналах Windows.

Алгоритм действий:

• Создаете в Active Directory новую учетную запись, например dhcp-replication и делаете ее администратором на обоих DHCP серверах, кто входит в группу репликации. Как дать права на DHCP читайте по ссылке.

• Создаем небольшой скрипт dhcp-replication.ps1. Для этого вам просто нужно открыть PowerShell ISE и ввести там команду:

Далее вам просто нужно сохранить его в формате ps1.

• Создаем задание в планировщике Windows, которое по событию будет запускать ваш скрипт. Почему именно по событию, все просто, чтобы уменьшить количество бесполезного трафика и нагрузку на ваш сервер.

Когда вы производите новое резервирование IP-адреса на вашем DHCP сервере, у вас генерируется событие ID 106.

Генерируется оно журналом Microsoft-Windows-DHCP Server Events.

И так, откройте планировщик событий, самый быстрый способ, это в окне «Выполнить«, ввести taskschd.msc.

Щелкаем правым кликом и создаем новую, простую задачу.

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

Выбираем пункт «При занесении в журнал указанного события«.

Далее заполняем три пункта:

• Журнал — Microsoft-Windows-DHCP Server Events/Работает
• DHCP-Server
• Код события 106

1. 

Оставляем пункт «Запустить программу«.

Далее в поле:

• Программа или сценарий, вы указываете powershell.exe
• В поле «Добавить аргументы» введите текст -WindowStyle Hidden -File «C:Scriptsdhcp-replication.ps1». Где WindowStyle — это указание не показывать диалоговое окно, а атрибут —File указывает путь до вашего скрипта PowerShell. Мы такое уже разбирали в методах запуска скрипта PowerShell.

Смотрим сводную информацию и закрываем мастер настройки простого задания.

В результате ваше новое задание появится в списке.

Далее нам необходимо открыть свойства вашего задания и в параметрах безопасности выбрать созданного ранее пользователя, от имени которого будет запускаться задание, далее выставить опцию «Выполнить для всех пользователей» и поставить галку «Выполнить с наивысшими правами«.

Все теперь ждем появления события ID 106, вы его сами можете вызвать, путем резервирования IP-адреса. Как видим у меня успешно отработало мое задание и все резервированные IP-адреса на текущем сервере, благополучно отреплецировались на DHCP-партнера.

С событием установки резервирования (ID 106) мы разобрались, но еще есть и обратная операция, это удаление резервирования IP-адреса за определенным компьютером, и тут генерируется событие ID 107.

• Журнал Microsoft-Windows-DHCP Server Events/Работает
• Источник DHCP-Server

В итоге вам нужно создать такое же задание, как и в случае с ID 106, но сделать для ID 107 некоторые изменения. Теперь при включении и выключении аренды IP адреса, все области отработки будут автоматически согласованы и ошибок с ID 202091 и ID 20292 не должно быть.

Обновление прошивок и драйверов на конечных устройствах

Еще бывают случаи, когда у вас может быть старое оборудование, которое долго не обновлялись, например случай с Thinstation. Там в логах фигурировала ошибка, что тонкие клиенты запрашивали IP-адрес с ошибкой и вот  установив свежий PoniX, созданного на базе TS 5.1, полностью решило проблему.

Настройка задержки IPDT на оборудовании Cisco

В моем случае, все проделанные выше действия мне не помогли, и я обратился за помощью к своим коллегам из сетевого отдела и попросил посмотреть были ли какие-то работы с их стороны за последнее время, они подтвердили, что работы были, и мы начали совместно разбираться в итоге нашли вот такую вещь. Оказывается Cisco знает известную проблему «Duplicate IP Address 0.0.0.0«.

Инженеры Cisco очень часто получали сообщение, о дублированных IP адресах, напомню в терминалогии Windows DHCP, это Bad address, а в терминалогии Cisco, это «Duplicate IP Address 0.0.0.0″. 

В Microsoft Windows Vista и более поздних версиях Microsoft представила новый механизм, который используется для обнаружения дублирующих адресов в сети, когда происходит процесс DHCP. Этот новый механизм обнаружения описан в RFC 5227 .

В разделе 2.1.1 есть интересное описание, что

Cisco IOS использует зонд протокола разрешения адресов (ARP), полученный из адреса 0.0.0.0, чтобы поддерживать кэш отслеживания IP-устройств во время отслеживания IP-устройств, и функция, которая использует его, включена (например, 802.1x) на Коммутаторе Cisco. Зонд не заполняет запись отслеживания. Он используется для того, чтобы активировать и поддерживать запись в таблице после ее изучения. Этот IP-адрес затем используется, когда к интерфейсу применяется список контроля доступа (ACL), чтобы заменить исходный адрес в ACL клиентским IP-адресом. Эта функция важна всякий раз, когда списки доступа используются с 802.1x или любой другой функцией Flex-Auth на коммутаторах Cisco.

Если коммутатор отправляет зонд ARP для клиента, в то время как ПК с Microsoft Windows находится в фазе обнаружения повторяющихся адресов, то система Windows обнаружит проблему, как дублирующий IP-адрес и выдаст сообщение о том, что в сети был обнаружен дублированный IP-адрес 0.0.0.0. ПК не получает адрес, и пользователь должен либо вручную обновить адрес, или отключить и повторно подключиться к сети, либо перезагрузить компьютер, чтобы получить доступ к сети. Вот пример, как это выглядит.

Вот еще пример ситуации с дублированием адресов, зонд «keepalive», отправленный коммутатором, является проверкой уровня L2. Таким образом, с точки зрения коммутатора, IP-адреса, используемые в качестве источника в ARP, не важны: эта функция может использоваться на устройствах без настроенного IP-адреса, поэтому источник IP 0.0.0.0 не имеет значения.

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

Устранение ошибок Duplicate IP Address 0.0.0.0

Основная задача IPDT — отслеживать подключенные хосты (сопоставление MAC-адреса и IP-адреса). Для этого он отправляет зонды одноадресного протокола разрешения адресов (ARP) с интервалом по умолчанию 30 секунд; эти зонды отправляются на MAC-адрес хоста, подключенного по другую сторону канала, и используют уровень L2 в качестве источника по умолчанию — MAC-адреса физического интерфейса, из которого выходит ARP, и IP-адрес отправителя 0.0.0.0, на основе определения зонда ARP, указанного в RFC 5227.:

Проверка IP ARP включается автоматически при включении IPDT; он обнаруживает присутствие новых хостов при мониторинге пакетов ARP. Если динамическая проверка ARP включена, используются только проверенные пакеты ARP, чтобы обнаружить новые узлы для таблицы отслеживания устройств.

IP DHCP Snooping, если он включен, обнаруживает присутствие или удаление новых хостов, когда DHCP назначает или отзывает их IP-адреса.

IPDT — это функция, которая всегда была доступна. Однако в более свежих выпусках Cisco IOS его взаимозависимости включены по умолчанию. Это может быть чрезвычайно полезно, когда его база данных ассоциаций хостов IP/MAC используется для заполнения исходного IP динамических списков контроля доступа (ACL) или для поддержания привязки IP-адреса к тегу группы безопасности.

Зонд ARP отправляется при двух обстоятельствах:

• Ссылка, связанная с текущей записью в базе данных IPDT, переходит из состояния DOWN в состояние UP, и запись ARP заполняется.
• У ссылки уже в состоянии UP, связанной с записью в базе данных IPDT, истек интервал проверки.

Есть несколько методов, которые используются для решения этой проблемы. Вот список возможных обходных путей:

• Наиболее эффективный метод, который используется для предотвращения этой проблемы, состоит в том, чтобы настроить коммутатор так, чтобы он отправлял не RFC-совместимый зонд ARP, для получения зонда от виртуального интерфейса коммутатора (SVI) в VLAN, где находится ПК. Если для VLAN настроен SVI и используется любая из двух следующих команд, то IP-адрес отправителя в IPDT никогда не будет 0.0.0.0. Таким образом, наверняка ошибка дублированного IP-адреса не произойдет.

Эта конфигурация в настоящее время не вызывает сообщение об ошибке обнаружения дублированного адреса в Microsoft Windows. Предупреждение этого метода заключается в том, что SVI должен существовать на каждом коммутаторе в каждой VLAN, где находятся клиенты Microsoft Windows, использующие DHCP. Этот метод трудно масштабировать, поэтому Cisco рекомендует использовать задержку зондирующего отслеживания IP-устройства в качестве основного метода. SVI в настоящее время недоступен на платформе коммутатора серии 6500. Эта команда была реализована в Cisco IOS версии 12.2 (55) SE на платформах коммутаторов серии 2900, 3500 и 3700, а также в версии 15.1 (1) SG на платформе коммутатора серии 4500.

Вот формат команды для более новых версий кода:

Эта последняя команда CLI была введена в Cisco IOS версии 15.2 2. Идентификатор был добавлен для того, чтобы разрешить пользовательский IP-адрес источника запроса ARP, вместо требования использовать IP-адрес источника по умолчанию 0.0.0.0. Новая глобальная команда

позволяет пользователю использовать адрес хоста 0.0.0.x в подсети, чтобы избежать любых проблем с дублирующимся IP-адресом. Если для конкретной VLAN нет SVI, вместо источника будет использоваться резервный host-ip.

Основной альтернативой, отличной от SVI, которая используется для решения этой проблемы, является задержка зонда от коммутатора, чтобы у Microsoft Windows было время завершить обнаружение дублированного IP-адреса. Это эффективно только для портов доступа и сценариев соединения. Введите эту команду для задержки зонда:

ip device tracking probe delay 10

В RFC указывается десятисекундное окно для обнаружения дублирующихся адресов, поэтому, если вы задержите проверку устройства, это решит проблему почти во всех случаях. В дополнение к задержке проверки задержка также сбрасывается, когда коммутатор обнаруживает проверку с ПК. Например, если таймер зонда отсчитал до пяти секунд и обнаружил зонд ARP с ПК, таймер сбрасывается до десяти секунд. Это окно может быть дополнительно уменьшено, если вы также включите отслеживание DHCP, так как это также сбрасывает таймер. В редких случаях ПК отправляет зонд ARP за миллисекунды до того, как коммутатор отправляет свой зонд, который все еще вызывает сообщение с дублированным адресом для конечного пользователя. Эта команда была представлена ​​в Cisco IOS версии 15.0 (1) SE на платформах коммутаторов серии 2900, 3500 и 3700, в версии 15.0 (2) SG на платформе коммутатора серии 4500 и в версии 12.

Дополнительные методы вы так же можете посмотреть по ссылкам:

1. https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html
2. https://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html

На этом у меня все, мы разобрали причину дублированных IP-адресов в DHCP Windows, устранили ошибки ID 20291 и ID 20292. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.