Проблема не совсем относится возможно к самому длинку, но может кто-то имел опыт.

Пользователи получают адреса через 3526, который пересылает запросы по dhcp_relay протоколу (клиент посылает запрос по броадкасту и свитч форвардит на выделенный дхцп сервер).

В нормальной ситуации пользователи через половину lease-time сами по юникасту обращались к дхцп серверу и успешно продлевали себе время. Но 3526 почему-то юникаст запросы не перехватывает и в результате информация о свитче, порте и прочие параметры option 82 просто не передаются. Именно поэтому мы пофильтровали все униаст запросы к дхцп серверу из пользовательских сетей и оставили доступх только из подсетей свитчей.

В ситуации, когда пофильтрованы уникаст запросы, клиенты примерно за минуту до истечения срока аренды адреса переполучают его по дхцп.

Так вот у некоторой не сильно большой части пользователей (судя по обращениям) ИП адрес на секунду-другую обнуляется, становится 0.0.0.0, после чего через секунду две адрес компьютер таки обновляет получает. Но как сами понимаете, при этом отваливаются все онлайн сервисы вроде скайпов, аськи и др. А там где лиз-тайм даже 1 час - это очень критично.

Помогите, ведь у вас богатый опыт.
Спасибо

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

Этой информации никогда не будет в обычных уникаст-пакетах.

Вот так вот. Для обхода этой фишки есть некоторые опции в самом сервере isc-dhcpd.

Осталось дождаться, когда нас порадют опцией dhcp_relay на конкретных портах.

Спасибо .

Немного не понял. Вообще-то свитчи при включённом Relay шлют пакеты в Unicast. У Вас DHCP Snooping включён?

snooping нет,
пакеты dhcp-броадкаст снабжаются информацией (mac-switch, port, client ip, client-vlan) etc.
а в уникаст dhcp-пакетах этой инфомации нет.

Так же очень сильно хочется увидеть возможность включения dhcp_relay только на определённых портах.

Возможно ли вообще такую логику реализовать и если да, то когда можно ждать?

Спасибо.

Как раз при включённом DHCP Relay option 82 информация добавляется в Unicast пакет. По поводу блокировки Broadcast пакета в клиентском VLAN при включённом Relay функционал запрошен. Как только будут новости сообщу.

Проблема вот где: "В нормальной ситуации пользователи через половину lease-time сами по юникасту обращались к дхцп серверу и успешно продлевали себе время. Но 3526 почему-то юникаст запросы не перехватывает и в результате информация о свитче, порте и прочие параметры option 82 просто не передаются."

Эту проблеме решили так в isc-dhcp (хотя она проявлялась периодически):

The stash-agent-options statement

stash-agent-options flag;

If the stash-agent-options parameter is true for a given client, the
server will record the relay agent information options sent during
the client's initial DHCPREQUEST message when the client was in the
SELECTING state and behave as if those options are included in all
subsequent DHCPREQUEST messages sent in the RENEWING state. This
works around a problem with relay agent information options, which is
that they usually not appear in DHCPREQUEST messages sent by the
client in the RENEWING state, because such messages are unicast
directly to the server and not sent through a relay agent.

Забыл самое главное сказать.

В юникасте когда приходят dhcp_relay пакеты, в них вместо клиентского порта 1-24 пишется аплинковый порт (в моём случае 25), другой терминологией "транковый порт".