Maika

Ну хорошо, а почему истинный? Как это проверить? Субъективненько как-то. Разве для компании улучшить свой продукт для покупателя, пускай даже за отдельную плату, не истинно верное утверждение? И это учитывая то, что среди "усовершенствованной" серии MOXA нет консольных многопортовых серверов, очень удобных в использовании.

Ну я так понимаю, операционка вместе с софтом, реализующим все функции коммутатора, живёт в этот самом коммутаторе, в ПЗУ каком нть.. и прочих мискросхемах.. если нет - поправьте.

Это чей конкретно ответ ?

Ну софт, реализующий протокол turbo ring, в рамках которого он управляет на master'е статусами кольцевых портов.

Он - это протокол turbo ring. На master'е этот протокол ответственен за активацию backup линков в случае разрыва основных. То есть, как только backup порты стали активны, основной порт переходит в состояние backup и возвращается из этого состояния по ручному таймеру, не обращая внимания на то, если даже линк поднимется. Суть от этого не меняется, но появится возможность убрать последствия "дрожания" линков.

Я имею ввиду, что уже приобретено порядка 50-ти CN2650... и, конечно, не хотелось бы ради такой мелочи еще брать дополнитльные маленькие... когда CN-ка почти как надо работает)

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

Почему петля. Турбо ринг блокирует backup порты. Если основной линк рвётся, он их быстро поднимает. Так вот можно добавить фишку такую: когда основной линк порвался и backup порты включились, порт на том линке, который оборвался, переходит в состояние backup и в нём и остаётся (то есть в заблокированном программно backup состоянии) в течение таймера, даже если линк снова поднимется.

Сейчас посмотерть не могу..в разные города поставили системы, дамп там не снять... но по-моему да. Вам проще стендик собрать да проверить. Один компик да одна мокса с перемычкой. Я бы не прочь узнать ещё, об упомянутых вами моксах, в которых мультикаст заявлен.. а они принять его и выдать в RS могут? В мануале пишет, что вроде бы да... но точно бы узнать.

Ну, конечно, если линк итак был в блоке или не основной, то да.. но ситуация вцелом такая, что дергание происходит часто и на том линке, который по факту основной. Может, LAG-о подобное что-нибудь и спасет, но вцелом это не дело. А разве плохо было бы предложенным способом улучшить возможности протокола? Просто галочка "ручное восстановление" и "время переключения на мастера обратно"?

Тут дело не в стабильности - к ней претензий нет. Просто если реально дёргать линк с высокой частотой, то любой протокол будет то блокировать, то разрешать трафик на порту. А вот ручной таймер, скажем, на 5-10 минут сведёт на нет дрожание линка, вызванное любой причиной.... переключил себе и сидит на резервном.. а основной пускай дергается, и фиг с ним - в блок на полчаса и всё, каждый разрыв просто обновляет таймер. Скорость turbo ring - это в 1-ю очередь скорость устранения разрыва, а скорость восстановления при этом едва ли важна.

Да, но там скорее речь о выдаче, о принятии нет... а в чём грех принять на таком могучем устройстве, как CN2650? Стоит она чуть ли не больше всех преобразователей.

Ещё вопрос. Пользуемся технологией turbo ring v2, всё хорошо, но есть нюанс. Кольца в случае обрыва пересобираются быстро, однако, в случаях, скажем утечки памяти на кольцевых железках (из-за бага, например), линк может то падать, то снова восстанавливаться, и собственно, весь трафик прыгает, аля "то есть, то нет". Также из-за проблем на линии или в SFP-модуле линк, а вместе с ним и система колец, начинает дёргаться туда-сюда. Если ли возможность добавить в настройки коммутаторов типа IKS 6824 и 6726 опцию времени обратного переключения на восстановившийся после обрыва линк, задействованный в turbo ring? Чтоб принудительно master держал его в состоянии blocked в течение указанного времени после его восстановления? Это бы сущесвтвенно улучшило поведение колец в таких случаях.

Добрый день. Теперь по преобразователям вопрос. Для начала сразу скажу, что стабильность работы устройств NPort и CN - моё почтение. Вопрос такой: CN2650 в режиме "Socket UDP" принимает unicast и broadcast трафик и без проблем транслирует его в RS. Также агрегат способен выдать RS трафик в Ethernet в виде unicast, broadcast и даже multicast (хоть это и не заявлено). Однако, принять multicast в ethernet'e и выдать его в RS он не может, трафик просто игронируется. Планируется ли в дальнейшем это исправить или добавить? Или это так и задумано? Или, возможно, принять его можно только в спец. группу? Трафик попадает на порты точно, ttl приемлемый.

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

Нет, сейчас уже нереально. На сислог их посадил, могу статистику чере пару дней предоставить.

Ну такое я вполне допускаю. Проблема как раз в том, что проблема неизвестная Серийники пожалуйста: TAIAD1043343, TAHLD1042926, TAHLD1042845, TAHLD1042931. А прикол с сотнями номеров портов, полученных по SNMP - это не только IKS 6726... ещё как минимум IKS 6824. Он существует со времен версии прошивки 4.x.

Нет, не производит. Уверенность 100%. Кстати, заметил ещё такую штуку... повесил ACL (ip based) на порты, задействованные в режиме Turbo Ring, такого вида: 1 permit src X.X.X.X dst any udp dport 161, 2 deny src any dst any udp dport 161, 3 permit any any. Один коммутатор без проблем, второй тупо повесился. Ребутнули, перестал быть доступен из других сетей, зашли напрямую по mgmt влану с перебоями. Убрали acl - стало норм. Я так понял - он в режиме any/any зачем-то обрабатывает все пакеты, а не врубает режим "по умолчанию", который, как в cisco, например, не жрёт ресурсы... Я больше скажу... с SNMP у данной модели вообще проблемы. Взять хотябы стандартный mib, и попробовать опросить все порты.. с удивлением можно обнаружить, что портов там не 26, а на порядки больше...появляются какие-то порты с номерами из 4-6 знаков и их так много, что заббикс вешается тут же. Это вот если просто попробовать стандартный mib. Я понимаю, кто-то видит "лишние" интерфейсы вроде консольных, ip, вланов...но откуда там сотни портов с неизвестными номерами...не понятно. Пришлось натравить регулярки, чтоб не создавали сь лишние элементы данных.

День добрый. В работе имеется кольцо на 4-х коммутаторах модели IKS-6726A-2GTXSFP-T. Мониторились успешно через Zabbix. Всё исправно работало без нареканий 4 года. И вот третьего дня в сети был поставлен ещё один сервер Zabbix. После чего начались перезагрузки всех коммутаторов каждые 3-5 мин. с сообщением в логе "Warm start by Self Diagnostic Reboot", а один из 4-х коммутаторов вообще повесился наглухо. Помогло полное отключение SNMP на коммутаторах. А тот, что отвалился, вернулся после перезагрузки вручную и отключения SNMP. Мысль такая - видимо, два Zabbix'а своим количеством SNMP запросов уронили коммутаторы. Полез на сайт производителя, почитал Release notes прошивок и обнаружил, что в версии 5.7 (на момент нашей проблемы стояла 5.6) был устранён некий баг "SNMP memory leak". Ну, думаю, скорее всего тут и зарыта собака. Ну я, значит, собаку то откопал, поставил самую новую прошивку (сейчас стоит V5.8 build 21072216) и... таки да, помогло. Всё хорошо, но не совсем. Теперь проблема появляется но сильно реже, например раз в сутки, - один из коммутаторов возьмёт да перезагрузится. Это почти незаметно, однако, как говорится, мелочь, а неприятно. Хотелось бы узнать, пофиксили баг до конца или всё-таки какой-то костыль прикрутили? Планируется ли решение более кардинальное? Понятно, что можно и второй Zabbix убрать, и SNMP запросы сделать реже...но хотелось бы решения какого-то... системного чтоли.

Запрос отправите, куда следует?)) А лучше каждую неделю, чтоб народ не забывал)

Добрый день. Пожалуй, присоединюсь Как-то странно на оборудовании с поддержкой L3 не наблюдать ARP-таблиц.. Просто, кроме МОХА, я лично таких железок не видел. Может быть так, что нет ничего, но ARP есть. Но чтоб наоборот... Может разработчикам периодически доносить о этом? А то на каких-то там, простите, EDR-ах есть, а на таких железках, как IKS, - нет... ну странно же!

ACL на кадры STP повесьте, на этой модели вроде есть.

Ну, они же обещали рассмотреть вопрос... может напомнить им)) Посмотрел модель.. разницы с брательником EDR-810 рублей на 50. Куда там 200к??

Доброго времени суток. Ну как там с ответом по фильтрации LSA ?)) Есть продвижение?

Добрый день. Со времён последнего разговора вышло две прошивки на EDR-810-й. Можно узнать, - не добавили ли случайно фильтрацию маршрутов? Вроде, обещали рассмотреть. ) В change-log'ах ничего по OSPF нет, но мало ли...