Конфигурация address_binding и dhcp_local_relay:
config address_binding ip_mac ports 1-16 mode acl stop_learning_threshold 500
config address_binding dhcp_snoop max_entry ports 1-16 limit 5
config address_binding dhcp_snoop max_entry ports 1-18 limit no_limit ipv6
config address_binding ip_mac ports 1-16 state enable strict allow_zeroip enable forward_dhcppkt enable
config address_binding ip_mac ports 17-18 state disable allow_zeroip disable forward_dhcppkt enable
config address_binding ip_mac ports 17-18 mode arp stop_learning_threshold 500
config address_binding dhcp_snoop max_entry ports 17-18 limit no_limit
enable address_binding dhcp_snoop
enable address_binding trap_log
disable address_binding dhcp_snoop ipv6
enable dhcp_local_relay
config dhcp_local_relay option_82 circuit_id default
config dhcp_local_relay option_82 remote_id default
config dhcp_local_relay vlan vlanid 2252 state enable
config dhcp_local_relay vlan vlanid 4000 state enable
config dhcp_local_relay option_82 ports 1-16 policy replace
config dhcp_local_relay option_82 ports 17-18 policy keep
Проблема:
К порту подключен абонент А, получен ip-адрес A по DHCP, в таблице address_binding запись присутствует.
В соседнем коммутаторе в этом же vlan к порту подключен клиент B, получивший по dhcp ip-адрес B.
При отправке клиентом А с src-ip B unicast dhcp request на dhcp-сервер, коммутатор его пропустит, на interface vlan обновится arp-таблица для IP-адреса B, и интернет у клиента B перестанет на несколько секунд работать.

Мне кажется это некорректное поведение и абоненту A должно быть разрешено отправлять dhcp request только с ip-адреса A.

Коммутатор des-3200-18/b1, версия 1.82.B011. На DES-3200/C1 не проверял.

У нас таких проблем нет, mode arp в strict режиме, и любые пакеты src mac/ip отличными от связки на порту - дропаются.

хм....

Про обычные IP пакеты аналогично, я говорю только про Unicast DHCP request пакеты(очень не стандартная ситуация), которые видимо при включенном dhcp local relay попадают на CPU, для добавления option 82, и видимо не происходит проверка на легитимность данного пакета.

На сколько я понял работу данного механизма, реквест и не проверяется на легитимность, проверяется только ответ dhcpack - связка создается/обновляется, во всех остальных случаях мак либо не лернится, либо попадает в блок лист. Т.о. это уже ваш дхцп сервер должен рулить ответами ack/nack, в зависимости от того какой клиент чего реквестит )))

Меня беспокоит не DHCP сервер, он ответит NAK. Но из-за того что unicast пакет прошел, и L3 свич его обработал, на нем обновляется arp таблица(похоже это особенность cisco dhcp relay).
Я обратил внимание что это обновление специфично только для DHCP и GARP пакетов, обычный ip unicast обновление arp-таблицы не вызывает.

В итоге получаем что правильно составленый dhcp-пакет позволяет нарушить работу отдельного vlan. И как от этого защищаться - непонятно.

Какое это имеет отношение к des-3200-18?

На доступе, имхо, только pcf вам поможет, но это изврат.

Самое прямое.
Мой вопрос был: Почему весь ip unicast с неавторизованного IP на des-3200-18 дропается, а dhcp unicast пропускается?
И насколько корректно такое поведение, ведь согласно RFC 2131:
"... If the lease expires before the client receives a DHCPACK, the client
moves to INIT state, MUST immediately stop any other network
processing and requests network initialization parameters as if the
client were uninitialized. ..."

То есть необходимости в пропуске таких реквестов нет.

Аклы по биндингу создаются? Покажите show access_profile в момент когда клиент А с src-ip B отправляет unicast dhcp request

Аклы создаются(outgoing IP/ARP пакеты не проходят), но в access_profile их не видно:
3200-18:5#show access_profile
Command: show access_profile

The access profile table is empty.