nocproject.org

XenPak трансиверы делали?

а то у меня в утюгах они стоят =)

SX800 с трансиверами теперь

mikevlz, я цисковский делал один

mikevlz: наделай базовых

модельки-то простые

ну да...

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

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

mikevlz: ты посмотри, как сейчас у cisco и у juniper

там уши TRANS_MAP

это обновляться надо...

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

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

логика та же

только умнее стала

скипт может вернуть примерно следующее -- тут 10GBase-LR какой-то

то-есть один хрен мапить надо

noc-discovery сам определит по дырке, что это за нечисть

и есть еще вариант из скрипта сказать -- здесь у меня какой-то трансивер

и он по дырке вставит соотвествующий тип Unknown

у меня есть 10G-ZR, 10G-LR, может найтись 10G-ER какой-нить из XenPak. А если брать свежее - 1G M-LX(SFP) или какие-нить 10GE LR 10km (SFP +), 10G XG-ER(SFP+). А Part# у них вообще чудным может быть... Но полезным.

балин, только дочитал - и володин ушел)

быстрей читать надо

dvolodin, ты как раз вовремя, NOC-1228 - посмотри модельку для PSU в конце

dvolodin, погляди плиз http://pastebin.com/fGKRx5Ci Там типы для 6500, иначе все в чассисы пихает.

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

я первый :)

итак первый

ты перепутал

lug -- это ушко с двумя дырками

тебе terminal нужен

:)

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

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

dvolodin, то есть эти штырьки с резьбой куда гайкой крепится провод, это terminal?

и контакты там называются RTN и -48V

да

ok

у меня еще есть соображение глобального характера

что если нам в JSON вводить поле UUID

с уникальным идентификатором модели

зачем?

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

а как он формируется?

uuid?

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

да

если делаешь save из морды и его нет -- дописывает

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

сначала их прописать

дождаться, пока они у всех упадут в базу

а потом можно будет смело менять 6500 на 7600 и наоборот

там выше про 6500 как раз

я видел

lexus-omsk, а у тебя get_inventory дефолтный?

с другой стороны -- RSP720-3C/3CXL под 7600 шасси

а для чего на модельках карт разъем DFC?

_4ePTeHok: уже да, я не стал после обновления снова патчить, пока не договоримся по всяким dfc/cfc

оно же на супе вроде как

исправил луги на терминалы

ага и счетчик

и история замен)

и 1С склад

lexus-omsk у тебя суп2 случаем н а 6500 нед?

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

не ну круто будет. нафига эти все извраты если это дубляж вывода рункоманд с show enviroment

show inventory

_4ePTeHok: не, у меня только 720'е - 3b и 10G модели

эх.

старье конечно, но блин работает)

lexus-omsk, ты не знаешь чем 3b отличается от 3CXL?

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

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

учитывая что решили забить на пфц...)

а следовательно и производительностью, и ценой

NAME: "module 5", DESCR: "RSP720-3CXL-GE 2 ports Route Switch Processor 720 Rev. 5.12"

PID: RSP720-3CXL-GE , VID: V13, SN: SAL1530KM72

NAME: "msfc sub-module of 5", DESCR: "7600-MSFC4 C7600 MSFC4 Daughterboard Rev. 1.6"

PID: 7600-MSFC4 , VID: 000, SN: SAL1530KRZP

NAME: "switching engine sub-module of 5", DESCR: "7600-PFC3CXL Policy Feature Card 3 Rev. 1.1"

PID: 7600-PFC3CXL , VID: 000, SN: SAL1529KDXL

вот так она у меня выглядит

а, ты про rsp... это же не то же самое, что и sup720... хотя суть отличия, думаю, такая же

а забить решили, потому что с другим pfc будет другой pid... по крайней мере про sup720 я именно так понял

lexus-omsk, а ты для CLK правил скрипт?

!! UNKNOWN: {'serial': 'NWG15170KQS', 'pid': 'CLK-7600', 'name': 'CLK-7600 1', 'vid': '', 'descr': 'OSR-7600 Clock FRU 1'}

не ловит он его

правил... там кстати и серийники определяются одинаковыми

серийники да

но смотри, скрипт не смог отработать

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

вон выше дифф для 6500

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

ну как скажете

e_zombie: то есть ты хочешь по part no видеть список managed object'ов, где оно присутсвует?

просто коллонка со ссылками на них.

сам понимаешь что надо будет найти где эта сфпи стоит?

это классика

бухии

тогда ты не того хочешь

бухам нужна модель, серийник, и объект установки

объект - в плане буховском

первые две у тебя в отчёте есть - а вот третьего нет.

вот это добавить и всё будетОК.

не боле того.

там еще потребуется по part_no и ревизии определить, где такое вообще стоит

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

я просто не смотрел структуру бд и не знаю.

e_zombie: объект найти легко

ну вот вывести в колонку название обьекта и всё

надо сначала мо по объектам раскидать

тогда бухи будут визжать от восторга

ну на бухов пока похер. всё равно эта CSV будет парситься отдельным скриптом. или на прямую из бд дёргаться.

dvolodin, про серверников это ты верно заметил...

тут вопрос, вот скажем шасси можно дергать с ipmi, а набивку уже из OS придется.

dmidecode например

ну и lspci всякие для полного щястья

как это совмещать

профиля то сейчас по OS

_4ePTeHok, пилите скрипт это называется

два профиля - типа ipmi+linux не выставишь

да еще и ipmi разный у платформ

_4ePTeHok, они у тебя все равно с разными ip

и вендоров

два МО получается

дык менеджмент object должен быть один

для ipmi

и для OS

по логике то

ось же не в воздухе висит

_4ePTeHok, самое разумное это научиться дергать инфу о шаське из операционки

хмы.)

да оно вроде дергается так-то

System Information

Manufacturer: HP

Product Name: ProLiant SL390s G7

Version: Not Specified

Serial Number: CZ320475BV

к примеру

возрадуйся, ipmi не нужен

почему никто Windows профиль еще никто не запилил?

гг

издеваешься?)

отнюдь

приветствую

RRAS там есть

маршрутизировать умеет

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

dhcp, dns

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

включить дебаг в настройках

[main]

logfile = /var/noc/log/noc-stomp.log

loglevel = info

logsize = 10240000

logfiles = 9

syslog_host =

pidfile = /var/noc/log/run/noc-stomp.pid

heartbeat= false

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

loglevel = debug

и вперёд

проще можно

./scripts/noc-stomp.py -f start

stomp(14:46:36) zi_rus: e_zombie, main setup stomp access и в конфиге должно совпадать как у активатора (14:47:05) zi_rus: в смысле не пароль как у активатора, а смысл такой же

оке, прсто кониг не менялся, работал а тут перестал

Type: DDR3

Speed: 1333 MHz

Manufacturer: Not Specified

Serial Number: Not Specified

Asset Tag: Not Specified

Part Number: Not Specified

гг

noname

dvolodin, провидец)

типичная история

Самое интересное вроде там реально не нонейм

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

_4ePTeHok, у меня тоже sfp оригинальные, якобы

а какой командой ты это смотришь, я свои сервера оценю

dmidecode -q в линуксе

но оно карты не показывает, это lspci надо

а оно по дефолту скажем в центоси не стоит()

в фряшке pciconf -lv есть

а в виртуалке это будет ваще фигня

в виртуалке ipmi надо дергать

шассей

фряшка на реалке стоит

IPMI явно надо делать, но я в нем полный лошара

импи очень разный, Дим.

подозреваю, что все это можно выдрать и из LOM/iLO

у меня в нем видно только модель и серийник шасси

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

вот с этим разбираться надо

но вот оценить где чего стоит - нет

сервачникам inventory еще нужнее, чем сетевикам

угу..

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

я бы активно позанимался этой частью

особенно если блядскими серверами балются

гг, кластер считается блядскими?)

собственно чо я спрашиваю)

если на блейдах - да

:)

оно что так что так

у нас куча ведер CPU/GPU блейдов

веселуха та еще

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

типа nvidia-smi

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

как бы не пришлось писать костыль - скрипт, агент. Типа как заббикс делает

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

хоть какая-то унификация

заббиксовый агент умеет это делать?

ну я про структуру в принципе

тут засады есть

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

агента сишного придется делать

причем и под винды

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

нахер винду

да можно и стомпом

как у нас с днс уже

мне кажется проще

сделать какой-нибудь STOMP/RPC

угу, как метод доступа на железку

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

ну а там уже обработчики

заббиксовый ангент отдаст нам набивку?

или он только сенсоры отдает?

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

нихрена он не отдает)

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

ящик не отдает ограничения

это как смотреть

например -

Physical Memory Array

Location: System Board Or Motherboard

Use: System Memory

Error Correction Type: Single-bit ECC

Maximum Capacity: 192 GB

Number Of Devices: 6

понятно, что не на все.

и всё же

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

а ты попробуй разными тулзами

dvolodin, дергать надо по возможности стандартными средствами ос

иначе как доп-софт туда ставить

геморой...

вот моя пируля http://pastebin.com/2ERrS1me, вот мой дифф до применения пирули, от которого я хочу избавиться: http://pastebin.com/cuKBGmr6 и вот то, что теперь приходит: http://pastebin.com/4UcQPzeC

ЧЯДНТ?

_4ePTeHok: подозреваю, что часть инфы можно снять с pci

Unbeerable: подозреваю, что это означает, что изменений нет

dvolodin, то есть это нормально

в смысле, меня заебали письма о том, что у кого-то включился/выключился интернет :)

я думал побороть их диффом, но он теперь срёт о самом факте диффа

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

ветка какая?

default

hg branch сказал так

а

еще до GridVCS?

в GridVCS проверка стоит, если совпадают конфиги после фильтра - не будет diff писать

не запускается стомп и синк в логах ланчера 2013-11-21 12:47:35,342 Daemon noc-sync[#0] started as PID 18032

2013-11-21 12:47:36,344 Launching noc-stomp[#0]

2013-11-21 12:47:36,346 Daemon noc-stomp[#0] started as PID 18033

2013-11-21 12:47:36,346 noc-sync[#0] daemon is terminated with status 1

2013-11-21 12:47:37,348 noc-stomp[#0] daemon is terminated with status 1

changeset: 8495:d1c63b11304d

это до GridVCS или после?

судя по hg log, у меня уже после него

Это у тебя уже inventory

конфиг у тебя в managed object сейчас?

да

или нет?

в смысле, я не понял вопроса :)

denix3, делай -f start он больше инфы дает

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

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

вот так запускаю /opt/noc/scripts/noc-stomp.py -f start

нет

cd /opt/noc

./scripts/noc-stomp.py -f start

аа, понял

так вроде ошибок нет никаких

2013-11-21 13:47:13,402 [inv.discovery: asset_discovery(bgw2-sar)] Unknown part number for Juniper mx960: NoName | Transceiver | 1G | SFP T (SFP-T)

2013-11-21 13:47:13,403 [inv.discovery] Job asset_discovery(bgw2-sar) is completed successfully (2.089144sec)

e_zombie, и что тебя смущает? садишься и рисуешь недостающую модель, а если не жадный то делишься

меня тут больше время работы настораивает

долго?

не знаю. у кого как с этим?

2013-11-21 13:53:56,113 [inv.discovery] Job asset_discovery(7600-1) is completed successfully (0.300546sec)

но он на железку не ходит

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

dvolodin: эта... у миня вапрос у уважаемым знатокам. А почему в железке, в ее инвентори, дескрипшен берется от модели, а не отнайденного куска железки?

поясняю суть. SX800 у меня возвращает в качестве part_no фактически фигню для трансиверов. Но он еще снимает и в дескрипшене пишет Part# снятый с железки.

просто, чтобы не плодить модели разных SFP, например, я для SFP отличаю просто их по дальности и отдаю NoName SFP. А в дескрипшене пишу, что это LX, а тут DEM-330T, в это вообще SFP-CWDM-51. В железке же открываешь инвентори, а там в порту трансивер, да... но дескрипшен у не

го NoName | Tranceiver | SFP-LX. И нафига скриптом дескрипшен отдавать?

mikevlz: в куске железка любая чушь может быть в description

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

mikevlz: не стоит так делать

как-то неубедительно

на самом деле если это SFP-CWDM-51, то и description у него должен быть соответсвующий

да, может быть херня

и part_no

а так зоопарк будет

зато моделей мало

чем тебя модели смущают?

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

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

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

если очень сильно захотеть, то можно и из виндового registry сделать inventory

у меня тут просто в железке стоит и Cisco-Finisar и китайцы безымянные, и китайцы именитые

правда - паршивый

и на каждый чих модель?

под NoName они пойдут

чем тебя модели смущают?

mikevlz, число моделей вполне ограничено фантазией производителя

тем, что их нет =)

нет

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

именно

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

ну почему?

партнамбер не серийник

он четко определяет конкретную продукцию

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

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

ладно, ща погрепаю свой SX на предмет Part#

разных

mikevlz, если получается что sfp например ничем не отличаются кроме part_no0 то вполне нормально просто в соответсвующей модели прописать этот part_no1

вполне себе оптимизация числа моделей

епта...

mikevlz: их даже грепать не надо

inventory > unknown part numbers

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

не, тут эта... Я их все как ноунейм отдаю

./noc beef --view <file or UUID>

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

mikevlz, ты норкоман, почему не хочешь нормальный парнамбер отдавать, который железка видит

http://pastebin.com/CwHYGjcb вот

не причесывал, как есть. Причем там есть дескрипшены плат, а есть part_no трансиверов

да, я норкоман, я неоднократно это говорил

и это я еще многообразия вендоров не касался :)

ну и среди 1Г там вроде нет ни одного двухглазого, кроме CWDM, который там есть, но прикидывается сусликом

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

> statistics enet

port status mode duplex up time

----- --------- ---------------- ----------- --------------

enet1 link up 1000fiber full duplex 00221:17:06:07

enet2 link down - - -

причем какой из них - не указано?

вообще ничего не указано

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

unknown тогда

пусть по дырке попадает

и нам еще надо придумать обозначения для протоколов для портов DSLAM

:)

так.... чота у меня херню рисует...

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

dvolodin, по диффу циско.иос.инвентори чего скажешь?) Там через одно место конечно, но рисовал, чтобы не сломать уже работающее.

клево... Дернул один объект: два модуля управления, две платы 10Г. Отрисовало норм. Дернул второй объект - одна плата управления, три портовых платы - в инвентори содержимое первого объекта. Как?

кажись понял...

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

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

zi_rus: все у него получилось идеально

в логе нужные модули. А на картинке - от предыдущего шасси

хы, одинаковые серийники на шасси?

нет возможности снять серийник - везде отдаю None

придется смотреть мак шасси, вроде есть такой

HW: BigIron 4000 Router, SYSIF version 21, Serial #: Non-exist

вот так вот

Boot Prom MAC: 000c.dbb6.1900 вот это у шасси разное

буду его как серийник шасси пихать

Сделал логи у объектов

счас затестим

а где смотретьь?

привет! Коллеги, кто в цисках рубит - слезно прошу о помощи! :)

у меня головной маршрутизатор чудит

циски рубить не стоит

уже третий раз на неделе ребутнулся :(((

топортом

что логи говорят?

подскажите, как и где крешдампы проаналищировать?

да логов то ни каких нет.

ребутается же она

в ноке в ивентах ни чего тоже нет

проанализировать ты не смогёшь. это только вендор

просто пинг down и усе

у тебя есть сислог сервер куда всё валится?

блин... то есть крешдамп бесполезен? :(((

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

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

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

e_zombie, зачем так то?

в логах ты увидишь краш

а архивировать и бакапить как ты будешь логи?

текстовые логи это тебе не бд монги

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

сколько у тебя в ноке логи хранятся?

ну максимум месяц два

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

ну в целом да. этим занимается циска через своих вендоров

исходняка иоса у тебя то нету.

ну мне достаточно и месяца :) я аварию сейчас увидел. и мне надо по горячим следам её разобрать. час назад роутер ребутался

а у меня логи лежат уже за год в архивах . и всё ок.

так что лишним не будет.

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

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

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

могу сказать только. что оба раза я перед ребутом делал команду clear.. первый раз clear ip nat translation. второй - clear ip dhcp binding

походу стоит обновлять иос до упора.

как мне товарищи подсказывают без отправки вендору хер ты что поймёшь

по трейсбеку.

в общем, вот такая история логов в нок у меня:

s247_3945 21.11.2013 15:45:56 Active NOC | Managed Object | Ping Failed Ping Failed

s247_3945 21.11.2013 15:43:55 Active NOC | Managed Object | Ping OK Ping OK

s247_3945 21.11.2013 15:43:50 Active Network | IP | Address Conflict Address conflict detected for 10.162.2.254 MAC: 8C:89:A5:2C:30:4D on Gi 0/0.162

s247_3945 21.11.2013 15:43:49 Active Unknown | SNMP Trap SNMP TRAP: 1.3.6.1.4.1.9.9.41.2(CISCO-SYSLOG-MIB::ciscoSyslogMIBNotificationPrefix)

s247_3945 21.11.2013 15:43:19 Active Network | IP | Address Conflict Address conflict detected for 10.162.2.254 MAC: 8C:89:A5:2C:30:4D on Gi 0/0.162

s247_3945 21.11.2013 15:43:18 Active Unknown | SNMP Trap SNMP TRAP: 1.3.6.1.4.1.9.9.41.2(CISCO-SYSLOG-MIB::ciscoSyslogMIBNotificationPrefix)

s247_3945 21.11.2013 15:42:47 Active Network | IP | Address Conflict Address conflict detected for 10.162.2.254 MAC: 8C:89:A5:2C:30:4D on Gi 0/0.162

s247_3945 21.11.2013 15:42:46 Active Unknown | SNMP Trap SNMP TRAP: 1.3.6.1.4.1.9.9.41.2(CISCO-SYSLOG-MIB::ciscoSyslogMIBNotificationPrefix)

s247_3945 21.11.2013 15:42:20 Active Unknown | SNMP Trap SNMP TRAP: 1.3.6.1.4.1.9.9.43.2(CISCO-CONFIG-MAN-MIB::ciscoConfigManMIBNotificationPrefix)

хреновенько блин :(

ну спасибо хоть за эту подскащку

все нераспознанные SNMP относятся к дублицированию IP адреса

я как раз эту проблему и пытался решить..

а что решать. найти и отпиздить кто закольцевал

думаешь из за этого роутер ребутнулся? :))

нет. но хотябы душу отведёшь