NShut писал(а):
3. поймать мы знаем как, как бороться не знаем. Мониторить все коммутаторы и все айпи на такое, не один dpi не справится, сам сдохнет скорее.
буду некропостером, вдруг кому поможет
, если после загрузки коммутатора, создать правило в таблице маршрутизации типо:
если за коммутаором подсеть 10.10.10.0/24 - то cre ipro 10.10.10.0/24 null - все, кто есть в arpe будут работать, новые записи тоже коректно добавляются, проблем с пропаданием записей тоже нет - зато кого нет не дойдут до cpu. Нагрузка с цпу уйдет, вариант не плохой, но если это правило оставить и ребутнуть коммутатор - то трафик с этой подсети перестанет вообще маршрутизироваться, т.е. надо удалять его и заново забивать. (не знаю какую аналогию привести - наверное ближе всего правила в iptables, работает до первого включения, после перезагрузки оно становиться "выше").
Второй вариант, если используется супервлан, добавить подсеть за subvlanom: config sub_vlan vlanid 101 add ip_range .....
у второго способа есть ограничения, вроде бы до 5ти диапазонов за каждым sub, нагрузка тоже уходит, но потестить долго не получилось т.к. используем много дробных сегментов и не влазим в ограничение.
Dmitry Luhtionov писал(а):
У меня CPU в 100% было при попытке вытянуть таблицу FDB по SNMP с количеством записей около 1000.
раз в пять минут стагиваю с коммутаторов таблицу arpe по snmp (до 2к записей), проблем с загрузкой не наблюдаю.