Здравствуйте.
Столкнулся с такой проблемой на свитчах DES-3028: при прошивке устройств на 2.80b08 и включении на устройстве функционала flood_fdb получил 100% загрузку процессора. При этом на прошивке 2.50b08 такой проблемы не наблюдается.
Проблема имеет плавающий характер, то есть при включении flood_fdb может пройти и день и два прежде, чем он отвалится, а может отвалиться сразу. Доступен он становится тоже самопроизвольно, может час пролежать, может каждые пять минут подниматься и снова падать. Если в момент когда свитч доступен отключить функционал flood_fdb, то коммутатор начинает работать стабильно, проц не грузится.
Хотел бы узнать из-за чего это может происходить?

_________________
LanCom/PowerNet

в сислог он что-либо пишет во время отвала?

Нет, не пишет. Правда там, где включен функционал safeguard_engine в логе перед отваливанием свитча появляется запись Safeguard Engine enters EXHAUSTED mode. Но, мне кажется, при перегрузке проца и должна появляться такая запись. Там где этот функционал не включен свитч молча умирает.

_________________
LanCom/PowerNet

Аналогичная ситуация, как и в теме viewtopic.php?f=2&t=121012&hilit=flood+cpu

Включено flood_fdb, c клиентского порта прилетает 15+ тысяч пакетов в секунду, почти все 65-127 байт, поэтому канал не сильно забивают, но коммутатор на таких объемах просто умирает

Несколько сотен немного напрягают, но не смертельно. Больше двух тысяч, насколько помню, уже пошывают загрузку процессора до 70+

Приходится выключать flood_fdb.

Я так понимаю, что это реализуется чисто софтом, и ничего тут исправить нельзя? Каждый пакет проверяется?

Можно, конечно, включать flood_fdb только при необходимости, но никто не предупрежал, что ее лучше использовать именно так.

Так на старой прошивке вроде нет таких проблем? Или дело все же в pps (torrent?)?

_________________
D-Link Switches: Tips & Tricks

Чем больше pps - тем выше загрузка cpu. При pps в несколько тысяч cpu уже загружено почти на максимум, точно не помню, нет сейчас возможности проверить.

Тогда осталось выяснить какая связь между pps и flood_fdb. И почему на более старых прошивках такого не наблюдается.

_________________
LanCom/PowerNet

Если я правильно понимаю хотя бы общий принцип, то связь прямая - каждый раз при получении пакета с "плохим" src маком нужно обновить flood_fdb или что-то в этом роде, проверить существует ли еще конфликт маков, или один из хостов уже не передает информацию. Соответственно, когда это действие выполняется n тысяч раз в секунду, то cpu загибается. Но не уверен. Было бы интересно, конечно, получить комментарии представителей компании.
Мои предположения основаны на том, что функция софтверная.

Выяснилось, что на DES-3200 имеется похожая проблема, только выражается она чуть-чуть иначе. Если 3028 отваливается совсем из-за высокой загрузки CPU, то 3200 просто перестает отвечать на ARP. Причина в обоих случаях связана с мониторингом flood fdb.

_________________
D-Link Switches: Tips & Tricks

Какие будут предложения?:)

_________________
D-Link Switches: Tips & Tricks

Актуально!

_________________
D-Link Switches: Tips & Tricks

Тоже столкнулись с данной проблемой. На некоторых коммутаторах работает нормально, но на большинстве через время может уйти загрузка до 100%.

Ситуация вызвана тем, что flood_fdb (как и обсуждалось ранее) - софтовый функционал. Исправить это нет никакой возможности, рекомендация - использовать flood_fdb только для анализа проблемных ситуация и не держать его включенным повсеместно на сети.
Загрузка cpu будет напрямую зависеть от количества, типа трафика и пр, но каких-то конкретных значений pps сказать не представляется возможным.

Дабы не плодить мелких тем спрошу тут: существует ли на DES-30xx серии(конкретно на 3010G и 3026) функционал, аналогичный flood_fdb?

_________________
newbie

Нет и не будет