nocproject.org

это как раз type для get_inventory

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

прописал трансиверы и chassis

Здорова! а не подскажете чего с обратными зонами в 0,8 - Обновился с 0,7(4) sync настроил

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

если выключить обратные - всё ок

с чем синхронизация?

с днс сервером

bind

dvolodin: обновил до develop таже ситуация

dvolodin: Дмитрий! я вчера скидывал проблему, по cdp линковка не проходит, а порой и log-job пустые. Это может быть из-за различия между gi 3/0/4 и gigabitethernet 3/0/4?

нет

имена интерфейсов нормализуются к одному виду

HaLVeR: просили типы в моделях - заполняйте

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

а что насчет днс - никто не сталкивался?

Kostua: нет, нужна более детальная диагностика

dvolodin: что более детально посмотреть?

куда смотреть?

вот почему log-job пустые - загадка

managed object'ы как называются?

по fqdn

причём все

у кого-то есть log-job, у кого-то нет

более того, дебаг скрипт по cdp выводит 5 нейборов, а в лог джобе только 1 предложение

что ты считаешь логом job'а?

ну, справа данные в МО при discovery + файлы в папке, которую указал в noc-discovery.cong

верно?

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

да

и там пустые файлы?

ага

а в логах noc-discovery при этом нормально пишется?

dvolodin: http://pastebin.com/dPuxuXjm включены все дискавери. 80% устройств это c3750x, логин на устройство есть, Pri 15, snmp RO есть.

афк, но приду и прочитаю/сделаю, что напишешь.

а

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

dvolodin: да? а дебаг-скрипт отрабатывает нормально и в МО статус отработанного Stop, а не Fail

кстати, объекты wiping-16 когда пропадут? удалил в MO железку, а она висит сутки уже.

dvolodin: дебаг скрипт get_cdp-nei выдаёт список соседей. а можно вызвать скрипт, который полностью за cdp_discovery отвечает?

у 1 свитча Link candidate found, Scheduling check for и ничего не происходит.

с другой стороны проверь

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

zi_home: понял. Юзабилити!

dvolodin: с другой стороны пустой файл/лог. скрипт get_cdp_neibors работает.

ах, вышле

buggy-funhouse, просто бага, сможешь починить все поблагодарят, нет то будешь со всеми

zi_home: бага? а я думал недофункционал. Чтобы починить, надо понимать кухню проиходящего внутри, все процесы и т.д. Я для начала попробую cdp покурить =)

кури кури

почему недо-

функционал нормальный

только не работает

Я хочу, чтобы было заебись от слова хорошо, а не от слова плохо

все хотят

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

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

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

не, я таких методов не знаю

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

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

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

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

get_chassis_id get_cdp_neighbors get_fqdn

yt levf. xnj ghj,ktvf d kjubrt

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

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

вероятнее всего недостаточно данных

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

Кмк, неверно определяется get_chassis_id. Правда, смотря что под этим понимать.

"last_chassis_mac": "64:9E:F3:33:67:80",

"first_chassis_mac": "64:9E:F3:33:67:80"

Хотя на самом деле по маку на интерфейс.

zi_home: как посмотреть в базе?

from noc.inv.models.discoveryid import DiscoveryID

n = DiscoveryID.objects.filter(hostname=device_id)

вместо device id подставляй хостнейм

zi_home: это в монге или в шелле?

шелл

NameError: name 'chem10g' is not defined

хотя объект называется chem10g.sw.pu.ru

buggy-funhouse, device id это fqdn из конфига

get_fqdn на этой железке что выдает то и вписывай

ха, его и пишу

или get_cdp_nei

вот в этом у тебя и проблема

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

но принял

buggy-funhouse, DiscoveryID.objects.filter(hostname='chem10g')

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

пусто

не попал сосед в базу

нок не знает на какой железке делать проверку

почему, если get_cdp_nei отрабатывает, как скрипт

djghjc hbnjhbxtcrbq

риторический вопрос

zi_home: а по шасси_ид, он должен 1 мак находить, или всё-таки каждого физ интерфейса?

buggy-funhouse, много разных нюансов, для get_fqdn есть снмп часть, может у тебя с снмп проблемы

могу вырубить снмп

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

buggy-funhouse, проще дебаг прогнать чтобы снмп заюзать, ты же наверное не делал этого еще

хм, нет, на снмп не грешил. Через дебаг-скрипт?

да

-с- rk.x

ключ

возьмет комьюнити из профиля

и прогонет снмп часть

./noc debug-script -c- rk.x get_fqdn chem10g.sw.pu.ru Верно?

да

нет

./noc debug-script -c- get_fqdn chem10g.sw.pu.ru

да, туплю. ключ==rk.x ..

zi_home: выдаёт то же самое, что и просто get_fqdn. Верный ответ

странно

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

buggy-funhouse, значит что-то не так

комьюнити в профиле прописан?

Да, trap ip sourse Тоько пуст

./noc debug-script -c- get_fqdn cat-77-1

2014-03-02 00:50:27,800 [Cisco.IOS.get_fqdn(cat-77-1, 192.168.81.65)] 192.168.81.65 SNMP GET 1.3.6.1.2.1.1.5.0

2014-03-02 00:50:27,816 [Cisco.IOS.get_fqdn(cat-77-1, 192.168.81.65)] 192.168.81.65 SNMP GET REPLY: 1.3.6.1.2.1.1.5.0 cat-77-1.kis.ru

угу, а я oid'ов не нашёл в вызове

buggy-funhouse, а ты auth profile используешь?

неа

пока только руками(

тогда даже не знаю

щас

должен снмп юзать

я попробую snmpwalk

бля

ud

*udp

теперь работает по snmp

теперь перезапущу дискавери

пиздец стыдно

на двух железках разом запускай

сначала id discovery

потом cdp

т.е. как только я указал snmp в профиле, он будет стараться его есть?

да

если в скрипте есть

но по ssh-то ходил.. Сейчас запущу

скрипт не достучался, по snmp, то кли юзать не будет

были мысли пару лет назад на эту тему

потом все забили

это неверно, думаю

формально должно быть достаточно одной схемы

снмп удобен

а кли универсален

некоторые снмп не любят

длинки от снмп дохнут иногда..

использую ip-mac binding, дёргаю по снмп, знаю

zi_home: если сделаю unlink, свзь пропадёт? пока все свитчи по lldp подцепились, не проверить

да

link found via cdp

zi_home: спасибо тебе большое

вопрос на полчаса

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

я тут с понедельника торчу с этим вопросом =)

если указал комьюнити зачит по снмп можно

а то что не получилось это косяк настройки

тут наверное ты прав

snmp приоритетнее

он шустрее

да, не поспоришь

1-10оид дернуть легче чем ssh cdzpm ecnfyfdkbdfnm

*связь устанавливать

перезапустил для всех дискавери

zi_home: get_chassis_id важный скрипт?

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

циска в своих приложениях для ios xr использует доступ через xml. по-моему интересная штука для нока

к сожалению, не видел Xr

шасси_ид это шасси_ид

по нему ищется сосед

в некоторых скриптах

а как ищется шасси? sh ver?

смотри в скрипт

скрипт вроде бы верный, у устройства есть Base Macc address в sh ver, но почему-то не парсится или ещё что не подходит. С утра посмотр.