Пффф, что за новость, где ошибка? фильтрую udp src port 67

create access_profile profile_id 4 profile_name 4 packet_content_mask offset_chunk_1 6 0xFF0000 offset_chunk_2 7 0xFFFFFFFF offset_chunk_3 8 0xFFFFFFFF offset_chunk_4 9 0xFFFFFFFF
config access_profile profile_id 4 add access_id 145 packet_content offset_chunk_1 0x110000 mask 0xFFFF0000 offset_chunk_4 0x430000 mask 0xFFFF0000 port 28 deny

Ну помогите кто нибудь, горит
Обычный IP, не PCF, в том же 4 профайле, режет на ура, где то ошибся, что-то не правельно посчитал...

Вот рабочий пример блокировки:

offset_chunk_1 3 0xFFFF - Тип кадра, это эквивалент 0x0000FFFF
offset_chunk_2 4 0xFF0000 - Тут я указываю какой тип PPPoE
offset_chunk_3 6 0x00FF0000 - Тип IP протокола
offset_chunk_4 9 0x0000FFFF - В данном случае 0x0000FFFF это dst IP port, тогда как 0xFFFF0000 это src IP port


PADO блок

TCP(0x60000) dst port 445 (0x1BD) block

dst port тоже на ура режу, а вот src на примере 67ого не могу.
Пробовал хоть 0x430000 mask 0xFFFF0000 хоть 0x43 mask 0xFFFF0000

Есть у кого нибудь рабочий пример PCF на блокировку src udp port 67 на клиентских портах?

А чем, собственно, не устраивает функционал DHCP Server Screening? В чем необходимость использовать для этих целей PCF?

Ну вот, собственно все и забылось...
Проблема в том что функционал DHCP Screening на данный момент требует отдельный профиль и в совокупности с IMPBv4 оставляет (помимо первых двух профелей) только один.
Первый два профиля не устраивают viewtopic.php?p=832763#p832763

Под наши нужды на C1 с использованием PCF уместились в два профиля. Второй создать не можем, решено отказаться от DHCP Screening просто зафильтровав в PCF необходимое. Без DHCP Screening'а создаем два профиля...

Простите, но за последнее время по acl выходит полный сумбур.
Пришлите, пожалуйста, мне на почту конкретное описание, что и в каких ситуациях не работает, почему не получается использовать DHCP Screening - и какие проблемы всплывают при его включении. Буду смотреть и писать в ШК наши вопросы.
Спасибо.

"На почту" - все-таки значит "на почту", а не в личные сообщения... Это на будущее.
По поводу arp - привожу документ. Рассматриваем только данный конкретный случай с arp. Если проблема с другими ethertype - значит, описываем проблемы с другими ethertype. Как я уже говорил, описания системных acl нам не предоставляют, и поэтому каждый конкретный случай рассматривать будем отдельно.

Ситуацию с DHCP Screening, 4м профилем и src udp 67 проверю и отпишу по результату.

У вас ошибка в PCF, нужно вот так:

отличия - offset_chunk_1 : 6 value : 0x00110000 Mask : 0xFFFF0000 нужно было заменить на 00.

По поводу Server screening и невозможности создания профилей - приведите, пожалуйста, все команды, введенные на пустой конфиг, приводящие к такому результату.

Охохоюшки... да спасибо, работает...

По поводу screening...

Т.е. отказываемся либо от impb либо от dhcp скрининга - четвертый профайл создается...

ya4ya
Я уточню этот момент в ШК. Спасибо.

Мдя. Сегодня наконец собрался перевести все C1 на новый ACL...
К моему удивлению, не получилось. Как оказалось, по крайней мере в последних двух (B005,B006) DHCP скрининг вообще не играет никакой роли на количество профайлов в ACL.
Проблема в следующем на дефолтном конфиге:

Смысл в том что ip_inspection при установленном по умолчании "config address_binding ip_mac ports 20 protocol all" создает два профайла IMPBv4 и IMPBv6 которые не дают создавать пользовательские профайлы, соответственно если используем "config address_binding ip_mac ports 20 protocol ipv4" получаем только один пользовательский профайл.

Понятно что отказаться от ip inspection не вариант...
Как быть?

Так и есть.
Под ipv6 используется еще один профайл, и если не указать ipv4 - он будет использован. Если указать ipv4 - он будет освобожден.

Сейчас ведется активное обсуждение этого поведения с разработчиками.

Артем, хотелось бы получить два свободных профайла под свои нужды (т.е. что бы функционал ip_inspection в all или ipv4/ipv6 only не создавал доппрофайл(ы)).

Можно ли ожидать что это будет?
Если да, то ориентировочно когда?