Добрый день имеется ситуация:
Свич, на нём созданы несколько профайлов с несколькими разрешающими правилами. в 28 порт воткнут Uplink в 1 порт клиент. Клиент указан в разрешающих правилах.
Также создан 256 access_id:


Итак - пингуем клиента откуда нибудь. (Или делаем что угодно)

Создаём правило запрещающее весь трафик:


Клиент всё ещё работает. (так как он есть в разрешающих правилах).
Но через 1040-1190 секунд перестаёт работать. Трафик запрещён.

Удаляем правило 1 из профайла 256 - клиент работает.
Добавляем правило 1 назад.
Опять работает 1040-1190 секунд, а потом перестаёт ...и т.д.

Нету ли идей?

Судя по всему клиент разрешен IP правилом, которое не распростаняется на протокол ARP, а запрещен как видно Ethernet правилом, которое на ARP распространяется. После некоторого тайм-аута записи в ARP таблице на компьютере устаревают и ему приходится отправлять ARP запрос, который из-за правил не проходит.
P.S. Вам нужно взять сниффер и посмотреть клиентские пакетики, чтобы разобраться в том, какие процессы происходят для обмене трафиком.

Действительно, теперь (в отличие от 3028) не адресуются первые 12 байт в правиле типа packet content.

Спасибо.

Вы имеете в виду выборку Source MAC и Destination MAC при помощи PCF на DES-3200?

Да. Ситуация такая.

Имеется профиль 10 - пакет контент:


и имеется запрещающий всё профиль 256


между ними ещё есть профиль разрешающий IP.

И вот так arp ответы не ходят. (Хотя должны, что делать?)

А если убрать 256 профиль, а в 10 профиле поменять на deny - то arp-ответы ходить не будут! ( в смысле, что ошибок в 10 профиле нет).
IP-пакеты ходят в обоих случаях.

Заместо 10 профиля используйте, пожалуйста, Ethernet профиль с выборкой по полю Ethertype.

Дело в том, что я немного упростил задачу...

Там проверяется ещё несколько полей, например что содержит arp ответ по поводу своего IP... И всё в одном правиле... Очень удобно... до 11 полей.

Может быть можно использовать какое-нибудь другое запрещающее всё правило, которое не будет иметь packet_content побеждающий приоритет?

В таком случае Вам нужно переделать все правила под PCF и запрещающим сделать тоже PCF, содержащий один offset (пусть даже пустой).

Правило packet_content по source_mac побеждает packet_content по оффсету (всегда
А Правило packet_content по offset побеждает IP правила

Не совсем так. На данной серии кроме привычного механизма правила еще делятся на две группы: (PCF содержащие offset) и (любые другие типы + PCF не содержащие offset).
В случае, если пакет попадает под обе группы, то более приоритетным будет запрещающее правило в одной из групп.
Поэтому я Вам и рекомендовал переделать все правила под PCF, содержащие хотя бы по одному offset.

При создании packet_content фильтра пишет
Device supports only 11 UDF fields!
Там не планируется расширение этого числа?

Не планируется. К сожалению, это аппаратное ограничение.