На ряде свитчей DES-3200-xx (хх=10/26/52) в ряде случаев происходит потеря управления.
Свитчи серии 3028/3052 тоже бывают подвержены, но реже.

Симптомы - управляющий интерфейс свитча перестает отвечать на ARP.
На маршрутизаторе или соседнем узле из арп-таблицы пропадает запись проблемного устройства.

Если некоторое время попинговать свитч, что он как будто "просыпается", отвечает на арп и дает доступ.
При этом клиентский траффик свитч пропускает без проблем и перерывов.

Из-за этого у нас проблемы с мониторингом доступности оборудования.
Версии прошивок - 4.51.B007 для С1.

В логах при этом либо вообще никаких записей, либо штатное срабатывание защит типа PortSecurity / Storm Control или включение/выключение клиентских портов. Но это не обязательно, свитч может перестать отвечать, потом ответить, но в логах не будет ничего, кроме последнегшо успешного логина. Аптайм не сбрасывается при этом.


Настройке сейфгварда:

#show safeguard_engine
Command: show safeguard_engine


Safeguard Engine State : Enabled
Safeguard Engine Current Status : Normal Mode
=======================================================
CPU Utilization Information:
Rising Threshold : 80%
Falling Threshold : 50%
Trap/Log State : Enabled
Mode : Fuzzy

Подвержена лишь малая часть свитчей из всего набора (~3%).
Вопрос - как это исправить или хотя бы задиагностировать причину ?

Такая же проблема на 3526 но она была более глобальная. Придется меня железо, вопрос только на какого производителя.

А у вас случайно в это момент не "моргает" ли какой-нибудь порт?

Если подключится консолью что говорит show arpe ?

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

Иногда бывают записи о срабатывании PortSecurity / IMPB / StormControl - но мы не нашли связи, такие сообщения периодически бывают везде, а дурят только некоторые железки.
У нас стоит 1 запись PortSec или IMPB на клиентский порт, шторм-контроль лимитит для клиента броадкаст + мультик на 64 - минимальное значение.

в show arpentry при этом отсутствует запись для шлюза. Если шлюз попинговать с такой железки - то через некоторое время арп-запись появится, и всё на на какое-то время станет хорошо.

Что было попробовано:
- ставить safe guard ut rising 99
- вообще отключать Safe Guard
- ставить большой arp_aging time
ничего из этого надёжно не сработало.

Такое ощущение, что железка при каких-то непонятных пока условиях перестает обрабатывать часть arp-траффика, что и вызывает такой отвал.

Да, 3526 страдали от этого эффекта ещё сильнее.

Я так полагаю сотрудникам D-Link пофиг на проблему. Они под новое железо (глюч...) прошивки пилят.

Нам удалось существенно минимизировать проблему, помогла вот эта статья:

https://aminux.wordpress.com/2020/06/26 ... mt-no-arp/

Но это лишь устранение симптомов, а не обнаружение причины !