Доброго дня!

Нет ли известных проблем с 3526 при использовании на них igmp access_authentication ?

Суть проблемы: в одном из районов сети периодически "виснут" коммутаторы 3526. Перестают отвечать в management-влане; перестаёт работать dhcp-relay, snooping и т.д. Трафик при этом ходит, на арпы коммутатор отвечает, на пинги - нет. Ещё интересно: судя по tcpdump`у, свитч при всём при этом продолжает слать запросы на radius-сервер (igmp).

Единственное отличие от других районов, где подобных проблем нет - в этом районе на свитчах настроено igmp access_authentication.

Нашёл аналогичную проблему: viewtopic.php?f=2&t=155481&p=840311&hilit=igmp+access_authentication#p840175 . К сожалению, решения в паблик озвучено так и не было.

Ждём ответа с нетерпением, поскольку проблема проявляется массово. Спасибо.

Версию прошивки какую юзаете?

В основном 6.20.B09
Знаю, что есть немного поновее, но просто так перепрошивать тысячи коммутаторов не очень хочется. Поэтому и спрашиваю, известно ли о подобных косяках, и исправлены ли они.
Пока всё как по волшебству вылечилось отключением igmp access auth

В прошивке 6.20.B17 было подобное исправление для IGMP Auth, поэтому прошивку хотя бы на небольшом участке для анализа стоит обновить до актуальной версии.
Прошивку можно скачать здесь: https://cloud.dlink.ru/owcl/public.php?service=files&t=eb7e726c15ce32d6e857514c3c13d9d1&download

Благодарю

Не за что.

Up. Новая засада.
Куча 3526, прошиты 6.20.B18

Стояли какое-то время без проблем; сегодня ночью внезапно эти проблемы начались:
свитчи пингуются как-то так:


Если кое-как зайти и сделать reset system exclude vlan system_ip - сразу начинает работать отлично.
При попытке настроить заново, на этапе ввода

свитч опять отваливается. Если сделать dis dhcp_relay - "возрождается". Проблема массовая ; (

Загрузка cpu в полке 100%
Если на проблемном свитче просто отключить dhcp_relay - не помогает, cpu висит в полке.

Кажется, практически решилось добавлением traffic_segmentation на аггрегации.
Т.е. это 100% какой-то флуд (dhcp), видимо ?

До дхцп-серверов этот флуд не долетал.

Вопрос: каким образом обнаружить виновника в такой ситуации, и почему 3200 и 3028 рядом ведут себя как обычно?