nocproject.org

hi

идея с запуском задач по alarm'у вполне удалась

на link down теперь запускается job, которые периодически проверяет статус линка

выводим наш FM на новый уровень ;)

красота

Надо добавить поиск причины и групировки алярмов.

но у меня такое чувство, что если я сейчас задам пару уточняющих вопросов, то у меня будут замечания :)

Например упал линк на магистрали и соотведственно пришол 10 пингфейлд..

технически выглядит так

http://code.nocproject.org/browse/noc/fm/collections/alarmclasses/Network/Link.json?hb=true#to203

секция jobs в alarm class

Так вот все эти 10 пинг фейлд должны отображатся когда нажимаешь "плюсик" на линк довн.

dvolodin, ты пропустил разговор где мы обсуждали то что ты отметил как интервал?

http://code.nocproject.org/browse/noc/fm/correlator/jobs/check_link.py?hb=true

вот сам job

zi_rus: почему пропустил

давай конкретное описание алгоритма и формулу рассчета

будем обсуждать и думать

алгоритм простой, интервал со временем увеличивается

формулу надо подумать

опиши :)

http://kb.nocproject.org/display/DEV/Home

В OpenDiscussions

А когда пинговалка запинговала эти 10 пинг фейлд, и линкап потерялся то целесообразно дёрнуть и посмотреть статус того интерфейса, закрыть алярм линк довн.

в момент возникновения аларма, с малой задержкой происходит первая проверка, потом по нарастающей, в реже и реже, когда достигается период например 10-30 минут таким и остается

dvolodin: rootcause - это сила! Можно посидеть и придумать очень быстрые и эффективные алгоритмы для управления многими алярмами.

zi_rus: вот подумай, напиши proposal

Guest77-ru, для начала надо на автомате надо линки в базу начать укладывать

реализовать, я думаю, дело 15 минут

Guest77-ru: ты говоришь про корреляцию по топологии

в принципе тут уже ничего не держит нас

Пример как связать ping faild & link down я приводил. Скрипт для укладывания линков в базу давал.

Алгоритмы поиска всех путей к корню или выходов наружу, определяющих доступность объекта приводил.

Алгоритм там несложный, да

Надо к МО добавить ещё одно поле, или привязать - "всех путей к корню или выходов наружу"

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

dvolodin, Guest77-ru, кстати я тут в пятницу подумал, планировалось повышать severity аларма, если он затронул много проблем, но есть такая мысль, предварительно рассчитывать и хвранить severity каждого МО и каждого линка, чтобы при падении не ждать пока все пинги от

валятся, а сразу поднимать аларм высшего приоритета

пока из нерешенных вопросов -- какой из интерфейсов делать root'ом при подении

ъ

нужна приоретизация железок

zi_rus: именно

Какраз поиск путей очень сложный алгоритм, я все его варианты скопипастил...

я думал насчет periodic'а

который заранее считает приоритет MO и интерфейса

Guest77-ru: дейкстра с модификациями

там несколько задач у нас

SPF, CSPF

Нет дейкстра сложен!

поиск всех путей и поиск всех путей с ограничениями

скажем так -- алгоритмическая часть меня не сильно беспокоит

а вот приоритеты считать - тут разные толкования

явно, что железка с MPLS более приоритетна, чем железка с L3

а L3 более приоритетен, чем L2

некоторые внешние порты очень важны

аплинк, или супер vip клиент

eBGP, наверное, более приоритетен, чем MPLS

о

может в interface profile добавим priority

и link alarm severity

Если иметь поле в котором есть все маршруты объекта то приоритет можно вычеслить изходя из количества конкретного МО в этих путях.

пусть пока из него навешивает

в профиль или просто переменная в свойствах каждого порта?

в профиль

можно сделать и 2 уровня

порт - профиль

настроено на порту - берем его

нет - берем из профиля

не задано в профиле -- берем default

Да и вес нужен только приочень сложных кольцевых топологиях, при звезде он не нужен вообще и в большинстве случаев тоже.

Guest77-ru: звезда - вырожденный случай плоского кольца :)~

давайте не будем говорить "не нужен" :)

двухшаговый поиск приоритета я могу сделать

далее, по новостям FM

поборол проблему с парными alarm'ами

для классов вроде ARP MAC Changed

суть такова

там дискриминатор определяется по (ip, from_mac, to_mac)

Ну в том алгоритме который я приводил для связывания линк довн и пинг фейлд, и только что для запуска проверки интерфейсов только после востановления пингов весы для звёздной топологии не нужны.

соответсвенно, при флапе туда-сюда поднимается 2 аларма

(ip, mac1, mac2) и (ip, mac2, mac1)

Ладно, надо отлучится.

поборол сортировкой значений полей

теперь все эти события падают в один alarm

а такое сможешь разрулить: "... in vlan 2337 is flapping between port and port " - порты не указаны, это значит флапает в VPLS между двумя PEшками

то с одной приходит, то с другой ( на третью

)

надо смотреть последовательность событий

dvolodin, она такая http://pastebin.com/R8HAQvuT :)

7600 ?

ага

ES20-е?

ES+

один фиг, деревяшка :)

ругается PE ?

да

MAC приходит то с L2, то с VPLS ?

нет

там вплс (vfi) , 3 РЕ, приходит то с одной, то с другой

это жалоба от третьей

и матерятся, надо думать, все PE-шки, кроме первых двух?

куда этот MAC залетает

так?

когда вплс на трех РЕ и ты говоришь "все кроме двух, это странно звучит"

если у тебя больше 3 PE

*"все кроме двух", это странно звучит

то будут ругаться и другие

ну да, наверное, больше трех пока не было

жопа в другом

нет информации, в каком это VPLS

по влану можно определить

да ну

:)

что не так?

что мешает двум разным клиентам сделать себе vlan 2337?

и гонять его через свои vpls'ы?

у тебя полукольцо, терминированное на 2 PE

верно

которое флапает и в нем перестраивается топология

так?

так какое тебе дело до клиенских vlan'ов?

ты знаешь, оно не совсем флапает

ты вообще про них, считай, ничего знать не должен

ну не суть важно

тебе один и тот же MAC падает в разные PE по очереди

ну да, это логично

я бы даже сказал, очевидно

как он до жизни такой дошел, не важно

STP там перестаивается, или клиент так чудесно подключен

у тебя есть MAC и есть VLAN

VLAN - вообще ничего не дает, так как у тебя там может быть куча клиентов

которые используют этот VLAN id и по q-in-q упираются в PE

так?

в нормальной схеме, may be, у нас - нет

если ты форвардишь клиентские vlan'ы в VPLS

влан - это клиент, у нас редко берут q-in-q

ну тогда да -- шансы что-то установить у тебя имеются

тут если только с базой маков поиграться

в общем резюме такое

флап мака в VPLS - можно сделать отдельное событие, когда известен только MAC и VLAN

можно на всех PE-шках подшить это к одному alarm'у

выдать более осмысленную диагностику можно только в случае, если ты не гонишь клиентские vlan'ы

а если допустим гоню? разве там будет светиться номер клиентского влана, а не только верхний провайдерский?

эээ

как у тебя верхний провайдерский vlan вообще в vpls светится?

эээ

ты его на входе снимаешь

и на выходе вешаешь

разве?

ну если только SIP'ы по другому делают

нет, ну да, наверное, в мплс пакете будет только клиентские данные - его q-тег и пейлоад

ну да

но причем тут это

1-2-3 MPLS-метки сверху и фрейм с клиентским vlan'ом

в логах на входе в РЕ

для РЕ - существует только провайдерский лван

*vlan

с чего это он мне в логах будет пусать что мак флапается в каких-то клиентских вланах?

PS могу рассуждать только теоретически, на сети есть q-in-q, но проблем с ними еще ни разу не было

возможно

там явно еще cisco-specific заморочки могут быть

я VPLS'ы только на MX дрючил, и еще в лабе на Huawei

в то время ES20 был сырым и глючным неработающим барахлом :-/

ладно, поехали дальше

да

в inventory -> interfaces

допилил combobox с managed objects

вроде paging вменяемый стал

я бы не сказал что пейджер - это решение

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

в рамках доброго подкола - ты видел, как железнодорожники продают билеты?

интерфейс оператора :)

не довелось

жаль

там действительно интуитивно понятный и удобный интерфейс

но нам до такого - далеко

значит знаешь к чему надо стремиться

оператор просто вводит мешанину букв и цифр в черном окне

на каком-то подонковском диалекте ассемблера :)

видимо я не понял сарказма

это надо видеть просто

вживую

интерфейс времен ЕС ЭВМ в виндовом окне

лично я не вижу выгоды иметь преимущество перед убогими, надо найти того, кто лучше, и превзойти, тогда может что-то получиться

имя будущей жертвы назовешь?

dvolodin, для ФМ - обойди IBM NetCool

а вот забавный вопрос -- надо ли?

что это даст и что получится в результате?

философские вопросы по утрам на канале #nocproject.org

надо же проснуться :)

кому даст? пользователям будет возможность бесплатно использовать фолт менеджмент высшего уровня; тебе, ну не знаю, ради чего ты развиваешь нок, вот это и получишь; а еще это будет одной из частей единой программы для комплексного управления сетью,

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

ну ладно, хотя слово "бесплатный" можно исключить

внедрение любого фолта - это серьезная работа и определенные затрары

затраты

я тоже сомневался над этим словом

на фоне которых стоимость софта и лицензий - не самое существенное

все же стоимость софта и стоимость поддержки/внедрения - разные вещи

ну тем не менее

когда есть RHEL, Centos не теряет популярности

centos не разрабатывает софт

а просто билдит готовые rpm

ну, утверждается, что ряд своих патчей у них таки есть

(не то, чтобы я их видел)

dvolodin, все же я говорю со стороны пользователя

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

скорее, ещё меньше :)

ред хат тоже не все разрабатывает

в смысле?

дождемся альтернативных сборок NOC со своими патчами ;)

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

dvolodin: я ж показывал на шабу ;)

там вроде бы тоже есть патчи.

и живёт оно не в /opt/noc, а согласно fhs

это нефункциональные все-таки

данное уточнение прозвучало только сейчас ;)

а в сборке вообще функиональные вещи добавляют обычно лишь в случае невменяемого апстрима

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

хм... extensions.nocproject.org ?

как правило, нужны сильно специфичные вещи и отчеты

которые больше никому не интересны

добрый день

ну что, можно апгрейдиться ?

дерзай

да в принципе, можно

вроде расколбас с поллингом преодолели

zi_rus: у нас еще была проблема с положением NS записей в reverse зонах

она ушла?

не в реверсах, а во всех

после твоего патча теперь нс в самом низу рисуются

больше не менялось

а что-нибудь надо, подключать/править в конфигах ?

dvolodin, а смотрю в прямой зоне так посреди зоны и торчат

misak, нет

zi_rus: проверяй реверсы с патчами

Обновляюсь

dvolodin, ок нс'ы поднялись, а по отстпу так и не определились

*отступу

dvolodin: вроде сохранилась проблема NOC-656... по крайней мере на epoll и kevent... хотя вот за несколько часов с последнего обновления проц в 100% не уходит, но трейсы те же сыпятся

zi_rus: по отступам ты не написал вменяемого алгоритма

lexus-omsk: как это у тебя одновременно по epoll и kevent летит?

почему одновременно, разные варианты пробовал

имеет значение, что устройства, на которые он ломится, не живые?

dvolodin, как так, я дал значения, а ты потом начал развивать, была одна переменная, я сделал 2, ты - 4, да еще и в конфиг их захотел запилить, и бросил

по-моему, только на них вылетает... хотя не уверен

dvolodin, ты коррелятор поломал

dvolodin, http://pastebin.com/PqLbdrE8

lexus-omsk, у меня kevent работает без трейсов

zi_rus: это пролечится само

перезапусти его еще раз

нет, не сработало

mongo noc

db.noc.schedules.fm.correlator.drop()

так помогло

какой грубый способ

это переходящее, больше не будет

да не

я в отдельные поля вынес параметры графика

работа кипит)

а то

dvolodin, как насчет статуса интерфейса в inv-interfaces?)

цвет значка link предлагаю менять

патчик давай

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

и это при трех состояния

up - down - admin down

а еще есть err-disable

даже 4 состояния

там надо определиться откуда и как брать статус. Я предлагал брать из бд дискавери(он же куда то кладет status), а затем обновлять по необходимости из get_int_status/fm - нужно тогда чтобы они в одно место записывали результат.

err-disable - это down

zi_rus, в скриптах сейчас 2 состояния для status - true/false

admin/oper в большинстве скриптов одинаковые вещи

если уж докучи - то порт может быть loopback detect blocked, которое отдельным скриптом только выявится.

т.к. на ежах к примеру нет err-disable понятия.

dvolodin, статусы то разделили? Я чот упустил когда.

не разделили пока

ты в шапке раздели, скрипты допилим сами.

может сделать oper status булевским и отдельное поле с причниной false ?

имхо усложнение.

или вообще так

status -- это oper status

а reason для false -- administratively down, err-disabled, link down

то есть ответ на вопрос -- живой или нет

и отдельный -- почему неживой

а если stp...Up, но discarded?

stp - это ж отдельный скрипт со своими состояниями... мне нравится (на первый взгляд) вариант с status и отдельным полем под причину

lexus-omsk, дык loopback тоже отдельный

я думаю, надо оставить get_interface_status как есть

и сделать что-то вроде extended_interface_status

гм. и дергать железку несколько раз?)

ладно, давайте сделаем в inv-interfaces хотя бы булевое представление статуса.

если тебе надо знать, что порт лежит или стоит -- дернешь статус

если хочешь знать, почему лежит -- дернешь extendend status

dvolodin, там проблема в том, что будет парсится вывод одной и той же команды. Т.е. 2 раза дергать одно и то же

почему?

сделайте хоть нормальные oper и admin status.

Vty-0#sh int statu

Port Admin: Up

Current Status:

Link Status: Up

Port Operation Status: Up

и это в одном выводе.

Port Admin: Down

Current Status:

Link Status: Down

Link Down Reason: Port Admin

как пример для ежа

я тоже за вариант, чтобы сразу что и почему выводилось, а не если хочешь так то этот скрипт, а если по-другому, то вот этот

что такого что он сразу выведет нужную информацию

сделайте необязательными параметры

потихоньку подтянем скрипты

давайте все-таки определимся, какие скрипты подтягивать

get_interfaces не хочется

это все-таки статика

там и так снимаются оба статуса

она полезна для инициализации статуса ифейса с бд без лишнего вызова скриптов

и актуализации состояния в долгосрочном периоде

при необходимости обновления статуса пусть дергается get_int_status

при прилетании трапа от FM - пусть будет обновление статуса ифейса в БД

ты же не будешь дергать скрипт при каждом отображении объекта в интерфейсе inv-interfaces

проще из БД брать состояние "средней" актуальности, сформированное get_interfaces/FM/alarm_job, и отдельно выведенной кнопкой - update int status, для актуализации статуса "прям счас" - запуском get_int_status.

с учетом трапов, состояние будет вполне актуальным

и я почти уверен что в подавляющем большинстве случаев будет не хуже чем от запуска скрипта

ну там будут возможные размолвки

типа трап потерялся

в общем метод кнопки "обновить прям счас" - я бы оставил

для контроля уж если на то пошло

_4ePTeHok, для потеряных трапов и введены недавние джобы

это если трап о поднятии потерялся поможет. А если трап о падении ифейса потерялся - какой там джоб)

алярма то нету

если это единственный линк до МО, то будет пинг файлед аларм, а к нему соответствующие проверки

если не единственный значит есть как минимум 2 МО которые в состоянии прислать трап, те и так невысокая вероятность потери уменьшается еще сильней

ну пусть так, но я бы оставил возможность проверить сейчас.

кстате, dvolodin, а можно же сделать, чтобы FM брал при падении линка инфу из инвенори, и соответственно "обогащал" инфу в алярме.

конечно надо оставить, вернее наоборот, реализовать

_4ePTeHok, тык он вроде так и делает, дескрипшены дергает

т е добавлял парный порт с другой стороны

к примеру

та железка(если линк для нее аплинком является) ничего не сможет отослать)

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

ну я пока ручками..)

медленно но верно)

я как раз хотел пробить, чтобы автозаполнение сделали

а потом уже эту информацию в фм целях юзать

это надо какой то task в шедулере делать

да зачем, есть дискавери, на него и надо это вешать

чтобы с периодикой проверял и вносил изменения в линки

дискавери не определит маки/lldp нейборов

пока что

это же построение топологии по сути

я думаю, что все что связано со сбором глобальной информации по сети должен делать дискавери

автообнаружение МО, МО version inventory, линки на МО, маки на линках, ip, lldp, etc. все это должен делать дискавери

зашел, допросил, ушел, записал

получится этакая "ушатывалка" железок_

:)

с периодикой раз в несколько дней - не проблема

автоматизатор аварий :)

пришел "слышь чо, есть маки? а если lldp найду?"

а железке потом оправлятся 2 дня0

)

ага

но по логике согласен..

в случае если железка говорит чо то не то: читай exeption self.cli("shutdown")

не, config erase & reload)

шатдаун кросплатформенный :)

на ежах нету команды выключить)

только ребут

а вы страшные личности...

даже думать о таких вещах страшно :)

alarm jobs проверили на практике?

dvolodin: кстати, давно спросить хотел - это бага или фича, что дискавери лезет на железяки, у которых не стоит крыжик is managed?

бага

скоро устраню

ок... это я к тому, что NOC-656 валится только на таких железках... т.е. которые сняты и висят только для истории (конфиг в основном)

dvolodin, интерфейс cm_cm я так понимаю переводится будет не скоро да :)

freeseacher: переписай :)

там несложно...

Может

Господа...

вот есть у меня префикс /11. А надо мне его расширить до /10 - что можно сделать?

mikevlz|3, нее. там как раз сложно :)

создать такой же, но /10, а старый потом удалить? В нем куча вложенных префиксов поменьше - их автоматом перенесет?

lexus-omsk: валится на недоступных?

да

перенест автоматом

mikevlz|3: rebase prefix

если в другое место

dvolodin, ребасе поломан.

или создать новый и удалить старый

freeseacher: это как это поломан?

не, все там же, vrf не меняется, тем более у нас он один

Может нафоруме написать для обсуждения маленький драфт по поиску причин проблем в сети? Там удобно будет обсудить. Кроме того там можно было держать эффективные и простые алгоритмы.

он не позволяет перенести в тот же vrf

я вроде даже багу создавал

мы потом заплатку писали в консоли

а нее

не так

он не позвояелт перенсти в такой же префикс в другом vrf

dvolodin: есть предположение, что именно на тех, где is_managed не стоит... хотя нужно помониторить ещё, может и на всех недоступных

traceback кинь еще аз

а нет трейса :)

вполне себе ошибка через веб обрабатывается

хотя может ты и lexus-omsk-у отвечал

Cannot rebase prefix to self

сработало, спсб

удаление

перляне есть ?

dvolodin: http://pastie.org/4655684 - проверил на просто недоступной - тоже падает

lexus-omsk: понял, да

lexus-omsk: http://pastie.org/4655740

попробуйте патчик с разными поллерами

на доступных и недоступных хостах

Спасибо, только, наверное, уже завтра

freeseacher: где-то на просторах каналов бегали. А что ты от них хочешь?

мех и мясо

:)

мех мексиканского тушкана и мясо, упакованное в жестяные банки?

evyscr, я чегото пропустил. это к чему было ? :)

про перлян ?

да

что еще от перлян надо, кроме меха и мяса

аа. я гетолку делаю для ипама

"мексиканский перлян" :)

уникальный вымирающий вид

http://pastie.org/4655795 сильно криво ?

эх, наконец-то я добрался до своих json с трапами ежика..

хех) Sep 9 2011

почти ровно год прошел)

еще подожди

до выходных

обноваился - отвалился noc-probe

2012-09-03 15:55:27,331 Launching noc-probe[#0]

2012-09-03 15:55:27,336 Daemon noc-probe[#0] started as PID 43460

2012-09-03 15:55:28,348 Launching noc-correlator[#0]

2012-09-03 15:55:28,354 Daemon noc-correlator[#0] started as PID 43461

2012-09-03 15:55:28,356 noc-probe[#0] daemon is terminated with status 1

2012-09-03 15:55:29,358 Launching noc-probe[#0]

2012-09-03 15:55:29,365 Daemon noc-probe[#0] started as PID 43466

2012-09-03 15:55:30,369 noc-probe[#0] daemon is terminated with status 1

сменил с poll на kevent - то же самое

zi_rus, ну я иссью сделал, пока закоммиттят может и 9е наступит)

dvolodin: http://pastebin.com/N4pShm5i

FreeBSD/select poller, трейс от noc-probe

логи пухнут

стоял poll - оно просто падало, kevent -тоже, с селектом работает, но так, что лучше бы уж падало

а корреллятор должен давить повторяющиеся ивенты?

у меня допустим приходят по syslog/snmp одинаковые

ох уж эти ежики. влючаешь трапы - так оно пока всю историю не вышлет - не успокоится...

zi_rus: у тебя бсд же?

так получилось

какой поллер стоит?

кевент

а то у меня снесло башню noc-probe демону, причем это не зависит от типа поллера, походу.

у меня не жалуется

хе

короче, noc-probe в новой редакции поллера валится, если ему надо снимать стату с железки, которая не существует, или с порта на железке, которого нет.

раньше пахало :)

что? собирал? успешно? :)

у меня пробе не работает, видимо поэтому и не валится

=))

Вот предлагаю для дальнейшего развития FM обсудить возможные алгоритмы основаные на топологии сети.

Открыл на форуме тему http://forum.nocproject.org/index.php?topic=136.0

ее сначала надо уложить в бд.

=)

+1

В которой выложил 5 алгоритмов связывающих аварии LinkDown, LinkUp & Ping Faild и поиска причин алгоритмами основаных на топологии сети.

"по воле")

по волЕ, вычИсляемый

=)

zi_rus, грамарнаци?)

почти, я от таких текстов слов начинаю пугаться

даННый

получеННого

отсудствует - это вообще абзац

Ловите скрипт который уложит все ваши линки в базу: http://pastebin.com/hHkz1JtB

Эсли - а про это просто нет слов

ыы

Ну откорректируйте очепятки, я спешил.

Эсли?

эт сначала надо топо.дот построить и скрипту скормить?

Да, запускаешь топологи дисковери, потом этот скрипт с /opt/noc/scripts/

Скрипт можно запускать много раз..

ладно, меня тут уже выганяют.. Дописывайте свои алгоритмы в туже тему, чтобы они не терялись.

Там же можно обмениватся своими Alarm Trigers и Event Treegers изменяющими Аварии на основе топологии.

Ато пишем в чате пишем, а оно теряется и в нужный момент сложно найти..

Ладно, пока, завтра посмотру ваши алгоритмы для FM на основе топологии.

NOC-666

символичненько

ежик запустился

и зло пришло в этот мир :)

бгг

я и не обратил внимание

символично что ник еще у меня такой в тему)

ага

кстати существующий Link.json надо править, там имена у ифейсов неполные, цифровые..

я думаю все нужно сводить к тому виду как на железке выглядит.

перетащил version_inventory в noc-discovery

обживаем scheduler'ы

а можно сделать в веб морде где нибудь пункт дискавери, где галками выставлять - что снимать, а что не надо?)

в конфиге