nocproject.org

NOC-220

По NOC-36 понял что надо конвертацию с 16 в 10 делать в самом скрипте, все кажись получилось.

Закомител get_arp с SNMP для Zyxel.ZyNOS_EE, Eltex.MES, Linksys.SPS2xx также тестовый пример есть здесь: NOC-36?focusedCommentId=10643&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-10643

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

Но плохо то что ID интерфейсов по 1.3.6.1.2.1.4.22.1.1 для Eltex.MES, Linksys.SPS2xx это ID vlan: "1.3.6.1.2.1.31.1.1.1.1." + ID

И по этому у меня вывод get_arp в cli и snmp разный!!!

Скопипастил у себя для профилей Zyxel.ZyNOS и DLink.DxS, в первом cli даёт vlan.., а для второго вывод идентичен!

я почти сделал NOC-219

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

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

o_O

если каталоги индексируются - то файлы выдаются в сортированном порядке

если не индексируются (тот же UFS/FFS), то в случайном

часть MIB'ов определяет одни и те же OID'ы

вот и получаются у них имена случайные

в зависимости от порядка загрузки

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

это небось длинк стандартные oid совими именами обозвал?

неа

RFC-1213 и IF-MIB хотя бы

dvolodin, доброе утро. SAE так и продолжает крашиться. Хотя все объекты были пересозданы (Кроме SAE).

на чем крашится?

Вот пастебин трейсбека: http://pastebin.com/5gT7d6ZW Как понимаю крашится при попытке выбора объектов из списка

Бегает все это под 6й центосью. Из странного есть только при пост апдейте записи: /usr/lib/python2.6/site-packages/pycrypto-2.4.1-py2.6-linux-x86_64.egg/Crypto/Util/number.py:57: PowmInsecureWarning: Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.

_warn("Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.", PowmInsecureWarning)

managed object с id = 2 есть?

нет. в sa_managedobject записи с id 2 нет

была и стерли ее?

Возможно и такое

NOC-36 get_arp и get_mac_address_table кажись можно уже написать..

dvolodin, проще перезаписать базу?

нет

mongo noc

db.noc.discoverystatusinterface.drop()

Хочу порты VLAN по SNMP дёргать.. snmpwalk -v 1 -c public 10.8.23.131 1.3.6.1.2.1.17.7.1.4.3

Стоит пробовать get_switchport через snmp?

dvolodin, отдало false

db.noc.discovery.status.interface.drop()

тру

gnu-linux а чо надо вжать чтобы if self.snmp and self.access_profile.snmp_ro сработало? коммунити вписано в объекте

да коммунити в объекте достаточно.

gnu-linux ну вот, а чегойто не пытается даже

debug-script'ом пробуешь?

но добавить ip трапа и комунити трапа тоже не помешает.., особенно если трапы на коммутаторах настроено скидывать на нок..

Запускать так: ./noc debug-script get_arp ID

Запускать так: ./noc debug-script get_arp ID -c <комунити>

-c <комунити> - тогда даже что в настройках объекта прописано не важно..

уважаемые, а каков best practice в хранении ip-адресов, про которые в Важной Бумажке написано "хз"?

dvolodin угу им, в выводе ваще 0 копеек про SNMP

./noc debug-script -c- script <object>

evyscr: лепить тег хз :)

[TELNET: 10.90.91.141] ==> START

dvolodin: и аналогичный fqdn?

wtf-10-90-91-141.example.com

:)

вообще, плохо укладываюсь в бинарность used/free

предложения?

я думал про заведение, скажем, поля status

туда и reserved запихать можно будет

какая-то фигня если честно, по обратке определять статус ;-)

вообще, какова политика партии в развитии ipam?

.

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

command_save_config = "copy running-config startup-config"

evyscr: IPAM развивается, как и все компоненты

будет также переводиться на ext js/rest

собственно, коли noc-discovery любезно собрал нам интерфейсы, можно уже делать связку с ipam

чтобы их видно было в общей табличке

при этом ссылку на managed object в ipam можно начинать искоренять

noc-discovery не соберёт интерфейсы с managed object, которые в действительности не managed.

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

а то у меня 300 объектов роутятся по глобальной таблице, а еще 3000 в врф и в ипам для них отдельные врф стоят

и еще, лупбеки дискавери в ипам будет загонять как ip address или как ip prefix с маской /32

zi_rus_: он разделяет интерфейсы по forwarding instance

один из типов FI -- VRF

не понял

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

и правильно раскидать ip по ipam

с топологией, в принципе, может

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

научим

а если не хочешь запускать на кисках discovery, то ССЗБ

как оно про VRF узнает?

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

про врф можно указать в свойствах объекта

или сделать привязку адм.домен <> врф

я же и говорю про доп параметр

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

теоретически - имея L3 интерфейсы на железке на SVI, можно оттрасировать vlan и посмотреть, не вылезает ли он из VRF

типовое кольцо или сопля упрутся в MPLS рано или поздно

я думаю, это самое простое что можно предусмотреть в работе дискавери, не говорим об AToM и service instance

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

по конфигам точно не будем делать

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

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

разве железка может сказать больше чем есть у нее в конфиге?

btw, эмайрайт что дискавери надо перезапускать после добавления/изменения managed objects?

ценность в том что по конфигу в репо он сможет сделать это много быстрее

чем бегать от железки к железке в поисках влана

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

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

zi_rus_ есть и недостаток, если понадобится оттрейсить влан сдесь и сейчась, в актуальном времени, придется дергать все свежие конфиги со всех девайсов ))

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

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

zi_rus_ а если учесть что в некоторых скриптах и так дергается весь конф или его существенная часть....

zi_rus_: да вот тебе навскидку. Есть киска. Есть конфиг интерфейса. Ты можешь сказать, включен ли proxy arp или нет?

evyscr: да, мы будем запускать его после измеения конфига

rp3u: конфиг вообще-то перечитывается и по событиям fm

если не ошибаюсь, proxy arp включается глобально

когда видит, что конфиг изменяется

на интерфейс он включается

у половины ios он по дефолту включен, а на половине - выключен

то есть если ты видишь явно

ip proxy-arp или no ip proxy-arp

то да, статус понятен

dvolodin, вот кстати, как он определяет изменяется ли конфиг, кроме цисковских железок

а если не видишь, то зависит от того, какой дефолт в конкретном ios'е

это да

zi_rus_: на всем он определяет

по syslog/snmp

как попал под класс Config | Config Changed, то перечитываем через 10 минут

proxy-arp -- это тебе просто как конкретный пример

причем на одной платформе в зависимости от версии ios будет разное поведение

dvolodin тем более, конфиг актуальный всегда :)

dvolodin, вот по conf changed у меня предложение, мне не понравилось что он через 10 минут дергает конфиг. предложение такое: по событиям конфиг ченжд создавать список железок, а потом по расписанию дергать конфиг только с них

я думаю, это все решится в workflow

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

по умолчанию будет reschedule на 10 минут

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

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

zi_rus_: да, трассировка vlan'а делается элементарно

я даже сейчас 3 запросами в монге могу сказать, на каких портах vlan в tagged, на какиех в untagged, и где в L3 уходит

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

а по разрешенным интерфейсам, тоже вот тебе кисковский прикол

vlan 1 :)

слабо по конфигу понять, что это?

отключен и запрещен на всех интерфейсах

мы всегда так делаем

а вот болт тебе

а vtp :)

транспарент

это у тебя transparent

ибо нафиг он не нужен

это по уму так надо делать, даже циска рекомендует его отключать

а некоторые каталисты из-за vtp не дают блокировать первый vlan на транках

одно неловкое движение и сеть легла

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

итого - не стоит овчинка выделки

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

смысл какой?

валидация конфигов у нас будет и так

быстрее

и проверка политик

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

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

вопрос в бюджете мероприятия

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

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

За 100k$ я его на Си перепишу :)

zi_rus_: я не могу сказать, что NOC-тормоз :)

а он еще ничего и не делает такого

zi_rus_, у меня делает.

например? может и мне надо :)

например - валидацию конфигов делает.

на полторы тыщи устройст

там не нужна скорость, ночью конфиги сдернулись, ночью проверились, и не заметил, за 10минут или за 2 часа

а где нужна скорость ?

прямое взаимодействие с пользователем

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

prefix_list_builder или show free prefixes (в ипаме)

И все формы строились прямо на компе пользователя.

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

zi_rus_: а для этого топология в базу и ложится

жмакнул кнопку - и оттрасировал его до BRAS'а

C SNMP в арпе есть бага..

когда вторую таблицу создаёшь надо контролировать существование мака.. ибо они динамически...

Вот максимум что удалось выжать для get_mac_address_table NOC-36?focusedCommentId=10645&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-10645

У кого будут идеи как vlan_id c OID дёрнуть отпишитесь..

gnu-linux а как у тебя коррелируют ARP и FDB ?

ARP это для L3, а mac_address_table вроде как чисто FDB выдает не?

никак:) они с разних OID берутся...

Пойди по ссылке там видно что OID разные..

да вы осоловеле

железяки из базы так и нельзя удалить

ты уже третий на этой неделе

давайте создадим issue и проголосуем

:)

welcome

NOC-228

голосуем)

ну ты там полегче.

я счас какааааа

начну писать доку

zi_rus_: а что делать с event'ами для удаленной железки?

что делать с конфигами?

что делать с алармами, особенно если они root cause для других?

на усмотрение

удалять / архивировать

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

причем user-defined, опять же по flow заданному

типа "Запланирована" > "В настройке" > "В работе" > "К удалению" > "Снята"

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

почему вляпались?

а что с объектом еще можно сделать?

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

у состояний делать галочку -- рабочий он или нет

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

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

:)

кому как повезет, у нас иногда тесты приходится делать на боевой СЕТИ

у меня счас в сети снимаются 10 коммутаторов изза того что они просто не нужны

и 76 цисок ещё снимут скоро

херняс (С)

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

иль у меня прав нету7

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

для инвентори может быть полезно

тем не менее СЕЙЧАС это проблема, ее или надо решать или сделать неактуальной

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

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

а объединить можно? (события etc.)

(не сейчас, а вообще)

не удаляется она, трейсбэкает