Имееется четыре 3526 в цепочке, прошивка 5.01 b14
Первый свитч упал в debug (не известно по какой причине, может из-за остановившегося вентилятора).. Тут же умерло все (включая управление в отдельнов влане) что включено в следущий за ним 3526 и последущий третий 3526.. Четвертый (крайний) остается жив.. На всех свитчах включен Broadcast,DLF шторм, Loopback detection (на основе портов и вланов - пробовали по разному), SafeGuard Engine. НИКАКИХ сообщений в логах.. Просто подлючаешь проблемный свитч в порт вышестоящего свитча - вышестоящий свитч через 10 сек молча умирает, (по COM порту управляется, показывает большое кол-во Unicast пакетов на тот порт куда включили свитч в состоянии дебага) через 2-3 сек умирает свитч который стоит еще выше. (по ком порту управляется, на аплинке флуда не показывает (!) совсем - немного каких-то пакетов..) ;-((
При перезагрузке эти свитчи на которые флудят тупо встают на этапе загрузки и не грузятся, покуда не выташишь патчкорд по которому флудят..

Раньше еще на 4.01B9 я сталкивался с 100% аналогичной ситуацией когда в 3526 абоненты подключили горелую 8портовую свитч-"мыльницу" .

Вот и вопрос собственно - что это такой за хитрый флуд..что на него Storm Control не реагирует.. И как сделать так чтобы при флуде удаленное управление не отваливалось.. Есть какой-то СPU Filtering - может кто уже прописывал - как сделать чтобы только 80 порт, SNMP, 22 порт, ICMP с двух управляющих подсеток были открыты, а все остальные левые пакеты свитч игнорировал.. ? Или при флуде CPU Filtering не поможет?

Я надеюсь у вас управление вынесено в отдельный VLAN. У Вас этот свитч стоит сейчас в сети или Вы его сняли? Попробуйте пожалуйста на нём прошивку которую я Вам выслал.

Естественно, управление у меня вынесено в отдельный влан.
В прошлый раз прошивку так же выслали. )

Проблема в том, что подобные ситуации довольно редки. Это не вирусный трафик. ИМХО коммутатор умирает НЕ от IP трафика, а от непонятного мусора на сетевом или канальном уровне который ему "засылает" подключенное к нему "глюкнувшее" оборудование. Пробовал разобраться - такие пакеты даже сниффером не ловятся - сетевка бешенно моргает а программа говорит, что кол-во сграбленных пакетов почти нулевое..

Может быть из-за того что у меня на каждом коммутаторе стоит ACL разрешающее только прохождение IP трафика..А подобный шторм просто намертво ложит из-за них CPU? Или ACL на 3526 все-таки аппаратное?

create access_profile ethernet destination_mac FF-FF-FF-FF-FF-FF ethernet_type profile_id 2
config access_profile profile_id 2 add access_id 101 ethernet destination_mac FF-FF-FF-FF-FF-FF ethernet_type 0x806 port 1 permit
config access_profile profile_id 2 add access_id 201 ethernet destination_mac FF-FF-FF-FF-FF-FF ethernet_type 0x800 port 1 deny

create access_profile ethernet source_mac FF-FF-FF-FF-FF-FF profile_id 3
config access_profile profile_id 3 add access_id 101 ethernet source_mac 00-00-00-00-00-00 port 1 deny


create access_profile ethernet ethernet_type profile_id 8
config access_profile profile_id 8 add access_id 1 ethernet ethernet_type 0x800 port 1 permit

create access_profile ethernet source_mac 00-00-00-00-00-00 profile_id 9
config access_profile profile_id 9 add access_id 1 ethernet source_mac 00-00-00-00-00-00 port 1 deny

p/s правильно понял, что если управление в отдельном влане то СPU Filtering ничем горю не поможет?

ACL в этой серии конечно аппаратные, а вот CPU Interface filtering в софте. В вашем случае эта функция не должна влиять на работу.Но некоторый трафик в зависимости от настроенного функционла идёт на интерфейс CPU из отличных от Management VLAN-ов. Т.е. например IGMP запросы при включённом IGMP Snooping, STP BPDU при включёном протоколе семейства STP, наример RSTP вообще не видит VLAN-ов и т.д.