nocproject.org

dvolodin: NOC-656 должен был починиться после вчерашних коммитов? Полчаса - полёт нормальный

а ещё вопрос: было несколько алармов (линк-пинг1-пинг2) , я им прописал root cause-ы, когда линк поднялся - всё как бы закрылось

хотя по факту - последняя железяка не заработала, т.е. пинг2 должен быть виден

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

насчёт алармов - наверное так потому, что при закрытии аларма никак не обрабатываются алармы "под ним"... по идее надо у них root cause сбрасывать?

застрял на конструкции a = ActiveAlarm.objects.filter(root__isnull=False) - ругается 'ObjectIdField' object has no attribute 'lookup_member'

dvolodin, привет! Читаешь irc логи по утрам? :)

а то я там понаписал в надежде на то, что всё же читаешь

да, должны починиться

отловил совсем странную проблему

при включеном epoll криво обрабатывались отбитые коннекты

dvolodin: а по второму вопросу? про сброс root cause зависимых алармов при закрытии основного?

да их тоже, наверное, закрывать надо

lexus-omsk, у тебя root cause заработал? Или ты руками прописывал прсто?

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

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

не заколебался это руками делать?

я думаю это заскриптовать не сложно

а как заскриптовать? Как определить, что является источником аварии

логически

мозгом

ну, скрипт логически мыслить не умеет ;)

если пинга нет, то падение еигрп/оспф под пинг файлед спрятать

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

не всегда

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

пинг фейл вообще ни счем не связан может быть :)

ну если нет линкдауна - то да...

мак потерялсо например :)

если линка нет - пинговаться по нему ниче не будет. А вот если еще и поверфейл и ППР у электриков - то линк-даун произошел из-за электричества. А за ним уже и пингфейлы пошли

только если есть мониторинг этих параметров и нок о них знает

может делать 2 аварии

линк даун и пинг фейл

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

под линк прятать падения роутинга, а под пинг прятать пинг фейлы

просто я считаю что простое падение линка это слабая авария

а пинг фейл - серьезная

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

zi_rus: а вот тут как раз надо добавить расстановку весов, потому что линк линку рознь

дело не в весе

но это уже, как у нас выражаются, другой бизнес-процесс

хоть 100500миллионов будет вес, все равно

мало ли чем там вес набился

а пинг фейл с большим весом

уже серьезней

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

например делать их в 2 строки

давайте поговорим про веса

:)

dvolodin, сначала надо научиться связность трассировать, а потом весам заниматься

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

линки у нас ведь есть?

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

давайте все-таки посмотрим частную задачу

как нам поранжировать железки

у нас есть конфиги интерфейсов

и есть линки

как найти самую жирную и толстую из двух железок?

да и линки надо взвешивать

для упрощения, скажем, можно принять вес железки за сумму весов ее линков

или как-то зашить в профиле

или, скажем, -- вес профиля плюс логарифм суммы линков

dvolodin, кольцо, вернее цепочка л2 свичей приходит на 2 разные РЕ, л3 интерфейс находится только на одной, но остальные линки равнозначны. если екнется одна, никто не заметит, если вторая - все навернется. что будешь делать?

Добрый день! после обновления нока на версию 0,7(4), перестали автоматом сливаться вланы с железок, в чем может быть дело?

аквтоматом никогда не сливались. С нока на железки - да, наоборот - нет

ух ты! а можно подромней на счет с нока на железки? :)

MindGames__: vc.vc_provisioning

Main -> Setup -> Schedules

так это как раз сливает виланы с железок, не?

Для железок, у которых есть set_vlan и set_switchport скрипты

не сливает, а заливает

хмм.. прикольно 4)

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

ага, только как этот скрипт прописать то? :)

сет влан

и вообще, MO по прежнему можно удалить только в консоли?

да

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

раньше сливались автоматом

Отловил роскошнейший баг в FreSSH, пока пытался понять, почему NOC не может прицепиться к свичам с Force10 SFTOS

Фикс -- в r7781

ржачный

FreSSH хочет, чтобы версию протокола и клиентского софта ему отдали строго в одном пакете

посмотрите, к чему мы там еще не могли ssh'ем зацепитсья, может пролечилось

хуавей ок

мх ок

7609 застре попробую