Скажите пожалйуста, как обрабатываются правила ACL при включенном Mac-IP-Binding.

Есть правила:
ACL:
Разрешить всем ходить в 10.10.0.0/24
Запретить всем ходить везде.
Mac-IP-Binding:
Заретить всем ходить куды бы то ни было.

Ожидаемый эффект, что все кто не опознан на свитче могут ходить в 10.10.0.0, а те кому добавляется правило MAC-IP могут ходить дальше.

Но... Почему-то в 10...... после включения MAC-IP банятся все и везде.

В чем может быть проблема?

Мы сейчас работаем над данной проблемой. Будут новости - сообщим.

Что-то не совсем понял.. Разве при включении IP MAC Bind, допустим последним 8-9 ACL профилем, предыдущие ACL запрещающие в 1-8 профиле не срабатывают?
Всю жизнь думал что если пакет попал под deny или allow на предыдущем профиле то до более старшего по номеру профиля ACL он не дойдет. Или я ошибаюсь? (firmware 5.1b14)

Еще вопрос.. в FAQ сказанно "– Любое запрещающее правило после IP-MAC-Port binding становится ненужным, поэтому
рекомендуется располагать все остальные ACL в более приоритетном порядке"

Раньше я всегда последними двумя профилями запрещал прохождение всех протоколов кроме IP.

create access_profile ethernet ethernet_type profile_id 8
config access_profile profile_id 8 add access_id 1 ethernet ethernet_type 0x800 port 1-26 permit
config access_profile profile_id 8 add access_id 101 ethernet ethernet_type 0x806 port 1-26 permit

create access_profile ethernet source_mac 00-00-00-00-00-00 profile_id 9
config access_profile profile_id 9 add access_id 1 ethernet source_mac 00-00-00-00-00-00 port 1-26 deny

В случае с включенным ACL mode Mac-IP-Binding и прописанном правиле на порту - запретит ли оно работу на этом порту например IPX или AppleTalk или все-равно необходимо после IPMB ACL профилей фильтровать трафик? И если фильтровать - достаточно ли будет создать один профиль "запрещиющий все" ?

Судя по вот этому:
Access Profile ID : 9 Type : Packet Content
===============================================
Owner : Address_binding
Masks :

Offset 16-31 : 0xffff0000 00000000 00000000 00000000

Access ID: 1 Mode: Deny
Owner : Address_binding
Port : 1
----------------------------------------------------
Offset 16-31 : 0x08000000 00000000 00000000 00000000

Здесь запрещается прохождение 0x800 - т.е. просто IP трафика - а вот ARP 0x806 пакеты (или даже ARP spoof запросы) и "все что не IP" будет ходить через свитч свободно

Нет не запретит. По поводу приоритизации правил мы сейчас решаем вопрос. Как только будут новости Максим отпишется.

..тогда подправьте амбициозную фразу в FAQе пожалуйста..
И если можно точните
1) от ARP спуфинга IPMB получается не защищает?
Трафик зараженная машина не перехватит, но ARP таблицу у всех в сегменте испортить и не дать работать сможет ?
2) Будет ли работать IPMB при приходе на порт тегированного пакета.
Допустим ниже 3526 стоит 2108 (tagged) и привязку IP+MAC хотелось бы выполнить на 3526.
3) Или пользователь-злоумышленник и отдает тегированный пакет с своим правильным VID, но неправильной связкой IP+MAC.. ))
4) Неправильные (заблокированные) пары IP+MAC (в ACL mode) заносятся в таблицу коммутатора для дальнейшего просмотра.. А если их сгенерить 1000-2000 какой-нибудь вирус.. Память у свитча не переполнится?

1) В последней прошивке при настройки функции IMP на порту есть опции strict и loose. При включении strict каждый первый новый ARP пакет не проходит и невозможен ARP спуфинг, а при loose проходит.
2) Вообще работает. По крайней мере жалоб на это не было.
3) В Block list заносятся только MAC-адреса злоумышленников.

Подскажите еще пожалуйста - имеет ли какой-либо смысл включение Port Security при активации IPMB ?

Нет не имеет.

Учитывая текущие расширения функции IPM-Binding, задача очень нетривиальна, мы занимаемся её решением.
На данный момент, как вариант, используйте следующий механизм:

Вместо IPM-Binding записей, создайте аналогичные правила с помощью ACL Packet Content, и впишите их в ваш набор правил с необходимым приоритетом = profile_ID.

Не могли бы вы дать примеры по настройке ACL Packet Content для 3526 а так же для DGS 36xx. CLI и SNMP, больше конечно же интересует SnMP: юмор : Давайте закроем тему со словами: "Я вам прошивку выслал".

В принципе понять как это делать можно вот из этого FAQ http://www.dlink.ru/technical/faq_hub_switch_115.php

Подскажите пожалуйста, как удалить правило ACLpacket_content_filtering.
В создании я разобрался, а OID для удаления никак не могу вкурить. Спасибо.

Такойже как и для создания только передать ему нужно не CreateAndGo, а Destroy, на 3526 так.

Уважаемые представители D-link, новости о проблеме приоритезации IPMB и остальных профилей ACL не появились? Или по крайней мере описание ограничений которые накладывает использование IPMB на остальные создаваемые на комутаторе ACL профили?

Мы работаем над этой проблемой. Но пока IMP имеет более высокий приоритет чем ACL. Главным образом из-за обработки ARP-ов. В принципе можно смело заменить IMP правила на аналогичные Packet Content и получить правильную последовательность выполнения правил.