Как клиенты DHCP знают, какой из нескольких DHCPOFFERS принять?

Представьте, что у нас есть сеть, как на картинке. Шесть хостов в одной сети уровня 2, без VLAN. Предполагается, что сеть будет разделена на две подсети с одним DHCP-сервером в каждой. Серверы DHCP имеют фиксированные IP-адреса, поэтому они, очевидно, знают, к какой подсети они принадлежат.

Затем подключаются новые клиенты. Они ничего не знают о том, в какой подсети они должны находиться, и отправляют свой DHCPDISCOVER в широковещательную рассылку Ethernet 255.255.255.255, поэтому она отправляется на оба DHCP-сервера. Оба сервера отвечают предложением. Теперь вот мой вопрос: как клиент узнает, какой DHCPOFFER он должен принять?

networking dhcp

— Майкл Ниманд
источник

Сравните этот вопрос и ответы там.

— Камиль Мачоровский

Вот еще один связанный с этим вопрос .

— Касперд

«Ethernet-широковещание 255.255.255.255» - это широковещательный IP-адрес для локальной сети, а не адрес Ethernet. Исходные сообщения DHCP DISCOVER также могут использовать широковещательный адрес Ethernet ff: ff: ff: ff: ff: ff, но на самом деле это не одно и то же.

— ilkkachu

Ответы:

Самый простой ответ - первым пришел, первым обслужен.

Если у вас было несколько VLAN, и 10.10.10.0/24 находились в другой VLAN, отличной от 10.10.20.0/24 - широковещательная передача не пересекает VLAN.

Если DHCP-сервер находится в отдельной VLAN для клиентов, iphelper на интерфейсе маршрутизации между vlans направит широковещательную рассылку в правильное местоположение.

В вашем сценарии, где у вас есть две отдельные сети в одной VLAN (или их отсутствие), обслуживающие разные подсети - это гонка.

DHCP обслуживает с использованием следующих транзакций:

Обнаружение DHCP (DHCPDISCOVER) - широковещательная рассылка клиента - «Есть ли там DHCP-сервер?»
Предложение DHCP (DHCPOFFER) - сервер клиенту - «Да, я здесь и доступен!»
Запрос DHCP (DHCPREQUEST) - Клиент-сервер "Отлично, могу ли я иметь адрес, пожалуйста?"
Подтверждение DHCP (DHCPACK) - сервер клиенту «Конечно, вот IP-адрес, маска, шлюз, некоторые DNS / WINS-серверы, сервер времени и все остальное, настроенное для вашей области»

Все это происходит на UDP-портах 67 для сервера и 68 для клиента.

Как только шаг 2 будет достигнут - клиент перестанет «слушать» ответы других DHCP-серверов - он счастлив иметь дело с первым сервером, чтобы уделить ему некоторое внимание.

В качестве примечания: на самом деле существует хорошо известная серия атак DoS (отказ в обслуживании), которые злоупотребляют этим правом. Злоумышленник подключает устройство, которое отвечает и отправляет пакеты DHCPOFFER, а затем не отправляет DHCPACK, когда его просят ... снова и снова. Существует также еще одна DoS-атака, когда «поддельные» DHCP-серверы предлагают адреса, которые нельзя маршрутизировать или которые конфликтуют с другими IP-адресами, которые прослушиваются, чтобы связываться с сетями.

— Fazer87
источник

И поэтому короткий ответ на вопрос «Но тогда как мне запустить несколько подсетей в одном сегменте уровня 2?» это « Вы не делаете ». (Да, есть способы, но это не то, что вы обычно должны делать. Один домен уровня 2 = одна подсеть.)

— user1686

Спасибо вам, ребята, что действительно сошлись со мной. Мне всегда было интересно, как это возможно, но это просто не так. Итак, вот что нужно сделать: есть ли маршрутизатор / коммутатор 3-го уровня между подсетями или сегментом с VLAN, я прав?

— Майкл Ниманд,

В общем, да, вам нужны VLAN или физическая сегментация. Совместное использование домена L2 было бы выполнимо, только если оба ваших DHCP-сервера были ограничены обработкой «известных» клиентов (например, с помощью списка «статической аренды» с разрешенными MAC-адресами).

— user1686

Я думаю, что вы могли бы дать каждому DHCP-серверу белый список MAC-адресов и контролировать, какой клиент получает адрес с какого сервера таким образом.

— Даррен

@ Grawity, вы можете легко запустить несколько IP-подсетей в одном сегменте уровня 2, если подсети равны, и вам все равно, какой клиент получает адрес, из какой подсети. У вас просто есть один DHCP-сервер, который выдает адреса из обоих блоков, и один маршрутизатор, который действует как шлюз для обоих блоков (с адресом в каждом). Выполнено. Сказать «ты не» - совершенно неправильно.

— ilkkachu

Существующий ответ от @ Fazer87 в общих чертах правильно на практике , и я рекомендую upvoting и принять его. Этот ответ исследует мелкую деталь немного точнее.

Оба DHCP-сервера могут ответить сообщением DHCPOffer.

Клиент DHCP может принимать их по принципу «первым пришел - первым обслужен». Однако такой подход не требуется.

RFC2131 определяет:

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

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

Как правило, подход «первым пришел - первым обслужен» даст вам предложение, которое не прошло через несколько переходов между устройствами (ретрансляции BOOTP), поэтому это хороший протокол, которым нужно следовать, если у вас нет причин для беспокойства.

Я был в одном проекте, где пользовательское устройство предпочло бы DHCPOffer, который включал сервер TFTP, где можно было найти обновленную прошивку.

— Oddthinking
источник

... или если один сервер предложил адрес, который клиент уже использовал ранее и хотел сохранить

— ilkkachu

@ilkkachu: Да, в теории, но есть более эффективные механизмы для этого (как обновление резервирования до истечения срока его действия со старым сервером DHCP, так и отправка DHCPDiscovery, запрашивающего старый IP-адрес), так что это вряд ли будет полезно на практике.

— Нечетное