но вот от этого как

(ероятной причиной послужила DDoS-атака, которая была воспроизведена на стенде. ping -f в несколько потоков на ip коммутатора (не управляющий, а шлюз для абонентов) кладет его на лопатки!.. так что попробуйте отключать уходящие порты и найти, откуда идет флуд.)

что тут можно сделать ? асл л3, л2

_________________
админ 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)

Павел Козик предложил лишь одно решение: на соседних коммутаторах создавать acl на icmp в сторонуц шлюза (можно по мак-адресу) и накладывать на него flow_meter. это можно было бы сделать на 3612/3627, если бы на нем можно было применять flow_meter на cpu_acl...

Странно как-то, у нас в сторону шлюза такие ацл в стандартный пакет входят: разрешить пинговать шлюз + rx-rate, запретить все пакеты в шлюз. Полёт нормальный.

а можно пример асл .

и куда он пишется на домовые коммутаторы ?

_________________
админ 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)

Вот пару минут назад опять повторилась ситуация.
Подключились быстренько через консольный кабель:
загрузка свитча 100 %, в логах только сообщение о включение safeguard engine

Загрузка портов нормальная.
Записей в fdb - 108
Хотел посмотреть arp таблицу, но на команде:

Консоль зависла наглухо, и больше через неё не получалось зайти.
Пришлось пускать в ребут.
Хорошо заранее на него прописали статические арп записи со всех серверов.

при этом перестают обновляться счетчики на портах. так что даже и не увидеть высокое кол-во пакетов на портах (кол-во мегабит смотреть нет смысла).

У Вас к коммутаторам DGS-3600 подключены неуправляемые коммутаторы или управляемые без ACL?

И статистику можно снимать не только на коммутаторах DGS-3600, но и других. А ещё нужно задействовать на коммутаторах уровня доступа Traffic Control с режимом Drop, ACL и т.д.



Смысл снимать ARP таблицу при высокой загрузки CPU? "sh uti p" или "sh packet ports ..." ещё понятно, т.е. определить откуда flood приходит, а ARP таблица чем поможет?

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

Если бы бы флуд - с чего проблема бы решалась перезагрузкой устройства аж на несколько дней?

Для этого нужно знать первопричину зависания коммутатора, а я её не знаю, поэтому не могу дать аргументированный ответ почему помогла перезагрузка коммутатора.

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

Ну вот для её выяснения и хотели посмотреть количество записей arp

У Вас к коммутаторам DGS-3600 подключены неуправляемые коммутаторы или управляемые без ACL?

управляемые с acl, но коммутаторов 3612 20 штук и к каждому по 8-10 управляемых коммутаторов разных серий подключено (3028б3526,3100). это слишком утомительное занятие... хорошо, что ситуация больше не повторялась.

предлагаю встроить защиту от DDoS для адресов, не включенных в trusted

она уже есть, называется ACL.

А сколько Вы ставите rx-rate ?
И если я буду правило создавать для маски /24, то полоса будет для каждого хоста в этой маске, или одна на всю маску ?

rx-rate ставлю 64, меньше нельзя а то я бы и меньше поставил.
Зачем маска /24?
Я разрешаю трафик с dst-ip = gateway по протоколу ICMP + ставлю на это rx-rate, после чего запрещаю весь трафик на dst-ip = gateway.

Получается, что кое-как пинговать шлюз можно, но весь остальной трафик, направленный именно на шлюз - блокируется. Трафик, предназначенный для маршрутизации шлюзу под эти правила не попадает, а значит маршрутизироваться будет нормально.

если такой умный, то скажи как 3612 может сам ограничить поток icmp на себя?