(?:Quidway|Huawei) (?P<platform>\D+\d+)\s

т.к. пока нет возможности посмотреть, спрашиваю: что находится в noc.noc.mac_log коллекции?

история прогулок мак-адреса по сети

Ахринеть конечно жирная коллекция

Был бы Дима, сказал бы, что это нок поломал

chassisd[2000]: CHASSISD_IFDEV_RTSLIB_FAILURE: ifdev_create: rtslib_ifdm_add failed (Invalid argument) приплыли нахуй

ну бывает

оно еще пашет?

Пол сети легло..

Видимо само шасси мудит - при любой операции с re - kernel panic

Даже power off не дает сделать

На любом re

Вторая коробка живая хоть

Весело встречаю начало отпуска

@dvolodin по описанию везде обращение в jtac, это смерть железки?

что за шасси?

9208

и ребут ему не помогает?

Нет

На fpc к тому же ругается, ее выключение и ребут не помогают

Не может создать интерфейсы

выдерни ее

Естественно

оптику левую не ставили?

sfp+

Все равно не але

Ставили

выдергивайте оптику всю

Только из-за этого джунипер

и попробуйте поднять fpc

Не, уже с пол года каптит, новую не добавляли

да всяк бывает

оно бывает шину завешивает

их не зря лочат, в общем-то

Ну да

Программаторы тоже бывают у кабельных провайдеров)

Буду лечить, вся ночь впереди

там не в программаторах дело

А подробнее?

я насколько помню, ребята из Force10 жаловались, что кривые SFP+ завешивают им шину I2C

перидически

они тоже сначала давали ставить любые SFP+, потом плюнули, залочили как-то хитро и привезли нам ведро оптики в качестве компенсации

:)

С cts вроде такое было

я так понял, это общая проблема

там не звезда, а общая шина

и одно говно завешивает все

так что иногда советуют вынуть всю оптику и попробовать завести голую карту

Понял, спасибо

Похоже карта сдохла

зипа нет?

Может и не в карте дело

Заменил карту с failed, все равно бидэ

Все не оригинальные sfp на оригинальные заменил,

Сделал вайп, линки поднялись, что блять за фантастика.. Это было просто последним вариантом

Но карточка всё же сдохла

Добрый день! Не скажете, SNMP v3, я так понял, не поддерживается?

привет.

нет не поддерживается

Понятно, спасибо. А по SNMP у вас только в FM события летят, или еще чего собирает, чего не заметил?

по snmp собирается метрическая информация

по snmp собирается всякие uptime

в FM события это видимо трапы ?

да они летят

Да, трапы. Вобщем ясно, надо смотреть что будет работать, а что нет по отдельности. Спасибо большое!

эм большое пожалуйста

Да, трапы. Вобщем ясно, надо смотреть что будет работать, а что нет по отдельности. Спасибо большое!

Смотреть надо скрипты для железа в sa

ой

откуда вы все :) ?

я тоже в шоке

думаю покусали кого-то где-то что ли

/stat@comstatbot

comstatbot.xyz/chat/-1001030501606

откуда вы все :) ?

да вот, приобщаемся.

ну что же велкам

Была авария, все восстановилось, но некоторые железки не смогли отправить или не дошли трапы/syslog о bgp session established, теперь висит пачка алармов. Может по snmp проверять состояние пира?

что-то у меня опасение что так на каждый тип аларма придется делать проверочный скрипт

также и по ospf, eigrp может не придти закртытие

Ну либо snmp trap tcp

и еще 100500 протоколов

и сислог по tcp может работать

Только не все железки поддерживают

в этом проблема

http://pisun.blogspot.ru/2011/11/snmp-monitoring-bgp-sessions-status.html

SNMPv2-SMI::mib-2.15.3.1.2.192.168.130.1 = INTEGER: 6

ответ

вроде как договорились что такие закрывать руками нужно

ибо нет шансов что для всех отрывающих логов будут закрывающие

по snmp не прокатывает сессии мониторить?

Или уходим наоборот от этого?

Может быть много ситуаций подобных

По ресурсам кстати еще меньше жрать стал нок ?

в принципе, для протоколов для которых есть стандартные невендорские мибы, можно и сделать

Илья, по ресурсам он стал жрать просто какпец как меньше.