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

Обновлено 18.11.2022

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

Ошибка с ID 20292: A BINDING-ACK message with transaction id: 1017818 was received for IP address: 192.168.31.111 with reject reason: (Reject Reason Unknown ) from partner server: dhcp02.root.pyatilistnik.org for failover relationship: dhcp01-dhcp02.

 id 20292 Ошибка с ID 20292: A BINDING-ACK message with transaction id: 1017818 was received for IP address: 192.168.31.111 with reject reason

или

Ошибка с ID 20291: A BINDING-ACK message with transaction id: 172671 was sent for IP address: 192.168.31.180 with reject reason: (Outdated binding information) to partner server: dhcp02.root.pyatilistnik.org for failover relationship: dhcp01-dhcp02.

Ошибка с ID 20291: A BINDING-ACK message with transaction id: 172671 was sent for IP address

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

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

Самый простой пример, когда компьютер перемещается из одной подсети в другую, это при переключении ноутбука с проводного интернета на WiFi

Еще вы можете получать ошибки 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-серверами.

Посмотреть BAD_ADDRESS на 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. Прочитать про обновления вы можете по этим ссылкам:

  • https://support.microsoft.com/en-us/help/2955135/event-id-20291-is-logged-in-the-system-log-when-a-client-computer-is-m
  • https://docs.microsoft.com/ru-ru/archive/blogs/teamdhcp/dhcp-failover-fixes-in-kb-2919393-for-windows-server-2012-and-kb-2919355-for-windows-server-2012-r2

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

systeminfo | findstr KB*

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

Проверка установленных KB2919355 и KB3000850

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

Скачать KB3000850 https://www.microsoft.com/en-us/download/details.aspx?id=44975

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

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

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

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

https://blogs.technet.microsoft.com/yongrhee/2018/02/28/stop-hurting-yourself-by-disabling-ipv6-why-do-you-really-do-it-2/

ID 20291 id 20292 проверка включения ipv6

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

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

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

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

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

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

ID 20291 id 20292 проверка настроек DHCP

Пересоздание отработки отказа на области 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)".

Отключение Удаление конфигурации отработки отказа (Deconfigure failover)

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

Отключение Deconfigure failover на DHCP сервере

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

Устранение ошибок репликации DHCP

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

журнал удаления Deconfigure failover

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

Тут вам заново придется настроить секретный ключ, пропорции ip адресов которые раздает DHCP сервер и так далее

Удаление кэша отработки отказа области DHCP

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

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

создаем отказоустойчивые отношения между DHCP

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

Configure failover на DHCP серверах

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

выбор dhcp сервера для отработки отказа

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

мастер по настройке Configure failover

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

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

Подробные настройки отработки отказа в мастере

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

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

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

Успешно устраненные ошибки 20291 и 20292

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

Из этого два вывода, первый это делать все настройки исключительно на первом сервере, как советует Microsoft, а второе автоматически их реплицировать на второй сервер

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

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

Invoke-DhcpServerv4FailoverReplication -ComputerName dc01.root.pyatilistnik.org

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

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

Invoke-DhcpServerv4FailoverReplication -ComputerName dc01.root.pyatilistnik.org -Force

Команда Invoke-DhcpServerv4FailoverReplication -ComputerName dc01.root.pyatilistnik.org

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

Invoke-DhcpServerv4FailoverReplication -ComputerName dc01.root.pyatilistnik.org -Name dc01.root.pyatilistnik.org-svt2019s01

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

Репликация отработки отказа через PowerShell

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

Invoke-DhcpServerv4FailoverReplication -ComputerName dc01.root.pyatilistnik.org -ScopeId 192.168.31.0,192.168.32.0 -Force

 

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

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

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

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

Создание учетной записи для репликации областей отработки отказа

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

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

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

Создание PowerShell скрипта для репликации DHCP

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

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

ID 106: Резервирование: [[192.168.31.109]] для IPv4 настроено в области [[192.168.31.0]192.168.31.0] через ROOT\Администратор.

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

Событие с кодом ID 106

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

как открыть планировщик заданий

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

Создание задания по репликации в DHCP

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

Заполнение поля имени задачи в планировщике

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

При занесении в журнал указанного события

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

  • Журнал - Microsoft-Windows-DHCP Server Events/Работает
  • DHCP-Server
  • Код события 106
  1. создание задания в планировщике Windows по репликации областей DHCP

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

Запуск программы через планировщик Windows

Далее в поле:

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

Заполняем аргументы для запуска скрипта PowerShell

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

Завершение создания задания в планировщике

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

Список заданий в планировщике

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

Настройка учетной записи для запуска задания в планировщике

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

Успешная репликация областей отработки в DHCP

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

ID 107: Резервирование: [[192.168.31.118]] для IPv4 удалено в области [[192.168.31.0]192.168.31.0] через ROOT\Администратор.

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

Событие с кодом ID 107

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

Событие с кодом ID 107

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

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

http://e1fer.blogspot.com/2016/08/20291-binding-ack-dhcp-failover-windows.html

Настройка задержки 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 .

http://tools.ietf.org/html/rfc5227

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

Кроме того, если в течение этого периода хост получает какой-либо ARP-зонд, где "целевой IP-адрес" пакета является адресом, для которого выполняется поиск, а "аппаратный адрес" пакета не является аппаратным адресом какого-либо из интерфейсов хоста, то хост ДОЛЖЕН аналогичным образом рассматривать это как конфликт адресов и сообщать об ошибке агенту настройки, как описано выше. Это может произойти, если два (или более) хоста по какой-либо причине случайно сконфигурированы с одним и тем же адресом, и оба одновременно находятся в процессе поиска этого адреса, чтобы определить, можно ли его безопасно использовать.

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. ПК не получает адрес, и пользователь должен либо вручную обновить адрес, или отключить и повторно подключиться к сети, либо перезагрузить компьютер, чтобы получить доступ к сети. Вот пример, как это выглядит.

Duplicate IP Address 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.:

В этом документе термин "ARP Probe" используется для обозначения пакета запроса ARP, транслируемого по локальной линии связи с «нулевым IP-адресом отправителя». "Аппаратный адрес отправителя" ДОЛЖЕН содержать аппаратный адрес интерфейса, отправляющего пакет. Поле "IP-адрес отправителя" ДОЛЖНО быть установлено на все нули, чтобы избежать загрязнения кэшей ARP на других хостах по тому же каналу в случае, когда оказывается, что адрес уже используется другим хостом. Поле «целевой IP-адрес» ДОЛЖНО быть установлено на проверяемый адрес. ARP Probe передает как вопрос («Кто-нибудь использует этот адрес?»), так и подразумеваемое утверждение («Это адрес, который я надеюсь использовать»).

Проверка 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-адреса не произойдет.

ip device tracking probe use-svi

Эта конфигурация в настоящее время не вызывает сообщение об ошибке обнаружения дублированного адреса в 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.

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

ip device tracking probe auto-source fallback <host-ip> <mask> [override]

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

ip device tracking probe auto-source fallback 0.0.0.x 255.255.255.0 override

позволяет пользователю использовать адрес хоста 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.

Автор - Сёмин Иван

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

  1. придурок:

    не отрабатывает чётко, в частности не переносятся dhcp options такие как 003 router, да даже бл мак адрес не переносится, шляпа кароч ето всё, мы так уже попали один раз думали что всё збс реплицируется, а потом сервер партнёр как попрёр неправильные шлюза раздавать, кароч луче убедиться вручную что всё збс

  2. Иван Семин:

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *