Есть сервер ISC DHCP, который принимает от свичей 3028 запросы с Opt82.

# DHCP_RELAY
enable dhcp_relay
config dhcp_relay hops 4 time 5
config dhcp_relay option_82 state enable
config dhcp_relay option_82 check enable
config dhcp_relay option_82 policy replace
config dhcp_relay option_82 remote_id default
config dhcp_relay add ipif System х.х.х.х

Клиент включается, шлёт DHCP Request, получает адрес, работает. Тут всё отрабатывается корректно.
Дальше он начинает просить продление аренды адреса (пока она еще не закончилась) напрямую у DHCP-сервера и получает банан.

dhcpd: DHCPREQUEST for y.y.y.y from 00:1d:60:08:a3:55 via eth0: lease y.y.y.y unavailable.

Так продолжается до тех пор, пока не кончится аренда, юзер отваливается и снова получает адрес через broadcast dhcp request
С этим можно что-нибудь сделать или оно у всех так ?

Можно делать маленькое время аренды либо очищать список этих аренд. У меня раз в 5 минут выгружается новый конфиг. Чтобы его применить сервер так или иначе надо перезагружать. Заодно очищаем список аренд. Само время аренды делаем большое, чтобы клиенты лишний раз к серверу не обращались. Пару месяцев работает так, никто не жалуется.

_________________
D-Link Switches: Tips & Tricks

Дело не во времени аренды, а в том, что DHCP выдает адрес свичу (dhcp_relay), а продление аренды уже напрямую от клиента юникастом идёт, и в этом запросе нет Opt82, который вставляет свич при перехвате broadcast dhcp request, поэтому DHCP отфутболивает такой прямой запрос. А вопрос в том - должен ли (может ли) свич подменять также эти клиентские запросы продления, либо DHCP-сервер реагировать на запросы продления, хотя тут вряд ли, т.к. изначально запрос идёт с Opt82, по которому и выдается адрес.

На dhcp_relay попадают только широковещательные пакеты, т.е. как раз DHCP Discovery, а пакеты на продление адреса - юникастовые, поэтому в них Opt82 не вставляется. Это нормальная работа, Вам надо подрегулировать DHCP сервер чтобы он мог продлевать аренду по запросу без Opt82.

Alexandr Zaitsev, это не нормальная работа.
Это дырка в безопасности сети и качестве предоставляемых услуг.

NOT required - не требуется
not must - не должен

Так схема сети - циска ISG и инициатор DHCP.
Продление сессии идет по renew , а удаление сессии по release уникастовому DHCP пакету.

Ваши предложения по валидации этих пакетов.

зы этот RFC 2001 года - тогда про ISG даже не думали.

Может кто знает как так подрегулировать ISC DHCP чтобы он продление без Opt82 делал? Вопрос не совсем по адресу, но думаю многим актуален и тесно связан с D-Link.

Вопрос: есть DES3526/3028/3200 ... на них включен dhcp_local_relay, enable address_binding dhcp_snoop, ...
Первоначальное получение адреса у DHCP-сервера происходит корректно, начинается работа и появляется соотв. запись в show address_binding dhcp_snoop binding_entry

Адрес выдается на 24 часа, и когда это время истекает, перезапрос адреса происходит юникастом. Только вот коммутатор никто об этом не уведомил, соотв. запись в dhcp_snoop binding_entry не обновилась, и все прекращает работать. Спасает принудительный перезапрос адреса у сервера (ipconfig /release , ipconfig /renew) . Но это очень неудобно. Есть ли какой-нибудь солюшн ?

Это давно уже исправлено. Какие у Вас прошивки?

3526 - 6.00.B51
3028 - 2.60.B02
3200 - 1.40.B006

Читайте RFC:
По прошествии половины периода, на который был выделен IP-адрес, DHCP-клиенты пытаются продлить его аренду. Для этого клиент посылает сообщение DHCPREQUEST непосредственно DHCP-серверу, выделившему ему адрес. При возможности DHCP-сервер продлевает ее и отсылает клиенту сообщение DHCPACK с новым временем аренды и параметрами конфигурации TCP/IP. Получив подтверждение, клиент обновляет свою конфигурацию.

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

Если по прошествии половины времени аренды DHCP-клиент не сможет продлить ее на исходном DHCP-сервере, то по истечении 87,5% времени аренды клиент начнет широковещательную рассылку сообщения DHCPREQUEST для связи с любым доступным DHCP-сервером. В ответ клиент может получить сообщение DHCPACK с информацией о продлении аренды, либо сообщение DHCPNACK, требующее инициализации клиента и получения им другого IP-адреса.

По истечении срока аренды или получении сообщения DHCPNACK DHCP-клиент должен сразу прекратить использование занятого IP-адреса. После этого он может возобновить процесс аренды для получения нового IP-адреса.

Пришлите мне на почту конфиги, с этими прошивками всё должно нормально работать.

Присоединяюсь! Конфиги выслал на почту

UPD: кажется разобрался, решением оказалась строчка

config address_binding ip_mac ports 1-24 forward_dhcppkt disable

теперь на сервер проходят только широковещательные запросы с опцией 82, в т. ч. который по RFC должен быть через 87,5% времени истечения lease

остается один вопрос: у меня клиенты и dhcp сервер в разных вланах, но без вышеуказанной строчки запросы юникастовые получаются проходят из одного влана в другой? т. е. dhcp relay всё таки используется каким-то образом, но не таким каким надо нам - обычным пользователям?

UPD2: с 3200-26 такой финт не прокатил. После вышеприведенной команды dhcp relay перестает работать

UPD3: на самом деле и с 3526 какая-то ерунда получается. Для клиента на 4-м порту
всё работает, а для клиента на 24-м - нет, после команды

config address_binding ip_mac ports 1-24 forward_dhcppkt disable

юникастовые дхцп пакеты всё равно проходят

UPD4: после команд

config address_binding ip_mac ports 1-24 forward_dhcppkt disable
save
reboot

на 3526 всё заработало как надо