nocproject.org

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

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

Skripnik: а что в нем корявого-то?

zi_rus: В основном -- interface profiles и классификация интерфейсов

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

опять пирули

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

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

уже хочется? :)

очень!!!

алгоритм уже есть

нужен регулярный процесс его применения

шедуль?

или лучше вместе с дискавери?

а еще лучше только когда информация изменилась

вместе

но там нужно еще и модерирование найденого

например?

не понял

сейчас есть алгоритмы восстановления топологии по MAC'ами, CDP/LLDP/FDP, *STP

zi_rus: топология в базе все-таки должна менять после подтверждения

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

тут есть блокирующий фактор один

сейчас в NOC дофига разных scheduler'ов

для periodic task'ов, конфигов, зон DNS, несколько штук для разных discovery

очено хочется не добавлять еще несколько, а унифицировать весь этот зоопарк

еще в SAE для MRT свои schedule

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

да вот бардака побольше будет

cahul-oancea acus o sa cada .. asta SRS .. nu bagati in registru .. doar sa fie max 1.2min (daca ceva Cazacov na svyazi 512, 591)

ups sorry

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

рактейблс и обратно уже утомило.

:)

что там в racktables такого осталось?

только связи меджу оборудованием. все остальное, IPAM и Vlan уже переехали в нок

можешь сравнить то, что переехало?

в смысле сравнить?

по использовании там и в ноке?

да

просто интересно сравнить пересекающийся функционал

на данный момент в рактейблсе самое ценное, для меня, это Rackspace. визуально видно какое оборудование где установленно, в какой стойке и на каком месте. Плюс визуально видно что и в какой порт оборудования включено. Все остальное, ipv4 и vlan, мне использо

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

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

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

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

и если бы я не заметил однажды нок, этот бардак и продолжался бы

racktables - тоже российский, если мне память не изменяет

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

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

мы раньше в NOC'овском KB рисовали

прямо XML'ем

все лучше, чем ничего

кстати, а какие функции возлогаются на КВ ?

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

так их и не вынимают.

но замену коммутатора на узле я отслеживаю сразу. по изменению его серийного номера

а то что его на 2U ниже прикрутили - тоже отслеживаешь?

Skripnik: просто wiki

буду знать. подумаю как его использовать в своих целях

<zi_rus>, а ето идея. прикрутить какой нить датчик. тогда по трапам можно будет отследить.

датчик называется служба эксплуатации ДЦ

:)

в каждый коммутатор по GPS

по фотоаппарату-мыльнице и по ведроиду

займитесь JS-мордой :)

сделаю зашибительную inventory

у нас как-то была идея линейный отдел снабдить GPS. и следить где они шарятся.

Skripnik, и каждому цак одеть

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

у нас и так камер по городу хватает :)

dvolodin, а можешь объяснить вот это из дефолтного конфига дискавери{{ IP|join:"-" }}

Как постгрю с ноковского дампа востановить?

создать юзара нок, базу нок, потом:

а, не надо, уже понял

pg_restore

psql noc < noc-db-2012-07-26-15-46.dump

pg_restore -d noc < noc-db-2012-07-26-15-46.dump

это с под юзера noc выполнить?

да

dvolodin, слушай, а почему ротация логов для noc-web не работает? он у меня уже 445М занимает

у него ее и нет

логи пишет tornado

dvolodin, а где может быть затык - скрипт отрабатывает из sa-mo-scripts и из debug_script, а в noc-discovery.log - ошибка "feature is not supported on this platform"?

железка одна и та же ессно.

получает версию софта

т.е.?

у меня в скрипте тоже есть проверка через get_version - и оно ее проходит

дискавери то тут причем

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

:)

inv/models/interfaceclassificationrule.py

:)

от такого и сон потерять можно

dvolodin, объясни всеж, что там такое проверяет дискавери, чего не делает сам нок при запуске скрипта из sa-mo-scripts?

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

да вроде ничего не проверяет

хм. ну вот странно же - из дебага работает, из веб морды - работает, а дискавери говорит - not supportes

d*

сообщение как выглядит?

2012-07-26 13:07:26,219 [bolsheoxt-16-1-es3526-1-1.line-r.ru] get_interfaces failed: {'text': u'Feature is not supported on this platform', 'code': 21}

вот блин дилема.

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

кеширование рулит

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

кэшируется же только результат скрипта

я вот все не могу решить для себя, что лучше)

проще конечно дергать уже имеющееся, да и унификация получается хорошая

но блин..

в том же get_interface_status = есть только state, а не admin/oper_state

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

пока можно забивать

а потом руки не дойдут да)

короче упрощу пока, поиграюсь с массивами

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

может и для хуавея напишешь?:

:)

там уже по идее почти все есть

дай хоть этот довести. я уже третий раз переписываю)

а как там правильно условие записать- "если слово существует в подстроке p - то"

if "слово" in p:

или

if "слово" in p[<start>:<end>]:

ага, нашел, спасибо.

а изменить приоритет alarm-а например Network | PIM | Neighbor Down

точнее severity

через alarm trigger

сейчас эти настройки в interface profile выносятся

правильно VLAN X, или без пробела\?

а то в имеющемся профиле ES без пробела сейчас.

имя интерфейса имеется ввиду

от системы зависит

на железке пробел

ну добавь пробел

ух, чую попути все скрипты ковырять придется)

а есть пример какой-то работы с этими триггерами?

например что значит template

и обязателен ли pyrule

pyrule не обязателен

и второй вопрос - когда нужно запускать ./noc sync-collections и что от делает

при изменении JSON в */collections/*

оно вливает их в базу

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

или он мне в итоге вернуло все как было

"оно"

built-in правила менять не надо

затрет

так как правильно добавлять - вебом,рестарт и все?

да, классификатор

с messaging я тоже более-менее разобрался

сделаю STOMP

dvolodin, я верно понимаю что у любого порта будет subinterfaces?

если он настроен хоть как-то, то да

обычно он один

который тем более switchport

у switchport'а он строго один

то будет is_bridge

да

ок, счас зобабазаем.

с tagged_vlans и untagged_vlan

у акцессного порта только utagged

хотя..

вот опять нюанс

в ES есть понятие - hybrid port

т е почти trunk

но с untagged

в хуавее тоже

+ есть MVR, который тоже untagged добавляет вилан

т е вполне может быть на акцессном порту несколько untagged виланов

а в формате get_interfaces вроде только один вилан отдаваться должен

или можно несколько untagged?)

'untagged_vlan': 1}],

привет!

можно одновременно выставить untagged и tagged

вот насчет MVR я не делал пока в IGetInterfaces

подумать надо

на тех же alcatel'ах может быть несколько мультикастных vlan'ов

hybrid port есть и в хуавее

для него нейтив влан такой-то

хьюбрид не проблема

несколько untagged vlan проблема.

в общем то что у некоторых называется mvr

может добавить список

mvr_vlans ?

а не проще ли их заигнорить

они же на аксесных портах обычно делаются

ну..вопрос тогда не только в get_interfaces, но и в get_switchport.

если отдельное поле добавлять - то нужно и туда и туда

как в принципе в get_interface_status нужно поле status разделить на два - admin/oper_status

тогда get_interfaces максимально упростится

можно, конечно, добавить два поля

вместо одного

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

mvr это же функция

которая "склеивает" два влана

или я не прав?

MVR виланы на разных портах могут быть разными

другое дело что на свитчинг юникаст трафика это не влияет

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

пока нету - можно игнорировать

_4ePTeHok: да, я тоже щитаю что в get_switchport & get_interfaces untagget должны быть списком! Надо поменять интерфейсы и поправить скрипты.

Пример, по одному влану инет, по другому малтикаст TV

ну это только в случае mvr

о нем мы и говорили

что может стоит его отдельно вытащить

но пока не ясно для чего)

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

епта..нарожают же

ладно, давайте по очереди

IGetInterfaceStatus

поле status заменить на два поля admin_status и oper_status

надо будет 16 скриптов минимум поправить

напиша скрипт который правит скрипты

гг

их на железе проверять надо

аля admin_status = status?)

oper_status = status

или оставить status без изменений и сделать необязательный admin_status

давай IGetInterfaceStatus оставим

я за необязательный

можно будет постепенно переделать скрипты

и то что уже работает - будет работать

Admin status надо только в get_interfacesб вот в нём можно с ним и заморачиватся.

Guest17-ru, смотри - мы дергаем get_status для state и затем ту же команду, которая в ней обрабатывается - для admin_state

зачем два раза один вывод парсить?

два вызова cli, нагрузка на железо, время..

Кроме того show interface наверно везде показывает админ статус, так что вытянуть ещё одну переменную регекспом совсем не сложно.

_4ePTeHok, не сношали бы мозги, по снмп 2 оид дернул и вот ответ

cli - зло

нюню. скажи это длинковцам.

там те же оиды

они стандартные

Ну тогда в get_interfaces можно сторонних скриптов не дёргать ;) А всё определять там..

оиды - да, реакция железа - непредсказуема.

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

IF-MIB::ifAdminStatus.1 = INTEGER: up(1)

IF-MIB::ifOperStatus.1 = INTEGER: down(2)

где там Dmitry1? Он расскажет про зависания длинков от snmp запросов.)

у меня ничего не виснет

в сети куча длинков

елки, ну вот ведь не суть

50% самописных скриптов шарятся по снмп

1. виснут порты при попытке опроса их состояния cable_diag

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

и ведь не виснут

есть метод cli, для него уже есть скрипты.

глупо их не использовать

по пути добавляя snmp, если хочется.

по снмп оно и работает быстрее

А вот с untagged вланами, надо менять интерфейс и всё. Untagged должен быть списком.

2. загрузка CPU поднимается под 100% при попытке выгрести по SNMP таблицу FDB >= 2000 MAC адресов

и нагружонные порты моргают.

я дергал тблицу маршрутизации на 4к маршрутов, без проблем, загрузка 30%

zi_rus: Возьми D-Link DGS-3627G и попроьуй у него через SNMP получить около 2000 MAC адресов.

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

Dmitry1, у меня есть DGS-3627G, и 4к маршрутов по снмп - это про него

не маршрутов, а MAC адресов.

у меня нет таких л2 сегментов

Мы используем DHS-36xx серию как аггрегацию. Т.е. там L2 превращается в L3

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

ок

состояние порта для d-Link

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

для DES-3526 - .1.3.6.1.4.1.171.11.64.1.2.4.1.1.4

Для DES-3026 - .1.3.6.1.4.1.171.11." . $p_oid[$ModelType] . ".2.2.1.1.4

и для остальных

и в cli есть различия

где $p_oid[$ModelType] - серия и модель свича. берутся из файликов типа SW3200PRIMGMT-MIB.mib

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

1.3.6.1.4.1.171.11.63.1.1.2.2.1.1.4 DES3010F-L2MGMT-MIB::swL2PortInfoLinkStatus

zi_rus: ошибаешься

вот для примера тебе - ScreenOS

1.3.6.1.4.1.171.11.63.4.2.2.1.1.4 DES3010FL-L2MGMT-MIB::swL2PortInfoLinkStatus

те же ifInOctets для сабинтерфейсов - в своих MIB'ах

1.3.6.1.4.1.171.11.63.1.2.2.2.1.1.4 DES3010g-L2MGMT-MIB::swL2PortInfoLinkStatus

Дальше продолжать? И это только 3 свича одной серии

dvolodin, не понял, что ты хотел сказать

я про то, что MIB'ы описывают только формат данных

наличие MIB'а абсолютно не гарантирует, что производитель будет отдавать эти значения на GET

ScreenOS - -как пример

Dmitry1, 1.3.6.1.2.1.2.2.1.7 - IF-MIB::ifAdminStatus - покажи где этого нет

вроде как в IF-MIB'ах что-то отдает, но не все

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

в прямом

eth0 есть, eth0.1 нет

через одну? рандомом?

или определенные вещи просто не предусмотрены

?

и такое бывает, да

Тот же D-Link при стекировании умудряется выдавать в качестве номеров портов вообще феерические вещи.

Причем в CLI это нормально видно, типа 1:1, 2:1 и т.п.

а в SNMP почему-то у первого свича в стеке номера портов с 1-го по 52 (или 60, я не помню), а у второго - после 60 начинаются

А порты больше 1000- туда вообще попадают интерфейсы управления, Voice Vlan и т.п.

захламили канал своими мибами.

Dmitry1, и у них тоже есть свои статусы

да

вот и именно

они есть и их надо отдавать

Dmitry1: это не номера, а ifNumber

dvolodin, почему для циски нет скрипта get_interface_status, а для длинка есть?

на выходных сделаю для циски

zi_rus: ну ты же его не сделал

:)

Я все жду, когда dvolodin победит длигкоаский CLI

dvolodin, да вот я смотрю, на длинковский и думаю, а на кой там делается cable_diag ports

Это я так делал. По другому через CLI невозможно узнать статус порта.

Потому как команда "show ports" использует curses-based CLI

а нок все дивайсы пингает?

или только те которые is_managed=true

acid232, те у кого trap source_ip прописан

или те которые в vrf default

у меня всех пингует, независимо от врф

а причем тогда trap source_ip

а у меня не все пингуе почему-то

и чем отличаются те что пингуются от тех что нет?

вот я и думаю в чем тут дело, в vrf != global, is_managed!=true или чем-то еще

vrf, adm domain

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

ну вот я и балуюсь

может еще в селекторах дело

непонятно короче говоря

dvolodin, так и не починил про лупбеки и ипам