nocproject.org

а скажите, Network | BGP | Peer Down само должно закрываться?

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

Unbeerable, в ивентах посмотри, когда пришел Neighbor Up

Unbeerable, и сравни это с NOC-788

в ивентах в это время есть куча событий Peer state changed с подробным процессом

ну надо триггер сделать.

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

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

секунды совпадают?

может вообще event'ы по id сортировать?

а не по времени

dvolodin, давай попробуем, текущее положение вещей совсем не годится

попробуй в fm/classifier/__init__.py

for e in NewEvent.objects.order_by("timestamp")[:max_chunk]:

заменить на

for e in NewEvent.objects.order_by("id")[:max_chunk]:

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

или сейчас на форуме гляну

db.noc.fm.alarms.active.drop()

ага, уже. понаблюдаю сегодня

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

я не уверен, что id строго растет со временем

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

вот не уверен

но проверим

а где можно отписать пожелания для нового приложения ФМ, несколько неудобно что с текущем приложении Object и Subject находятся в противоположных столбцах таблицы, сначала смотришь "где", потом "что"

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

если делать свою нумерацию - это можно похоронить напрочь всю распределенность

я делал аналог sequence на mongodb

zi_rus: http://forum.nocproject.org/index.php?topic=57.0

уже

странный глюк

дискавери сносит и создает все интерфейсы одной циски второй раз подряд за двое суток в одно и то же время

монга не отлетает?

в смысле

монга на другом тазике живет, не бутялся

dvolodin, Дим, поглядишь NOC-786?

Я там думал еще доделать фильтрацию по МО

но у меня с лукапом не получается - он в параметрах передает лишний &id__referred=inv.macdb__vc_domain

в том же app interfaces - этого id нет и все отрабатывает

ну это тянется от extmodelapplication

упс - это по домену урл конечно

там не vc_domain, а sa_managedobject

оно уже юзабельно?

можно коммитить?

ну то что там есть - работает

собственно ничего сложного

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

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

zi_rus: помогла правка классификатора?

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

я бы до завтра подождал с этим вопросом

ok

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

acid232_: а зачем так?

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

а то руками грустно чото совсем)

_4ePTeHok, csv? через офис можно в секунду всем навесить

профиля интерфейсов?

ааа

я про МО профиль

не) то то понятно

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

=) а маки вот например снимаются )

мне флапы маков надоели)

вот и решил проставить профиля)

а что профиля на это влияют?

да, если обновлялся не сильно давно

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

_4ePTeHok, МАК дискавери?

угу

и можешь в таком случае пояснить, на что она влияет, я теперь ничего не понимаю

оно пишет только одну запись на мак в бд

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

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

в хистори будет флап

между железками и портами

те он при флапе не запускает дискавери, а сразу вносит изменения в БД?

дискавери как раз при проходе вносит инфу в бд

это при первом проходе, а при трапах о флапах?

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

в итоге маклог коллекция пухнет

трапы никак не влияют на дискавери

дискавери пока - только по своему шедулеру как я понимаю работает

профиль с запретом снимать маки на транковых портах решает вопрос

запрет это когда галки нет?

ага

допустим он собирает маки "show mac address-table", на железке на интерфейсах есть профиль который разрешает сбор маков и есть который запрещает - что будет происходить?

ну порты же конкретные

с тех где разрешено - попадут в бд, с тех что нельзя - нет

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

не профиль мо

а профиль интерфейса

профиль мо я даже не глядел)

посмотри, там тоже есть галочка

ну подозреваю что МО приоритетней

если логически

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

я про маки

раз это пер-интерфейс задается

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

zi_rus: если не будет портов, то и заходить не должна

теоретически так должно быть, но я же не знаю как вы это реализовали

доброго всем

zi_rus: посмотрел по коду

на железке должен быть хоть один BRIDGE саб с включенным MAC discovery

без этого не будет железяку трясти

дык а профиль МО ?

приоритетней?

если отключен mac discovery на MO -- он вообще даже думать не будет на эту тему

то есть нужна галочка в профилях объекта и интерфейса

dvolodin, Дим, по поводу статусов портов - разделения так и не произошло?

в инвентори бы очень понадобился admin_status в L1

пока руки не дошли

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

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

он в смысле мак

ну там пишется мо-vl-timestamp-interface

только учти что это дискавери

а значит дискретная информация

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

дык на то и направлен macdb

добрый день

сколько сейчас ИП адреса стоят ?

я слышал $12 один

у нас один /21 остался и все, а их на 2 месяца еле хватит

наты и в6

=)

Рт тоже мучается.

нечего было в6 динамить

да толку от него

контента все равно копейки

проблема курицы и яйца, контент туда не идет потому что юзеров нету

тут кроме яйца и курицы есть еще проблема бабла

ибо в6 это оборудование

в6 в оборудовании уже лет 10 как прописался

где-то больше, где-то меньше

dual-stack сделать можно

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

потом больше и больше, и контент за ними бы пошел

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

некоторые себе домой по сети в6 протащили, а юзерам все равно не дают. кто бы знал почему. некоторые говорят про проблемы в биллинге

угу проприетарные радиусы особенно

стартойпишные к примеру)

радиусы, netflow, всякие полисеры

на самом деле нефига было делать IPv6 адрес в 128 бит

48 хватило бы за глаза

с адресацией вида <as>.<n>

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

вообще проблемы бы не было -- выдал AS -- и сразу блок адресов за ней

ага, блин

по /64 на линк

еще раз -- не лезут они в CAM'ы нормально

тем не менее оно работает

вот сейчас легко шашкой махать, лучше так, а не так

все уже, поезд ушел

в4 пора хоронить, новый протокол есть, реализован и местами внедрен

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

���� ������