У нас есть учебные комнаты, где обычно установлена Windows XP (через PXE). «Обычная» инфраструктура DNS / DHCP - это Windows-серверы. У учебной комнаты есть своя собственная VLAN (отличная от серверов Windows), поэтому наиболее вероятно, что на маршрутизаторе Cisco, к которому подключены все ПК из этой комнаты, есть помощник IP для запросов DHCP.
Теперь мы хотели вместо этого перевести некоторые ПК на Linux. Идея заключалась в следующем: поместите наш собственный ноутбук с DHCP-сервером в VLAN комнаты и переопределите «нормальный» ответ DHCP. Идея заключалась в том, что это должно работать, поскольку непосредственно подключенный DHCP-сервер в этой VLAN должен иметь более быстрое время отклика, чем «нормальный» DHCP-сервер, расположенный на расстоянии нескольких переходов от этой VLAN.
Оказалось, что это не сработало. Нам пришлось вручную освободить аренду исходного DHCP-сервера, чтобы он заработал.
На портативном компьютере мы видели, что клиент запрашивает IP-адрес, и «наш» DHCP-сервер отправлял NACK на IP-запрос Windows, до этого мы предлагали наш собственный ответ.
Старый вопрос: почему это не сработало так, как ожидалось? Что заставляет ПК вернуть прежнюю аренду?
Обновить 2012-08-08:
Проблема восстановления была объяснена в DHCP-RFC. Теперь это объясняет, почему ПК возвращается в прежнюю аренду.
Теперь мы освобождаем IP от Windows-DHCP-сервера, прежде чем дать ему еще одну попытку.
Опять же - Windows-DHCP-сервер побеждает.
Подозреваю, что для dhcp-клиента существует какой-то алгоритм, который определяет "лучший" dhcp-ответ для клиента. Новый вопрос:
Как клиент выбирает «лучший» ответ?
Если предположить, что маршрутизатор по-прежнему действует как ретранслятор DHCP и пересылает запрос на ваш исходный сервер, то причина, по которой он это сделал, заключается просто в том, что DHCP-сервер Windows сказал ему продолжить и использовать IP. В этом случае DHCPNACK от нового сервера не имеет значения, поскольку клиент DHCP будет рассматривать все ответы, и, поскольку он получил предложение от окна DHCP Windows, он совершенно счастлив его использовать.
ПК: Привет, мир, могу я использовать 192.168.1.123?
New-DHCP: Я говорю нет.
Старый DHCP: Я говорю да.
ПК: Кто-то сказал да! Милая, я воспользуюсь этим!
То, как клиент реагирует на несколько ответов DHCP, зависит от производителя, даже от прошивки.
Варианты, которые я видел за эти годы:
1) Примите первое, независимо от того, является ли это ACK или NACK.
2) Возьмите первый ACK, полностью игнорируя NACK.
3) Возьмите последний ACK, полученный в течение установленного временного интервала (обычно 5-10 секунд).
Пример. Несколько лет назад у нас были проблемы с МФУ Ricoh.
У нас было 2 DHCP-сервера. Один предоставил адреса, другой - только дополнительные параметры DHCP. Второй сервер всегда отвечал первым.
Ricoh использовал вариант 1), даже если первое предложение содержало только параметры DHCP. Ricoh изменил его на вариант 2) с обновлением прошивки после того, как мы объяснили им проблему.
Если ничего не помогает - RTFM (прочтите прекрасный мануал). В данном случае попадание было первым.
RFC 2131 описывает DHCP-операции.
В разделе 1.6 говорится, что DHCP должен:
Сохранять конфигурацию DHCP-клиента при перезагрузке сервера, и, когда это возможно, DHCP-клиенту должны быть назначены те же параметры конфигурации, несмотря на перезапуски механизма DHCP,
Теперь возникает интересный вопрос, как эта цель дизайна достигается на клиенте, который ничего не знает о своем прошлом. Раздел 3.2 описывает:
3.2 Взаимодействие клиент-сервер - повторное использование ранее выделенного сетевого адреса
Если клиент помнит и желает повторно использовать ранее выделенный
сетевой адрес, клиент может пропустить некоторые шаги
описано в предыдущем разделе. Временная диаграмма на рисунке 4
показывает временные отношения при типичном взаимодействии клиент-сервер для клиента, повторно использующего ранее назначенный сетевой адрес.
Клиент передает сообщение DHCPREQUEST в свою локальную подсеть. Сообщение включает сетевой адрес клиента в опции «запрошенный IP-адрес». Поскольку клиент не получил свой сетевой адрес, он НЕ ДОЛЖЕН заполнять поле «ciaddr». Агенты ретрансляции BOOTP передают сообщение DHCP-серверам, находящимся в другой подсети. Если клиент использовал «идентификатор клиента» для получения своего адреса, клиент ДОЛЖЕН использовать тот же «идентификатор клиента» в сообщении DHCPREQUEST.
Серверы со знанием параметров конфигурации клиента отвечают клиенту сообщением DHCPACK. Серверам НЕ СЛЕДУЕТ проверять, что сетевой адрес клиента уже используется; в этот момент клиент может ответить на сообщения ICMP Echo Request.
Таким образом, DHCP-сервер, имеющий активную аренду, получает приоритет благодаря использованию ярлыка в protcol.
С этого момента клиент-DHCP-сервер игнорирует.
Таким образом, решение в нашем случае, вероятно, будет таким (я обновлю его, когда мы его действительно протестируем):
Новый вопрос, вероятно, должен быть в другом вопросе - название вопроса совсем не соответствует большей части вопроса.
В любом случае, что касается того, как клиент выбирает, какое предложение использовать, в случае, если у него нет текущей аренды: это зависит от клиента, но в каждой реализации клиента DHCP, о которой я знаю, это простая гонка .
RFC 2131 охватывает это:
Клиенты DHCP могут использовать любую стратегию для выбора DHCP-сервера среди тех, от которых клиент получает сообщение DHCPOFFER.
Есть Проект IETF там, который кажется мертвым, который добавил бы настраиваемость к процессу выбора, а также упоминает тусклые клиентские реализации (более десяти лет назад, но мало что изменилось):
На практике политика большинства поставщиков здесь очень проста (например, первое полученное предложение или получено первое приемлемое предложение) и является «жестко запрограммированной» (т. Е. Не настраиваемой).
Наличие двух DHCP-серверов, обслуживающих одну и ту же сеть с разной конфигурацией, приводит только к гонкам, что нежелательно с точки зрения надежности или предсказуемости. На самом деле нет причин, по которым ваш единственный DHCP-сервер не может предоставить то, что вам нужно.