Что 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-ответ для клиента. Новый вопрос:

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

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

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

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

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

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

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

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

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

New-DHCP: я говорю нет.

Старый-DHCP: я говорю да.

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

Если больше ничего не помогает - 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.

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

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

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

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

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

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

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

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

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

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

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

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