Погоняли две недели прошивку 2.52.b02 на свитчах где из-за блокировки МАС-адреса шлюза, приходилось отключать на портах IMPB и пользоваться ACL. IMPB в режиме strict+ACL отрабатывает на ура. Никаких проблем не замечано.
Чего не скажешь про 3200-28. Там при аналогичной конфигурации:
Код:
enable address_binding dhcp_snoop
enable address_binding trap_log
disable address_binding arp_inspection
config address_binding ip_mac ports 1-24 state enable strict allow_zeroip enable forward_dhcppkt enable mode acl stop_learning_threshold 500
config address_binding dhcp_snoop max_entry ports 1-24 limit no_limit
при прохождении через абонентский порт (с включённым IMPB strict+ACL) arp-пакета c ARP->Sender MAC = МАС-адресу шлюза, данный МАС заносится в блоклист, не смотря на включённый режим ACL для этого порта. Хотя пакеты с неизвестной парой MAC-IP вроде как должны отбрасываться без занесения в fdb и установки флага блокирования.
Как временное решение, использую CPU ACL для того, чтобы не допускать ARP-пакеты в клиентских VLAN'ах на обработку CPU:
Код:
# arp inspection workaround
# prevent MAC-address blacklisting by IMPB in customer VLAN's
enable cpu_interface_filtering
create cpu access_profile profile_id 1 packet_content_mask offset_0-15 0x0 0x0 0x0 0xffffffff offset_16-31 0xffff0000 0x0 0x0 0x0
# VLAN 701
config cpu access_profile profile_id 1 add access_id 1 packet_content offset_0-15 0x0 0x0 0x0 0x810002BD offset_16-31 0x8060000 0x0 0x0 0x0 port 1-28 deny
# VLAN 714
config cpu access_profile profile_id 1 add access_id 1 packet_content offset_0-15 0x0 0x0 0x0 0x810002CA offset_16-31 0x8060000 0x0 0x0 0x0 port 1-28 deny
# VLAN 715
config cpu access_profile profile_id 1 add access_id 1 packet_content offset_0-15 0x0 0x0 0x0 0x810002CB offset_16-31 0x8060000 0x0 0x0 0x0 port 1-28 deny
Используемая на 3200-28 прошивка: 1.20.B011
Данное решение не рациональное, т.к. может мешать работе другому функционалу CPU, анализируещему ARP-пакеты. С другой стороны, это так же может помочь снизить нагрузку на CPU при арп-флуде...