Поддерживаю. В нашей сети около 2,5 тыс. всякий зверей)) С каждым вытворяются такие чудеса, что обновление прошивки до актуальной решает их 95 случаев из 100.

я вам не завидую если у вас 2.5 тыс длинков ))

А кто сказал, что только длинки?) Но их большинство. Работают весьма неплохо при продуманных настройках и актуальных прошивках.

свят свят свят )

ИМХО. оборудование про которое написано 72 страницы на форуме про баги в каждой версии прошивки - не может называться "нормальным"
я бы охарактеризовал как дешевое и массовое.

Вы бы знали сколько багов мы передали таким монстрам как cisco и juniper. Там тоже есть проблемы с прошивками, хоть и не такие явные. И так же в каждой новой, что-нибудь да сломают. Потом еще препираются, что дескать сами виноваты.
Длинки по крайней мере оперативно стараются решать найденные баги, чем вышеприведенные монстры, которые просто зажрались и требуют на каждый писк открывать кейс, потом еще ждать неизвестно сколько и оплачивать поддержку. Месяц не продлишь, и "давай дасвиданья". И это не говоря о просто космической стоимости оборудования.
К том же DES-1210-28/ME/B2 вышел относительно недавно, баги в нем будут исправляться еще долго. На данный момент я бы сказал, что железка работает относительно хорошо. А вот модели DES-3200 сейчас укоренились и работают у нас как часы. Так что оборудование очень даже приемлемое в отношении цена/качество.

согласен, бывают баги и у других производителей.
но сказать что проблемы МАССОВО у cisco / huawei / juniper я бы не сказал, разница в разы.
для сравнения - huawei для свих коммутаторов выпускает как правило 1-2 прошивки за год , остальное патчи,
а тут прошивок штук .... "100пицот"
в случае неисправности - открывается case и всё в РАЗУМНЫЕ сроки - разжевывается и решается.

а в случае с этими коммутаторами - бодали не менее полгода, по факту так проблему полностью так и не победили.

О какой именно проблеме идет речь?

За 3 недели можно было отписать по моим проблемам?
Если с multicast-ом и traffic control-ем, ещё можно придумать костыли, на вышестоящем оборудовании, то с port_security увы никак.
Или как ещё можно ограничить порт в 3 мака?

(версия ПО 5.0.40) , конфигурация - та которую вы написали для нашей компании.
периодически коммутаторы "сходят с ума", в консоли сообщение что переполнен какой-то буффер , либо полностью теряют управление - нужна физическая перезагрузка (случается даже на одиночных! коммутаторах подключенных напрямую к аггрегации),
либо начинают штормить сеть управления.

имхо, отчасти проблема в том, что в вашей прошивке устройство нормально не изучать мак-адреса !!!!!!! (баг легко воспроизвести - после перезагрузки коммутатора с включенными устройствами !!!! - часть мак адресов с различных (или со всех портов) не изучается. маки изучатся только если переподключить патч-корд!
дополнительно с вашим рекомендованным конфигом на более свежей версии ПО 7.0.29 - данного "бага" уже нет, но ждем пока "проверят эту прошивку".

а также проблема совпадений хеша мак адресов, вот пример :
совпадение влана управления с маком BRAS и в момент совпадения 3х хешей , трафик льется уже "всюду где есть эти хэш".
как следствие - шторм

Command: show flood_fdb

Flooding FDB State : Enabled
Log State : Disabled
Trap State : Disabled

Value VLAN ID MAC Address Time stamp
------ ------- ------------------- ----------
7652 11 4c:b1:6c:1f:41:25 523829
5612 11 70:54:f5:a2:c5:ba 111751
5612 11 70:54:f5:a2:d5:ba 111751
7652 11 70:54:f5:a4:07:2b 523829
5612 1598 e8:b7:48:21:5b:00 111751
7550 1687 dc:0e:a1:97:55:e2 1221333
* address in hardware table

spirt
По traffic control. Проверено на прошивке 6.07.B052.



Коммутатор не пишет, на какой конкретно тип трафика сработал механизм traffic control. Функционала такого нет.
Mode shutdown, при countdown disable порт будет погашен сразу же, как коммутатор обнаружит шторм. Это несколько секунд, в пределах значения time interval.
Если countdown включен - то порт не будет гаситься в течении значения countdown (5-30 минут), но пока шторм обнаруживается - весь трафик на порту отбрасывается и далее не идет. При значении 0 трафик будет отбрасываться, порт никогда не выключится. Запись в лог будет по истечении countdown timer, если шторм еще продолжается.
Если порт выключен - автоматически порт поднят не будет - функционала auto recovery, как на DES-3200, пока нет, но мы запросили его.

В режиме drop шторм не логгируется. Это нормальное поведение. И мультикаст, и броадкаст при этом успешно режется до значения threshold (задается в Kbit/s)

По проблеме с port security.
Пишите на почту, а не здесь. Так работа по проблеме пойдет гораздо оперативнее.
Необходимая информация: конфиг коммутатора, количество записей в fdb, а также по пунктам - что и как происходит, как проблема наблюдается.
Фразы "мак не изучается" мало - нужно подробное описание в деталях. Как проблема выглядит, уходит ли сама и пр. Если проблема не воспроизводится на стенде - скорее всего, будет необходим консольный доступ до проблемного устройства в момент проблемы.

zyxelll
Какое общее количество мак адресов на устройстве? В среднем, какое количество mac per vlan?
Я не знаю, о каких версиях ПО вы пишете - таких версий, как 5.0.40 или 7.0.29, в принципе не существует. Вашей почты у себя я также не нахожу, поэтому сказать, какие и кто конфиги для вас писал я не могу.

В B052 сломали ACL:

На предыдущих прошивках использовали такие правила:

О проблеме известно, исправят в следующей версии ПО.

Только shutdown unicast так и не работает как нужно (срабатывает на любой unicast трафик). То что функция не работает известно давно, но коммутатор дает ее включить.

Получается, что если на коммутаторе использовать shutdown режим, то сеть остается абсолютно не защищена от unicast штормов. Я уже предлагал сделать unicast всегда в режиме drop, если уж это аппаратная проблема. Это было бы логичным решением, а не так как сейчас.

Ещё немного информации о потере MAC-ов при задействованном функционале port_security. Сегодня было 2 заявки от пользователей (причём один по схеме vlan per user, static ip, второй - vlan на дом, ip по dhcp), включены на соседних коммутаторах одного дома. Оба коммутатора с аптаймом около 17 дней, предыдущая перезагрузка - обновление ПО до B035. Решилась проблема (по-моему, временно) путём отключения port_security на порту клиента (MAC сразу же появился), затем port_security включается обратно, но клиент продолжает работать, MAC не пропадает. У обоих клиентов по логам видно частое моргание линка, которое прекращается после вышеуказанных манипуляций.

Говорят, на данных коммутаторах есть защита от статического электричества на FastEthernet портах. Как она работает, можно как-то удалённо определить её срабатывание? Неоднократно наблюдали ситуацию, когда жалуется несколько абонентов с дома (кабель не подключен), диагностика кабеля (в т.ч. и аппаратными тестерами) при этом проблем не выявляет, решается либо переключением в другой порт, либо перезагрузкой коммутатора по питанию.
А теперь к другой проблеме: после вышеуказанной перезагрузки на большинстве абонентских портов отсутствуют mac адреса до тех пор, пока не будет выключен функционал port_security.