About Forum Blogs NOC Docs Downloads KB Issues Code CI Registration

nocproject.org

#nocproject.org at irc.freenode.net log.
Back to nocproject.org Back to IRC log index
Date: 07.02.2013
freeseacher #
05:16
dvolodin, у нас вдруг появились железяки которые из состояния ping failed не выходят
05:17
но тем неменее отлично пингаются
dvolodin #
05:18
мого таких?
freeseacher #
05:19
уже 5
05:21
как их переопросить ? раньше рецепт был просто. запустить задание а тут пока не понимаю состояние что ли сбросить в базе ?
zi_rus #
05:24
freeseacher, проверь через tcpdump отправляются ли пинги в их сторону
05:24
tcpdump host 1.1.1.1
05:24
может у тебя версия старая
05:25
это у меня было но потом пофиксили
05:25
он переставал пинговать недоступные железки
05:26
dvolodin, NOC-906
dvolodin #
05:32
да, было такое
freeseacher #
05:34
как сейчас то состояние почистить
05:34
вроде обновился до последней
05:35
но за 10 минут в сторону проблемного свитча ниодного icmp не улетело.
zi_rus #
05:35
freeseacher, не надо состояние чистить, когда он начнет работать нормально все и будет в порядке
05:35
не шлет icmp - это проблема, ее надо решать
05:36
последняя |NOC|0.7(4)r7511| - точно работает, по крайней мере у меня
05:37
проверил, железка лежит 9 дней, запросы продолжают отправляться
freeseacher #
05:44
я лошаро. :)
05:44
трап сорс ойпи не проверил
dvolodin #
05:45
кстати я вот не уверен, по нему пинговать, или по address
zi_rus #
05:45
dvolodin, странный вопрос, тебе уже давно говорят
05:46
по ssh ты стучишься на адрес, а пингуешь трап сорс, логики ноль , гемороя выше крыши
dvolodin #
05:48
ага
05:48
мне больше интересно, какой бес меня там попутал Ж)
05:48
и зачем
freeseacher #
05:49
думаю долбанутая железяко :)
zi_rus #
05:49
что телнетится на интерфейс, но не пингуется?
05:50
мне кажется даже китай на такое не способен
Unbeerable #
06:07
freeseacher, забавно, у меня тоже есть пинг фэйлды до железок, которые пингуются, но нок не обновлялся уже сто лет
06:08
во, 21 ноября последняя запись в чейнджлоге
mikevlz|3 #
06:35
кстати да... насчет пинга трапсорса... госкомдурь задремала =)
dvolodin #
06:46
не иначе как ветры национального чемпиона голову закружили
06:47
единственная отмазка была - у некоторых fqdn в address вбит
06:47
резолвить не хотелось
zi_rus #
08:16
а noc умеет snmp get bulk?
misak #
08:41
здрасте
08:49
длинки все почти померли как и я их в нок завел :)
08:49
проц наверное слабенький
evyscr #
08:59
zi_rus: dvolodin говорил, что умеет
dvolodin #
08:59
кто умеет?
evyscr #
09:00
noc
mikevlz|3 #
09:00
misak: что-то неправильно сделал :) у меня живут и не жалуются
dvolodin #
09:00
bulk?
09:00
умеет
Dmitry1 #
09:00
dvolodin: Напиши доку, как коммитить тушенку, а в scripts выложи скрипт конвертации старой тешкнуи в новую
dvolodin #
09:01
Dmitry1: test я доделал
Dmitry1 #
09:01
я видел
09:01
как коммитить?
dvolodin #
09:01
теперь можно и репо целиком тестить, и отдельный скрипт и отдельную тушенку по GUID
misak #
09:01
mikevlz|3: у меня пинги выросли до небес и еле шевелятся
09:01
3200 серия 10и портовый
dvolodin #
09:01
я предлагаю через pull request на bitbucket?
09:02
или удобнее будет все-таки team сделать?
Dmitry1 #
09:02
Здесь об этом ничего не сказано: http://kb.nocproject.org/display/DOC/Commiters+Tutorial
dvolodin #
09:02
Дим, я еще думаю, как нам удобнее будет
Dmitry1 #
09:03
У меня уже несколько десятков файлов тушенки есть, заодно и изменения в SA скриптах.
mikevlz|3 #
09:03
у меня таких нет. Есть 3028, 3200-28, 3200-18. 3100, 3612, 3627. живут, падлы...
dvolodin #
09:03
есть еще вариант - у девелоперов свои репо с тушенкой
mikevlz|3 #
09:04
а еще есть нортелы 470-е вроде, 3комы 4226г... Вот эти не сую, хотя автодискавери скорее всего их всех нашла и сочла за длинки =)
dvolodin #
09:04
и по мере переработки она отправляется в sa_public
Dmitry1 #
09:04
А кто будет следить за этим? Или у нас появился человек на 8-ми часовый рабочий день?
mikevlz|3 #
09:04
надо дискаверилку переделать, чтоб сначала snmp снимала, по нему профиль переделывала...
dvolodin #
09:05
да, с тушенкой
09:05
теперь можно снимать ее с флагом --private
09:05
я буду класть ее в отдельный репо sa_private
09:06
их можно не чистить
ufir #
09:15
как поменять get_interfaces.py ? инвентори не видит интерфейсы, если в дескрипшне есть запятая - как её "выкувярять"
dvolodin #
09:18
это для какой железки?
ufir #
09:18
для хуавеев. моих любимых ;(
09:19
я тестил - дело именно в запятой. а в дескрипшне по умолчанию их две
09:19
с питонами незнаком
dvolodin #
09:20
заготовь модную приватную тушенку
09:21
да, ты прав
ufir #
09:21
а как новую делать ? ;) я знаю только ./noc debug script A.B.script -o out
dvolodin #
09:21
r"(?:Description\s*:\s*(?P<desc>[^\n,]+)(?:, (?:Switch|Router) Port)?\n)?"
09:21
./noc debug-script ….. -o /tmp --private
09:22
действительно, оно считает, что запятых там быть не должно
ufir #
09:24
отправил на beef@
dvolodin #
09:31
написал, какой там интерфейс не видно было?
ufir #
09:32
нет.. щас напишу
09:34
написал ;)
09:34
а невидно все интерфейсы, если "из коробки"
dvolodin #
09:49
ufir: гляну
ufir #
09:50
ага, спасибо
misak #
10:00
mikevlz|3: а у тебя все дискавери включены ?
mikevlz|3 #
10:00
да
10:00
ну почти... udld, bfd поотключал, стп тоже вроде
zi_rus #
10:02
Dmitry1, смотрю ты сислогами занялся
Dmitry1 #
10:02
ага
10:02
немного
zi_rus #
10:03
смотри, сможешь сделать NOC-869 как повышающий приоритет для NOC-868?
Dmitry1 #
10:03
надолго меня не хватило. работы подвалило
10:03
напиши комментарий к issue, а я потом сделаю
zi_rus #
10:19
Dmitry1, почему ты не придерживаешься при классификации ивентов уровней которые определил производитель, severity есть в каждом syslog-message
Dmitry1 #
10:21
Как пример - на D-Link возможно на разных моделях разный уровент severity для одного и того же события
dvolodin #
10:21
игнорировать это
zi_rus #
10:30
существуют более ответственные производители, не вижу причин не верить уровням, кторые сообщает циска
Dmitry1 #
10:33
у нас поддержка более сорока вендоров. циска тут явно н езаконодатель моды
zi_rus #
10:45
отнюдь
10:45
посмотри на результаты опроса
10:46
только вычеркни длинк, потому что он явно тут не авторитет
dvolodin #
11:25
да что нам до моды
11:25
мы же поддерживаем всякие PVST, REP и прочие CDP :)
11:26
кстати для интерфейсов - иерархия forwarding instance -> interface -> subinterface слизана с JUNOS :)
_4ePTeHok #
11:27
угу, заметил сразу
11:27
по тушенке распиши, и для девелоперов надо будет доступ к приватной тушенке сделать
11:28
вообще - может автоматизировать сбор тушенки?
dvolodin #
11:28
регистрируйтесь на bitbucket
11:28
я его вообще сильно автоматизировал
_4ePTeHok #
11:28
а то руками ее мало кто шлет
dvolodin #
11:28
./noc beef рулит
11:28
:)
11:28
а так - хочу вообще на уровне sae-активатор сбор сделать
_4ePTeHok #
11:29
я к тому - что может сделать функцию, чтобы при обнаружении неведомой платформы оно само сдергивало
11:29
но это попахивает фродом)
11:29
реально высылают тушенку еденицы
11:30
и в том головняк, при переписывании скриптов потом
misak #
11:47
кстати
11:48
я тушенку должен выслать
11:48
у меня от циски трейсбек валится
11:48
какой сейчас правильный механизм актуален ?
12:01
Error: Can write canned beef for one object only
_4ePTeHok #
12:05
гг
misak #
12:07
по имени объекта вроде фурычит
_4ePTeHok #
12:08
dvolodin, Дим, вопрос есть со вчера еще. Как быть с ситуацией, когда get_interfaces с одной модели длинка отдает нормализованный интерфейс вида Gi 0/1, а get_lldp_nei с ежика включенного в этот длинк отдает remote port id - GigabitEthernet
12:09
понятно что нужно нормализовать имя, но мы же в профиле другой железки это выдергиваем
12:09
может сделать фичу, чтобы по remote_chassis_id профивался в инвентори профиль МО и применялась функция нормализации имени ифейсов?
12:10
изнайденного профиля
12:10
пробивался конечно
dvolodin #
12:17
remote_object.profile.convert_interface_name
_4ePTeHok #
12:20
эм. а как он узнает какой именно ремоут обджект из скрипта?)
mikevlz|3 #
12:24
дискавери когда дергает LLDP сам находит remote object по базе идентификаторов
_4ePTeHok #
12:25
о, счас проверим
mikevlz|3 #
12:25
там вроде даже это закодено, надо только в профиле ежика нормализатор прописать
_4ePTeHok #
12:25
у ежика все нормализовано
mikevlz|3 #
12:26
тогда должно дискаверить ллдп нормально
ufir #
12:27
на ежах все отлично дискаверит
_4ePTeHok #
12:30
это длинк отдает в выводе на ежик
12:31
ненормализованное имя
zi_rus #
12:32
а другие что отдают?
12:32
не повлияет ли это на связи с другими вендорами
_4ePTeHok #
12:32
ежики отдают то же что и в кли
12:33
дык о том и речь - чтобы снятое в гет_ллдп имена были нормальзованы так же как как в собственных профилях железок
12:33
к единому знаменателю свести
ufir #
12:33
_4ePTeHok они же sysname отдают ?
12:34
я в какой-то версии их софта видел в cli везде Vty# - а сиснейм был нормальный
_4ePTeHok #
12:35
ежик в выводе ллдп с порта кажет не мак интерфейса а сам интерфейс в виде, несовпадающем с тем, что у длинка хранится в инвентори
12:35
=)
12:35
короче раз есть функция - попробуем с ней
`kk #
12:37
_4ePTeHok, модель делика?
_4ePTeHok #
12:38
3610-26G. тогда Port ID : GigabitEthernet 0/1
`kk #
12:38
циско кли лайк?
12:39
видимо да.
_4ePTeHok #
12:39
э..хз, не моя тема, ApmeM -a
12:40
а что, от вида кли меняется то, что длинк отдает другому свитчу в ллдп?)
`kk #
12:40
хех
ApmeM #
12:40
профиль DxS_Cisco_CLI. модель 3610-26G
`kk #
12:40
_4ePTeHok, инт-ы же подругому называются
ApmeM #
12:40
уже есть мысль переделать все интерфейсы под те имена, которые выдаются в CLI
mikevlz|3 #
12:41
кто-то что-то не догоняет, а в инете как всегда кто-то неправ
`kk #
12:41
ApmeM, в кли он gi0/1 ?
mikevlz|3 #
12:42
дался вам этот get_lldp_neighbors?
`kk #
12:42
мне вот нужен)
ApmeM #
12:42
нет. GigabitEthernet 0/1
mikevlz|3 #
12:42
он используется дискаверилкой. пусть отдает как получается. Задача сводится к тому, чтоб дискавери нашел линк
`kk #
12:42
не суть. не такой как везде
ApmeM #
12:43
у меня, например, нет других вариантов снять топологию. только lldp
`kk #
12:43
нужен костыль для DxS_Cisco_CLI =)
mikevlz|3 #
12:43
отсюда вывод. Дискаверилка видит, кто там сосед у этого длинка, видит, что это ежик. при обработке вывода она вызовет конвертор из профиля ежика
_4ePTeHok #
12:44
вы все перепутали
`kk #
12:44
ага
_4ePTeHok #
12:44
снимаем инфу с ежика по гет_ллдп
mikevlz|3 #
12:44
хорошо
_4ePTeHok #
12:44
в его выводе видим что сосед по порту - длинк
mikevlz|3 #
12:44
отлично
`kk #
12:44
-)
_4ePTeHok #
12:44
и порт_айди у него - GigabitEthernet 0/1
12:45
и линк мы построить не можем
mikevlz|3 #
12:45
значит надо, чтоб в профиле этого длинка был конвертор, который поймет и отнормализует то, как видит порт соседа ежик
_4ePTeHok #
12:45
потому что в инвентори линк снятый длинковским гет_интерфейсес - Gi 0\1
12:45
наеборот
mikevlz|3 #
12:45
епт
_4ePTeHok #
12:45
в скрипте ежика надо сконвертить полученное имя
mikevlz|3 #
12:46
ненене
_4ePTeHok #
12:46
функцией из профиля длинка
ApmeM #
12:46
кстати, такая картина наблюдается не только на ежиках, но и на самих длинках. в связке 3610-26G - 3120-24SC
mikevlz|3 #
12:46
в скрипте ничего делать не надо
12:46
это делается автоматом при проходе lldp_discovery job
_4ePTeHok #
12:47
блин
12:47
совсем запутали
mikevlz|3 #
12:47
джоб вызывает конвертор из профиля соседа. Надо в профиле соседа дописать конвертор, чтоб он понимал и то, как отдают его порт длинки, и то как отдают его порт ежики, кошки
12:47
а скрипт пусть остается как есть
12:47
ты посмотри код Job_а
_4ePTeHok #
12:47
так чо, в каждом профиле прописывать функции конвертации всех профилей?)
mikevlz|3 #
12:48
получается, что надо дополнять конвертор для того, чтоб он не только свой DxS_Cisco_like_cli понимал, но и чужие выдачи
`kk #
12:49
ох
_4ePTeHok #
12:49
даешь мегаконвертилку
12:49
а теперь самый главный вопрос
`kk #
12:50
ещё и стэк её научить понимать
mikevlz|3 #
12:50
длинк говорит о своем порту как Gi 0/1, ежик об этом же порту говорит GigabitEthernet 0/1. С этим выводом должен справиться конвертер профиля DxS_Cisco_like_cli
_4ePTeHok #
12:50
как оно узнает, что нужно именно вот эту функцию для ежика использовать, а не вот эту для длинка
`kk #
12:50
mikevlz|3, нет же
12:51
в Gi 0/1 конвертит get_interfaces
12:51
_4ePTeHok, nfr ;t&
12:51
так же?
_4ePTeHok #
12:51
длинковский да
`kk #
12:51
вот
_4ePTeHok #
12:51
а в кли у него полное имя
12:51
и в ежик по ллдп он отдает полное имя
`kk #
12:51
надо чтоб get_interfaces писал в нок свой инт GigabitEthernet 0/1
12:52
я так всё это понял
_4ePTeHok #
12:52
либо
12:52
чтобы из гет_ллдп ежика можно было нормализовать полученное имя длинковской функцией нормализации
ApmeM #
12:53
<`kk>, да именно длинковский профиль конвертит интерфейс
mikevlz|3 #
12:53
def get_remote_port_by_name(self, object, port):
12:53
return object.profile.convert_interface_name(port)
12:54
эта функция вызывается дискаверилкой. Объектом передается СОСЕД, портом - то, что выдал get_lldp_neighbors в качестве порта соседа
_4ePTeHok #
12:54
т е ничего не надо
12:54
прикольно.
mikevlz|3 #
12:54
итого, если тип соседнего порта не MAC, то оно отконвертит его в соответствии с профилем СОСЕДА, то есть длинка
12:54
в данном случае
12:55
значит, как я и говорил, надо, чтоб профиль соседа смог сконвертить GigabitEthernet 0/1 в Gi 0/1
12:55
тогда сростется
12:55
ладно, побегу
_4ePTeHok #
13:00
дык соседовский гет_интерфейсес и так конвертит имя в гет_интерфейсес своем)
`kk #
13:03
iface = self.profile.convert_interface_name(iface)
_4ePTeHok #
13:04
угу, из инита профиля берет
dvolodin #
13:14
в DLink.DxS_Cisco_CLI сделайте convert_interface_name
13:14
по аналогии с киской
13:14
и все заработает
13:15
нужно конвертить только свои имена
13:15
discovery сам дернет правильный профиль
ApmeM #
13:18
в DxS_Cisco_CLI в файле __init__py имеется
13:18
convert_interface_name = NOCProfile.convert_interface_name_cisco
13:19
или сделать свой собственный?
13:19
имеется ввиду для профиля
_4ePTeHok #
13:27
ну в дискавери же эта функция у тебя конвертит верно
13:27
ой, в гет-интерфейсес
`kk #
13:27
а вот если бы не конвертила..
_4ePTeHok #
13:28
ну он говорит что дискавери джоб не находит линк
13:28
гет-ллдп отдает развернутое имя
13:28
как отдебажить джоб - хз
ApmeM #
13:30
вот то, что отдает get_lldp у длинка
13:30
[{'local_interface': 'Gi 0/1',
13:30
'neighbors': [{'remote_capabilities': 4,
13:30
'remote_chassis_id': '70:72:CF:15:FA:74',
13:30
'remote_chassis_id_subtype': 4,
13:30
'remote_port': '70:72:CF:15:FA:7D',
13:30
'remote_port_subtype': 3,
13:30
'remote_system_name': 'GOR_8'}]},
13:30
а вот то, что отдает сосед (еджкор)
13:30
[{'local_interface': 'Eth 1/9',
13:31
'neighbors': [{'remote_capabilities': 22,
13:31
'remote_chassis_id': '00:21:91:C7:D6:F7',
13:31
'remote_chassis_id_subtype': 4,
13:31
'remote_port': 'GigabitEthernet 0/1',
13:31
'remote_port_subtype': 5,
13:31
'remote_system_name': 'DGS3610'}]}]
13:32
но это результат debug-script, что получает на выходе discovery неизвестно
mikevlz|3 #
15:45
вы тут все еще холиварите?
Tweet
Share this page
Share this page: Tweet