У меня есть DHCP-сервер, обслуживающий несколько подсетей через DHCP-ретранслятор. Когда он отправляет предложения DHCP, он устанавливает идентификатор сервера (опция 54) на свой собственный IP-адрес.
Когда клиентам необходимо продлить подписку, они пытаются выполнить одноадресную рассылку на этот IP-адрес, на который никто из них не может выполнить маршрутизацию.
Как должна работать одноадресная передача на DHCP-сервер при использовании реле? Ожидается ли поведение клиента при отказе от обновления одноадресной рассылки во время состояния RENEWING и последующего возобновления посредством широковещательной рассылки во время состояния REBINDING после времени T2?
Да, конечно.
Немного странно, что клиенты не могут направлять одноадресную рассылку на свой DHCP-сервер, но это вовсе не проблема; они будут просто продлеваться позже в течение срока аренды (что дает вам немного меньше возможностей для простоя DHCP-сервера).
Продление аренды (на этапе T1) упрощается с помощью одноадресного сообщения от DHCP-клиента на DHCP-сервер. Почему одноадресный трафик из клиентской подсети не направляется в подсеть сервера? Каким образом исходное широковещательное сообщение будет ретранслировано в подсеть сервера, если сообщение DHCPDiscover из клиентской подсети не маршрутизируется (ретранслируется) в подсеть сервера? Если трафик между подсетями не маршрутизируется, то как клиент вообще получит IP-адрес?
В конце дня трафик из подсети DHCP-клиента маршрутизируется через маршрутизатор (посредством одноадресного сообщения от агента ретрансляции DHCP во время исходного этапа DHCPDiscover, а затем на этапе T2) и / или посредством одноадресной передачи непосредственно из клиент DHCP на этапе обновления T1.
Как вы заявили, если клиент достигает стадии T2, он отправляет широковещательный запрос на обновление, который агент ретрансляции DHCP должен ретранслировать (одноадресная передача) на сервер DHCP.
РЕДАКТИРОВАТЬ
Это теоретический вопрос или у вас действительно есть эта проблема?
РЕДАКТИРОВАТЬ 2
Чтобы добавить еще один поворот к моему ответу: когда клиент инициирует продление аренды на этапе T1, запрос на обновление представляет собой одноадресное сообщение напрямую от клиента к серверу (одноадресная передача - это прямая связь один-к-одному), поэтому агент ретрансляции DHCP вообще не должны быть задействованы. Если клиент достигает стадии обновления T2, то запрос обновления отправляется посредством широковещательного сообщения и должен быть ретранслирован агентом ретрансляции DHCP (который фактически является одноадресным сообщением от агента ретрансляции DHCP).
Если одноадресное сообщение этапа T1 не маршрутизируется из подсети клиента в подсеть сервера, то это проблема маршрутизации / сети, а не DHCP.
ОК Похоже, я не могу комментировать предыдущий ответ, а просто спамю вам дополнительный ответ.
Я думаю, что это не совсем проблема маршрутизации. Чтобы понять, посмотрите на следующий очень простой пример:
=> Где мне нужно было знать MAC сервера? нигде. Я не могу быть уверен, что исходный MAC-адрес полученных мной пакетов, будь то широковещательные или одноадресные, является MAC-адресом сервера. В любом случае, высока вероятность того, что T1 превысит таймаут кеширования arp ...
Обычно я использую ARP для siaddr. Что делать, если IP-адрес одноадресного сервера НЕ указан в моей ссылке? Что ж, я в конце концов отброшу запрос и все последующие попытки, пока не перейду в состояние REBINDING.
Здесь нет реальной ошибки маршрутизации. Это проблема топологии, и я даже не могу реализовать решение, в котором я бы отправил обновление на IP-адрес giaddr, поскольку это противоречит стандарту.