а вот никак, даже обычные ACL не будут обработаны, если dest_ip=ipif
И вот сейчас ситуация была только что: одно чудо флудило в гейт, на гейте как не измывался на ACL, зарезать чудесный трафик в гейт на самом гейте не получается возможным, только на нижестоящем L2 получилось.
cpu acl, в данном случае, в нормализации работы гейта не приводило, хотя трафик резало.

Да я вообще думал урезать ICMP не только к шлюзам, но и к некоторым серверам (маска /24).
Просто если rx_rate будет применяться на всю маску, то это всё таки жестковато, придёться в таком случае отдельное правило создавать на каждый сервер.

Кстати, Вы ACL на самом 36-ом создаёте ?

а можно примерчик асл ?

я там понял на раенном л2 резать как раз можно 3028

_________________
админ DGS 3612(DGS36xxRun_2[1].50-B15), DES 3526 (DES3526R6_6.00.B10),
DES 3028(DES_3028_52_V2.10-B06),DES 3026, DES 2108 (hw des-2108v3-00-27),
DWL 2100, DWL 700G, DIR 100,
DL-LB604 (app2+4+DI-604LBVPN_v102_b0Otw_080815_ipsec)

Нет, на нижестоящем 3028



192.168.95.40 - 3612, работающий так-же в качестве DNS-Relay. Чудо, о котором я говорил, посылало на DNS нехилую пачку запросов, от которых util cpu был 99-100%.
После этих правил нагрузка на проц упала до 50%, после отключения абонента восстановилась до стандартных 15%.

Входящий от абонентов - 25 порт.

create access_profile ip desti 255.255.255.255 icmp profile_id 7
config access_profile profile_id 7 add access_id auto ip destination_ip 192.168.95.40 icmp port 25 permit

create access_profile ip desti 255.255.255.255 udp dst 0xffff profile_id 8
config access_profile profile_id 8 add access_id auto ip destination_ip 192.168.95.40 udp dst 53 port 25 permit rx_rate 64

create access_profile ip desti 255.255.255.255 profile_id 9
config access_profile profile_id 9 add access_id auto ip destination_ip 192.168.95.40 port 25 deny

Вот сегодня опять повторилась проблема... Syslog сервер ничего не зафиксировал, фактически на ровном месте.
До этого почти 2 недели проработало нормально.

Руслан, отправил Вам на почту схему сети + конфиги устройств.

Вобще очень интересный момент с последовательностью применения фильтров (ACL).

До прошлой недели жил на at-9724 (уже неподдерживаемый "телесиновский" бюджетный l3)

там соотвественно правилО типа



проблему ping -f XX.XX.XX.1 решает на раз.

понятно что фильтровать можно любой трафик - в CPU он не попадёт. Соотвественно до вчерашнего дня наивно полагал что так на свичах любого производителя - ведь логичное поведение не правда ли?

Что можно предпринять на 36-той серии, корме как резать на доступе?

2 Arti_ > Будет примерно так:
create access_profile ip source_ip_mask 0.0.0.0 destination_ip_mask 0.0.0.255 icmp type profile_id 2
config access_profile profile_id 2 add access_id 1 ip source_ip 0.0.0.0 destination_ip 0.0.0.1 icmp type 8 port <порты> deny

По ACL советую почитать эту презентацию:
ftp://ftp.dlink.ru/pub/Trainings/D-Link ... vanced.rar

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

Ну речь не о масках - там действительно глядя на XX трудно понять что имелось в виду ( сеть 192.168.0.0/16 интерфейсы l3 свича - 192.168.0.1/23, 192.168.2.1/23 и т.д.).

Проблема в том что невозможно отфильтровать пакеты ДО попадания их в CPU.

пример:



открываем шел:


3627G используется для агрегации т.е. фактически ARP, IGMP, ICMP "отвечалкой".

Пакеты, которые идут на CPU фильтруются с помощью CPU Interface Filtering. В указанной выше презентации это описано.

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

чем бы эту презентацию еще открыть....

Но не суть.

Скажите пожалуйста, ведь CPU Interface Filtering - выполняется на процессоре?

Если да, то мне не понятно как же при помощи такой фильтрации защитится от флуда, не перекладывая эту задачу на доступ? ping -f <интерфейс свича> уложит эту железяку безразлично от того задействован механизм CPU Interface filtering или нет.

Я извиняюсь м.б. из моих собщений не понятно что я от Вас хочу.

Меня бы удовлетворили ответы типа:

1. Да на этой серии защита CPU не предусмотрена его архитектурой, трафик необходимо фильтровать до его попадания на свич.

2.Эта поведение будет исправлено в следующей верси ПО.

Да, на процессоре:

viewtopic.php?t=118108

Реально, если флудерастят IPIF - хана CPU, неважно как вы будете изголятся с ACL.

Больше всего меня интересуют ответы на мои вопросы Что CPU Interface Filtering в деле борьбе с флудом не помошник - понятно и так (но иногда хочется ошибиться )

Я всё отфильтровал на нижестоящих L2 (где есть ACL), проблема этим костылём кое-как решается. На самой DGS-ке это решить не смог.

Иван, Руслан, мы ждём ваших комментариев!

2 terrible > Вы уже всё сказали. Правильно - это на коммутаторах доступа либо зарезать через Flow Meter + использовать Traffic Control, либо определённые пакеты вообще drop-ать. Но на самотёк лучше не пускать!

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

Правильно ли я понимаю, что защиты CPU от флуд атак на 36-той сери не будет никогда? Очень хотелось бы получить точный ответ, согласованный со штаб-квартирой.