Ошибки 20291 и 20292 на DHCP в Windows Server

Добрый день! Уважаемые читатели и гости одного из крупнейших 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

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

Далее в поле:

• Программа или сценарий, вы указываете powershell.exe
• В поле "Добавить аргументы" введите текст -WindowStyle Hidden -File "C:\Scripts\dhcp-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.