Добрый день всем. Неоднократно повторяется проблема с коммутаторами 3627G. Они у нас в сети используются очень активно на 2-м и 3-м уровне. Проблема в том, что совершенно непонятно по какой причине, коммутаторы перестают отвечать на запросы по сети (перестает пинговаться ip адрес в любом вилане), помогает просто перезагрузка. Анализ логов не дает ничего, никаких сообщений об ошибках, атаках, спуфинге и т.д. Интересно то, что другие устройства, работающие через них, но по 2-му уровню, остаются доступными. На всякий случай, версия прошивки - Build 2.40-B19.
И еще одна проблема, буквально вчера, в одном из сегментов сети возникла подобная проблема: На магистральном узле установлено 3 коммутатора 3627G, подключенные последовательно друг с другом, от которых подключено около 60 узлов (жилые дома). 3-й уровень реализован на одном из коммутаторов (для каждого из 60-ти узлов отдельный вилан и в каждом вилане отдельный ip интерфейс). Когда отвалилось 90% сети, методом исключения выяснилось, что проблему создавал клиент, подключенный к одному из узлов, к порту FastEthernet (на узлах стоят d-link Des-3028), и после его отключения сеть восстановилась. Как защититься от таких проблем, и почему они в принципе возникают хотелось бы понять. Конечно можно предположить что виной тому статика по последней миле, проблема сетевой платы клиента и т.д., но почему это сказывается на всей сети, почему проблема в одном вилане, нагружает магистральный комммутатор (3627G) настолько, что он становится недоступен? Кстати, в логах в этот раз повторялось сообщение Possible spoofing attack from 00-21-91-9B-44-0E port 3, причем мак-адрес в сообщении - это собственный мак-адрес коммутатора 3627G.

По зависаниям - была такая же проблема, т.е. отваливается весь L3-функционал, L2 работает. Решилось обновлением прошивки. Думаю, представители D-Link подскажут вам актуальную версию.
По второму пункту - похоже на кольцо со стороны абонента, обычно спасает loopdetect на домовых свитчах.

Аналогичная и весьма серьёзная проблема, спасет только "enable cpu_rx_rate_control". Но и эту функцию используйте осторожно, после её включения у нас начинают страшно теряться транзитные snmp-пакеты.
Сейчас пробуем с помощью sFlow проследить за ситуацией. А вообще забили, заказали 7210...

Да, по первому вопросу - меняйте прошивку, у нас была подобная проблема на ней, и по моему с этой-же (ну очень старой) версией.