Попробовал включить данную функцию. Создалось 4 правила. Как я понял первый правиль разрешает АРП пакеты с заданной связкой. Зачем ??? Второй профиль разпрещает АРП с Sender IP Address защищаемого шлюза. Это уже по делу. Правда в каждом профиле создается по 2 правила - со смещением VLAN и без. Опять же для чего ? Поясните, пожалуйста.

P.S. топология у меня кольцевая. Привязываться к макам не хочу, DHCP Snooping здесь конечно применить бы, но насколько он хорошо работает? И как понимаю с ним пользователь статикой уже не пропишет адрес.

Всё зависит от модели коммутатора, на некоторых, таких как DES-3028 и DES-3200 ACL отрабатывают до добавления tag 802.1q, поэтому и создаются профили для untag и tag трафика.

_________________
С уважением,
Бигаров Руслан.

Ясно. Тогда получается достаточно на клиентских портах (untaged) прописать PCF ACL, запрещающий ARP с Sender IP шлюза без смещения по VLAN.
Все таки остается вопрос для чего разрешать связку IP-MAC шлюза (насколько я внимательно понял по автоматически созданному ACL arp_spoofing_preventation), если защита вешается все равно на клиентские порты ?

Недостаточно, коммутатор отбросит пакет, но изучет МАС шлюза на клиентском порту.

_________________
С уважением,
Бигаров Руслан.

А на 3028 есть данная функция? В веб интерфейсе найти немогу.

Есть

1) И все-таки непонятно, для чего создается первый разрешающий профиль командой config arp_spoofing_preventation?

2) Включаю защиту задав соответствующие ip/mac шлюза, при этом на клиентский комп ставлю айпи шлюза с другим маком. Он конечно перестает работать, но MAC то изучается все равно, а Руслан сказал что написать вручную ACL недостаточно т.к. мак будет изучаться. Он и так и сяк изучается. При Arp-spoofing`е ведь МАК-адрес атакующего как раз таки не совпадает со шлюзом

3) Если влючить защиту и поставить на клиентской машине mac+ip шлюза, то при выключенном настоящем шлюзе этот поддельный (без доп. настроек коммутатора) работает себе. А делать ему это позволяет насколько понимаю как раз первый разрешающий профиль

Вывод: данную функцию можно реализовать вручную посредством одного правила ACL, мало того, в отличие от arp_spoofing_preventation, такой метод не позволит клиенту повесить композицию ip+mac шлюза. Конечно, там встает вопрос совпадения МАК-адресов, но его можно решить посредством auto_fdb (в случае кольцевой топологии) или привязки вручную МАКа шлюза на аплинке.

Подскажите, всё ли я правильно истолковал или где-то ошибаюсь ? Может эта функция еще что-то делает кроме создания ACL ?

А писать эту связку нужно на аплинк порт или на все клиентские ?

На клиентские, на аплинке то как раз шлюз висит, который шлет правильные данные, а в противном случае сосед соседу беспрепятственно подкинет левый ARP для спуфинга

Вариант тоже хорош, ведь Arp spoof тоже израсходует ACL.
И добавить мак шлюза в статику тоже подходит.