Вопрос к тем, кто возможно сталкивался с даной проблемой.
Существует связка свитчей.
3828 - в ядре, к нему подключены свитчи 3026, к ним свитчи 1226G.
Всё по звезде.
Прошивки Build 4.00.B28, Build 4.01.012, 3.00.24, соответственно.

Возможно совпадение, но проблемы начались после замены серии свитчей в самом низу со стареньких моделей другого поизводителя на 1226П.

Суть проблемы:
Периодически отваливаются ветки между 3828 и 3026.
Линк при этом сохраняется.
В логах абсолютно ничего не фиксируется. Ну разве что если включить протокол STP - то фиксируется изменение топологии, так как нижние ветки перестают видеть рута.
Трафик со стороны 3026 в сторону 3828 идёт. Но несколько своеобразный. По статистике с отвалившегося порта - 5-20 юникастовых RX-пакетов/с и примерно 30 мультикастовых RX-пакетов/с .
При этом TX-пакетов нет совсем.
Пока по статистике мультикастов нет - всё работает, как только появляются мультикасты - ветка ложится.
Хотелось бы понять столь странное поведение свитча.

Цепляем к 3828 циску, сразу видим в её логах
WARN: 1/Invalid traffic from multicast source address 01:68:0f:8f:fd:52 on port 2
WARN: 1/Invalid traffic from multicast source address 5f:41:00:00:00:ca on port 2
WARN: 1/Invalid traffic from multicast source address 5f:65:00:00:00:50 on port 2
WARN: 1/Invalid traffic from multicast source address d5:86:ac:14:1c:14 on port 2
WARN: 1/Invalid traffic from multicast source address 9b:cf:e3:77:ec:38 on port 2
WARN: 1/Invalid traffic from multicast source address d3:e2:b7:12:61:42 on port 2
WARN: 1/Invalid traffic from multicast source address fd:ae:9c:da:a7:ef on port 2
WARN: 1/Invalid traffic from multicast source address 53:a4:ee:79:b8:0d on port 2

Циска это видит, кидает в логи, а длинк игнорирует и не замечает - это, как говорится, ладно.
Но проблема даже не в том, чтобы вычислить конкретное устройство или порт. Это сделать можно. Но это достаточно долго, учитывая, что до оборудования ещё нужно добраться.
Но как защититься от такой напасти в дальнейшем?

Требуется конфиг коммутаторов, схема сети с подключением по портам, описание действий step-by-step.

Всё выслал вам письмом.

Укажите точную модель коммутаторов на доступе - 1008 или 1226G?

И те и те.

Попробуйте с высланной в другой теме прошивкой для DES-30XX.

Спасибо, новые присланные прошивки на обе железки поставили.
Видим, там добавились дополнительные функции - их тоже обязательно протестируем.

Проблема осталась.
Причём, судя по всему, ноги у неё растут не от мультикастов.
Сегодня получили доступ к обоим железкам.
Единственное - не удалось подключиться консолью к 3026 - так бы картина яснее была.

Настроили зеркалирование всех портов, встали сниффером.
Ничего.
Дамп трафика в последние секунды жизни длинка могу выслать почтой, комментарии по адресам - дам.
Судя по всему - проблема именно в 3026.
Кто-то или что-то просто убивает хождение трафика с портов.
Трафик либо начинает ходить крайне медленно, либо перестаёт ходить совсем.
В логах свитча при этом - абсолютно ничего.
Загрузка процессора при этом не скачет - 7-8%.

Единственная взаимосвязь между разными такими ветками - связка 3026--1226.

Проблема решается, если заблокировать ветку в сторону "проблемных" свитчей 1226.
Завтра попробуем заменить "проблемные" свитчи на другие.
Либо трафик идёт от них самих, либо от абонентов, работающих через них, а модель свитчей - простое совпадение.
В любом случае, хотелось бы узнать, что за пакет нужно прислать на длинк 3026, чтобы он просто так вот взял и умер без всяких видимых следов.

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

Результаты неутешительные.
Проблема наблюдалась в 3х совершенно различных ветках.

В 2х ветках решилась полностью после замены DES-1226G на управляемые свитчи другого производителя с оптическим модулем (решили не рисковать).

На 3й ветке сегодня ещё будем экспериментировать.

Я один раз видел подобную картинку на снифере у себя в сети - умер порт на крайнем коммутаторе (это был des3526),при этом он частенько переключался в "замыкание", то есть передовал в сеть то, что на него приходило, причём не смотря loopback dеtection на 3526 штормило только в путь - порт не закрывался ни автоматом по loopback, ни кучками, и активность светилась даже при отключенном кабеле.
Если смотреть содержимое такого мультикаста это был просто набор случайных байтов.

LBD должен помогать если уменьшить до минимума значение интервала через который посылать служебные пакеты.

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


Вчера ставили несколько тестов с заменой оборудования на проблемной ветке.
Вывод такой. Если на проблемной ветке заменить 1226G на управляемый свитч другого типа или на неуправляемый свитч - проблема решается.
Если вернуть свитч на место - через некоторое (случайное) время 3026, к которому он подключен, перестаёт коммутировать трафик.
В логах 3026 при этом - никаких новых записей.

Все три 1226, с которыми проблема наблюдалась, из сети убраны. Попробуем собрать лабораторный стенд и понаблюдать за поведением, но почему-то мне кажется, что на стенде эта проблема не проявится.