Укажите пожалуйста в личку Ваш телефон.

У меня есть кольца составленные из разных коммутаторов: 3526 и 3028, я заметил, что в кольцах, где коммутатором закрывающим свой порт для создания логического разрыва в кольце оказывается 3028, подобные шторма возникают, а если на месте разрывающего оказывается 3626, таких шторомов никогда не возникает. на коммутаторах настроен ISM_Vlan, может это имеет значение какое-то...

Версия прошивки и Ingress Checking на DES-3028 отключён?

_________________
С уважением,
Бигаров Руслан.

А ingress_checking у Вас в таких топологиях выключен на этой модели?

Версия прошивки 2.31-B03, ingress_chacking отключен

Попробуйте пожалуйста прошивку которую я Вам выслал.

Нужно обновить на 2.41-B03.

_________________
С уважением,
Бигаров Руслан.

2.41-B03 не решает данной проблемы. Так же как и 2.52-B02. На 3028 через магистральный дискардинг порт проходит мультикаст, что в конечном результате создает шторм.

Что самое интересное, на дискардинг порт счетчик TX показывает по нулям. RX же пропускает по 50-80 пакетов в секунду. Из которых процентов 95 бродкаст, остальное мультикаст и юникаст.
Такие же показания только зеркально повернутые на соседнем свитче,куда смотрит дискардинг порт.

Тут же возникает вопрос. Пишут ли 3028 и 3526 в счетчики портов о прошедших через них бипидию пакетов?

Приведите, пожалуйста, пример настроек IGMP Snooping и STP.

_________________
С уважением,
Бигаров Руслан.

Отпишусь что у меня получилось в рамках решения проблемы.
1. Уменьшайте широковещательный домен, насколько это возможно (у меня этого нельзя сделать пока, но есть в планах).
2. Настраиваем config traffic control 1-6 broadcast enable multicast disable unicast disable action drop threshold 64
3. Убил трафик netbios, ipv6, лишний dhcp, лишний pppoe, tcp/455.
4. Обновил везде софт до актуального.
5. Выключил ingress_checking
6. Включил фильтрацию мультикаст групп.
7. Естественно, не забываем установить у одного из коммутаторов, который ближе всего к аплинку кольца, вес STP меньший, чем у соседей. С весами по разному игрался. Так же делал два меньших веса, но разные. Один основной рут, второй рут, если умрет первый.

Вроде все. После этого стало гораздо лучше. Редкие перестроения. Качество ТВ стало гораздо лучше, STP перестало пересобираться. В общем пока считаю, что проблема закрыта. В планах уменьшение широковещательного домена. И еще 3052/28 гораздо лучше живет в нашей сети, чем 35 серия. Стараемся что бы в транзите кольца не было 35 серии, и ставим его в тупиковые ветви и настраиваю ограниченные роли, что бы от туда никто не объявил себя рутом. 35 серия все равно по процессору не вывозит и периодически начинает перестраиваться.

Кстати, в больших кольцах на 35 серии pppoe incertion нормально не работает. Периодически клиенты не могут подключиться. Похоже, что проблема с нехваткой ресурсов ЦП, так что пришлось отключить. 30серия работает без проблем. Интересно кто нибудь сталкивался с аналогичной проблемой? Пока не сильно важно, так что не обращаем внимание.

Может, кому то поможет.

Спасибо Ivan E.! Все те же действия, описанные Вами, проделаны. Так же пока не удается уменьшить широковещательный домен. У нас несколько иная проблема: счетчики на транковых портых показывают, что через дискардинг порт все равно прут пакеты - юникаст, бродкаст и мультикаст.

Помочь реально может только просмотр результата комады sh flood на коммутаторах DES-30xx. Ибо при конфликте траффик с MAC адреса, не попавшего в FDB, пойдёт по все порты того влана, к которому принадлежит источник этого MAC.