Вопрос: Что DHCP-клиент считает «лучшим» ответом?


У нас есть учебные комнаты, где обычно устанавливается Windows XP (через PXE). «Обычная» инфраструктура DNS / DHCP - это Windows-серверы. Учебная комната имеет свою собственную VLAN (отличную от Windows-серверов), поэтому наиболее предпочтительным является IP-помощник для DHCP-запросов, активных на маршрутизаторе Cisco, к которому подключены все компьютеры из этой комнаты.

Теперь мы хотели конвертировать некоторые из ПК в Linux. Идея заключалась в следующем: Поместите наш собственный ноутбук с DHCP-сервером в VLAN комнаты и переопределите «нормальный» ответ DHCP. Идея заключалась в том, что это должно работать, поскольку непосредственно подключенный DHCP-сервер в этой VLAN должен иметь более быстрое время отклика, чем «обычный» DHCP-сервер, расположенный на некотором расстоянии от этой VLAN.

Оказалось, что это не сработало. Мы должны были вручную освободить аренду на исходном сервере DHCP, чтобы заставить его работать.

На ноутбуке мы видели, как клиент запрашивает IP-адрес, а «наш» dhcp отправляет NACK на запрос Windows IP, прежде чем мы предложили наш собственный ответ.

Старый вопрос: Почему это не получилось так, как ожидалось? Что заставляет ПК восстановить прежнюю аренду?

Обновить 2012-08-08:

Вопрос о возврате объяснен в DHCP-RFC. Теперь это объясняет, почему ПК восстанавливает свою прежнюю аренду.

Теперь мы освобождаем IP-адрес от Windows-DHCP-сервера, прежде чем повторить попытку.

Опять же - побеждает Windows-DHCP-сервер.

Я подозреваю, что существует некоторый алгоритм для dhcp-клиента, который определяет «лучший» dhcp-ответ для клиента. Новый вопрос:

Как клиент выбирает «лучший» ответ?


13
2017-08-03 20:23


Источник


где вы выпускаете IP-адрес? в клиенте Windows или в загрузочном агенте PXE? - longneck
@longneck нам пришлось освободить адрес на сервере Windows-DHCP, чтобы он работал. - Nils
Странный способ, например, задать новый вопрос, надеюсь, что вы - Daniel Li


Ответы:


Поставщик, даже прошивка, определяет, как клиент реагирует на несколько ответов DHCP.

Варианты, которые я видел за эти годы:

1) Примите первое, независимо от того, является ли это ACK или NACK.

2) Возьмите первый ACK, полностью игнорируйте NACK.

3) Возьмите последний ACK, полученный в течение заданного интервала времени (обычно 5-10 секунд).

Пример: Несколько лет назад у нас были проблемы с MFP Ricoh.
У нас было 2 сервера DHCP. Один из них предоставил адреса, другие - только дополнительные параметры DHCP. Второй сервер всегда отвечал первым.
Использованный вариант Ricoh 1), даже если 1-е предложение содержит только параметры DHCP. Ricoh изменил его на вариант 2) с обновлением прошивки после того, как мы объяснили им проблему.


4
2017-08-29 15:00



OFFER пакеты - это то, что должна решать клиентская система. ACK а также NACK пакеты отправляются только в ответ на REQUEST, что происходит только после того, как клиент «решил», который предлагает пойти дальше. Хотя это довольно крутая ошибка с принтерами! - Shane Madden♦
@ShaneMadden Это правильно, но я видел многочисленные случаи, когда клиенты отправляют запрос в ответ на предложения BOTH, а затем действуют на ответы, как я описал. Прошло некоторое время, так как я подробно рассмотрел это. Я четко помню, как NT4, W2K и XP были виновны в этом. Рико сделал тоже. Они запускали ядро ​​Linux 2.2 и сетевой стек. - Tonny


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

ПК: О, мир, я могу использовать 192.168.1.123?

New-DHCP: Я говорю «нет».

Old-DHCP: Я говорю «да».

ПК: Кто-то сказал «да»! Сладкий, я буду использовать его!


9
2017-08-03 20:47



После холодной загрузки ПК разговор начинается с «мой MAC - XYZ - пожалуйста, дайте мне IP». Затем оба DHCP-сервера предлагают IP-адреса ... Единственное отличие состоит в том, что он имеет активную аренду на одном из серверов, но это просто перспектива сервера. - Nils
если у ПК уже был IP-адрес. если ранее он имел IP-адрес, назначенный DHCP-сервером, он попросит его использовать сначала, прежде чем запрашивать другой адрес. - longneck
@longneck, где будет храниться этот IP-адрес на ПК? - Nils
с головы до головы, я не знаю. но правильный способ его очистки - использовать ipconfig / release - longneck
@longneck - операционная система задает вопрос в среде PXE, где мы предполагаем, что BIOS загрузки не имеет воспоминаний о предыдущих загрузках или IP-адресах - Mark Henderson♦


Если ничего больше не помогает - RTFM (прочитайте точное руководство). В этом случае первым был хит.

RFC 2131 описывает DHCP-операции.

В разделе 1.6 указано, что DHCP должен:

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

Теперь интересным вопросом является то, как эта цель дизайна достигается на клиенте, который не знает своего прошлого. Раздел 3.2 описывает:

3.2 Взаимодействие клиент-сервер - повторное использование ранее выделенной сети       адрес

Если клиент помнит и желает повторно использовать ранее выделенные
  сетевой адрес, клиент может отказаться от некоторых шагов
  описанных в предыдущем разделе. График временной шкалы на рисунке 4
  показывает временные отношения в типичном взаимодействии клиент-сервер   для повторного использования клиентом ранее выделенного сетевого адреса.

  1. Клиент транслирует сообщение DHCPREQUEST в своей локальной подсети.     Сообщение содержит сетевой адрес клиента в     «запрошенный IP-адрес». Поскольку клиент не получил     сетевой адрес, он НЕ ДОЛЖЕН заполнять поле «ciaddr». BOOTP     ретрансляторы передают сообщение на DHCP-серверы не на одном и том же     подсети. Если клиент использовал «идентификатор клиента», чтобы получить его     адрес, клиент ДОЛЖЕН использовать один и тот же «идентификатор клиента» в     Сообщение DHCPREQUEST.

  2. Серверы со знанием параметров конфигурации клиента     ответьте клиенту сообщение DHCPACK. Серверы НЕ ДОЛЖНЫ     проверьте, что сетевой адрес клиента уже используется;     клиент может ответить на сообщения ICMP Echo Request на этом этапе.

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

  1. Клиент: DHCREQUEST (MAC-адрес, широковещательная передача будет передаваться в локальном широковещательном домене - здесь локальная VLAN и через IP-помощник на Windows-DHCP-сервер)
  2. Laptop-DHCP-сервер: DHCPOFFER
  3. Windows-DHCP-сервер: Эй, я уже знаю вас - DHCPACK
  4. Клиент: О, у меня есть два ответа. Тот, кто меня уже знает. Прохладный, я возьму это

С этого момента Клиент-DHCP-сервер игнорируется Клиентом.

Таким образом, решение в нашем случае, вероятно, будет (я обновлю это, когда мы его протестируем):

  1. Убедитесь, что Клиент выключен
  2. Отключите DHCP-сервер на ноутбуке, поддельный клиент-MAC на ноутбуке, DHCP-Request
  3. Выпуск IP
  4. Восстановите исходный IP и MAC, включите DHCP-сервер
  5. Включите клиента и выполните PXE-загрузку ...

3
2017-08-04 21:19





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

В любом случае, в отношении того, как клиент выбирает, с каким предложением идти, в случае, если у него нет текущей аренды: это зависит от клиента, но в каждой реализации клиента DHCP, о которой я знаю, это простая гонка ,

RFC 2131 охватывает это:

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

Есть Проект IETF там, который кажется мертвым, который добавил бы конфигурацию к процессу выбора, а также упоминает тусклые клиентские реализации (более десяти лет назад, но не так много изменилось):

На практике реализация политики большинства поставщиков здесь очень проста (например, первое предложение получено или получено первое приемлемое предложение) и является «жестко запрограммированным» (то есть неконфигурируемым).

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


3
2017-08-26 21:20



Вы считаете, что «приемлемое» предложение зависит от поставщика на стороне dhcp-client? Поскольку в нашем случае это не «первое» предложение, оно должно быть чем-то другим - поведение довольно детерминированное, хотя я все еще думаю, что за этим стоит общий стандарт. - Nils
@Nils. Вы абсолютно уверены, что сервер Windows не получает ответа на клиента перед ноутбуком в одной комнате? Интуитивно кажется, что ноутбук должен победить в этой гонке, но это может и не быть тем, что происходит. - Shane Madden♦
Думаю, мне придется проследить это на сетевом уровне (с помощью wirehark), чтобы увидеть, что там происходит. Возможно, на зеркальном порту этого клиента ... - Nils