Возникла проблема:
Клиенты (сеть из DES-1228) перестали получать адрес по DHCP (option 82)

Выглядит в логах это так:

Oct 3 07:18:28 dhcpd dhcpd: DHCPOFFER on 10.135.192.62 to 34:08:04:c3:19:a3 (DIR-300) via 192.168.133.105
Oct 3 07:18:28 dhcpd dhcpd: DHCPREQUEST for 10.135.192.62 (192.168.128.1) from 34:08:04:c3:19:a3 (DIR-300) via 192.168.133.105
Oct 3 07:18:28 dhcpd dhcpd: DHCPACK on 10.135.192.62 to 34:08:04:c3:19:a3 (DIR-300) via 192.168.133.105
Oct 3 07:18:31 dhcpd dhcpd: DHCPDISCOVER from 34:08:04:c3:19:a3 (DIR-300) via 192.168.133.105
Oct 3 07:18:31 dhcpd dhcpd: DHCPOFFER on 10.135.192.62 to 34:08:04:c3:19:a3 (DIR-300) via 192.168.133.105
Oct 3 07:18:31 dhcpd dhcpd: DHCPREQUEST for 10.135.192.62 (192.168.128.1) from 34:08:04:c3:19:a3 (DIR-300) via 192.168.133.105
Oct 3 07:18:31 dhcpd dhcpd: DHCPACK on 10.135.192.62 to 34:08:04:c3:19:a3 (DIR-300) via 192.168.133.105
Ну и так каждые несколько секунд, в зависимости от конечного железа
====================================

Все проблемные клиенты живут внутри одной сети /24
При этом какие-то клиенты получают нормально и с первой попытки, а пара десятков бьются безуспешно.

На шлюзе обнаружился гадкий клиент, который светился везде:

Internet 10.135.192.212 5 00e0.4d36.0521 ARPA Vlan192
Internet 10.135.192.209 5 00e0.4d36.0521 ARPA Vlan192
Internet 10.135.192.142 5 00e0.4d36.0521 ARPA Vlan192
Internet 10.135.192.139 5 00e0.4d36.0521 ARPA Vlan192

Порт клиенту с маком 00e0.4d36.0521 положили, все нормализовалось.

==============================================

Мне не очень понятно происходящее. До сервера DHCP-запросы доходят с правильного коммутатора. А вот именно ACK уходит непонятно куда.
Вредный клиент живет не на одном коммутаторе с потерпевшими.

Мне надо как-то резать arp-запросы?

курите в сторону traffic segmentation

И у нормального клиента, и у ненормального будет открыт на доступе аплинковый порт в сторону шлюза и DHCP-сервера.
Как это изменит ситуацию?

DHCPACK должен приходить по управляющему влану на коммутатор, который посылал DHCPREQUEST. Он либо не доходит, либо этот самый коммутатор не транслирует его на нужный порт.

Я тут просто не понимаю, что лечить.

Мне не совсем понятно почему у гадкого клиента несколько адресов?

Потому что он гадкий.
Он отвечает на все аrp-запросы от шлюза.
Понятно, что клиент "ничего не делал", но после общения с ним стало понятно, что что-то таки было. Сниффер, видимо.

Давай-те посмотрим конфигурации коммутаторов.
Я так понимаю под этим "все аrp-запросы от шлюза" вы имеете ввиду broadcast arp или что? Ну то есть кто-есть в этом вилане с этим ip.

Давайте посмотрим конфигурации.

Клиенты (сеть 10.135.192.0/24) живут в 192 влане, который протянут до шлюза-циски
Управляющий влан - 196, там включена опция 82. Влан дотянут до сервера с named


По ACL на доступах

1) Режем DHCP сервера у клиентов
create access_profile ip udp src_port_mask 0xFFFF profile_id 1
config access_profile profile_id 1 add access_id 1 ip udp src_port 67 port 25-28 permit
config access_profile profile_id 1 add access_id 2 ip udp src_port 67 port 1-24 deny
2) Разрешаем трафик клиенту с полученным IP
create access_profile ip source_ip 255.255.255.255 profile_id 100
config access_profile profile_id 100 add access_id 1 ip source_ip 10.135.192.90 port 1 permit
3) Разрешаем трафик для получения адреса
create access_profile ip source_ip 0.0.0.0 destination_ip 255.255.255.255 profile_id 180
config access_profile profile_id 180 add access_id 67 ip source_ip 0.0.0.0 destination_ip 255.255.255.255 port 1-28 permit
4) запрещаем все остальное
create access_profile ip source_ip 0.0.0.0 profile_id 200
config access_profile profile_id 200 add access_id 200 ip source_ip 0.0.0.0 port 1-24 deny


Таким образом я режу исходящий трафик клиенту с левым IP.
Обычно этого достаточно.
Но вот вылезло еще.