Приколы с SNMP, IKS 6726.

[Maika]

   День добрый. В работе имеется кольцо на 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 запросы сделать реже...но хотелось бы решения какого-то... системного чтоли.

[Знайка]

Добрый день. Есть ли уверенность, что Zabbix взаимодействует с коммутаторами только по SNMP? Не производит ли он (внезапно) мониторинг доступности и других сервисов, SSH, например?

[Maika]

Нет, не производит. Уверенность 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, вланов...но откуда там сотни портов с неизвестными номерами...не понятно. Пришлось натравить регулярки, чтоб не создавали сь лишние элементы данных.

[Знайка]

К несчастью, известных проблем с SNMP в прошивке 5.8 для IKS-67xxA  нет Что бы понять, что происходит, приведите, плз, серийные номера всех 4х коммутаторов кольца в формате ABCDE1234567

[Maika]

Ну такое я вполне допускаю. Проблема как раз в том, что проблема неизвестная  Серийники пожалуйста: TAIAD1043343, TAHLD1042926, TAHLD1042845, TAHLD1042931.

А прикол с сотнями номеров портов, полученных по SNMP - это не только IKS 6726... ещё как минимум IKS 6824. Он существует со времен версии прошивки 4.x.

[Знайка]

Ага, спасибо. Раз в сутки - это более/менее цикличный процесс? То есть с достаточной точностью можно предсказать, что, скажем, SW1 "зависнет" в 15 часов, например?

[Maika]

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

[Знайка]

Это я к тому, что потребуется дамп трафика к коммутатору на период перед его перезагрузкой

[Maika]

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

[Знайка]

ну давайте тогда подождём его и пойдём терзать разработчиков

 

[Maika]

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

[Знайка]

На "быстрых" протоколах типа TRv2 такой недостаток непобедим в силу особенности их реализации. Перейдите на TRv1, думаю, в таком случае, будет работать стабильнее (хотя и медленнее).

[Maika]

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

[Знайка]

"если реально дёргать линк с высокой частотой, то любой протокол будет то блокировать" - спорное утверждение

[Maika]

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

[Знайка]

Будет петля в топологии.

[Maika]

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

[Знайка]

"Если основной линк рвётся, он их быстро поднимает" - он - это кто?

[Maika]

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

[Знайка]

"Он - это протокол turbo ring" - это не так, непосредственно протокол статусами портов не управляет. Так кто этот "он" из предыдущего сообщения?

[Maika]

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

[Знайка]

Хорошо, пусть так, хотя это и не так. А софт, этот, значит, живет где?

[Maika]

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

[Знайка]

Абсолютно верно. И что же, каждый коммутатор "блокирует backup порты"? Прямо из коробки?

[Maika]

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