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: 16.03.2014
buggy-funhouse #
08:52
народ. удалил линки с помощью
08:52
mongo noc
08:52
db.noc.links.remove({"discovery_method" : "stp"})
08:52
db.noc.links.runCommand("compact");
08:52
В карте линки пропали, но номера интерфейсов остались
08:52
как их почистить тоже?
08:53
или как удалять правильно?
08:53
не из дб напрямую
HaLVeR #
08:56
плохо из базы удалять, плохо.
buggy-funhouse #
08:56
и почему номера интерфейсов идут не по порядку рядом с иконкой?
08:57
HaLVeR: научи, как, пожалуйста
HaLVeR #
08:57
ну уже позно же
buggy-funhouse #
08:59
HaLVeR: знать не поздно, а я напишу на сайте, как верно
HaLVeR #
08:59
def api_unlink(self, request, iface_id):
08:59
i = Interface.objects.filter(id=iface_id).first()
08:59
if not i:
08:59
return self.response_not_found()
08:59
try:
08:59
i.unlink()
09:00
выгоняешь в фильтр линки которые надо снести
09:00
и анлинкишь
buggy-funhouse #
09:01
это из shell? определяю свою функцию api_unlink?
09:03
и как узнать iface_id?
HaLVeR #
09:05
ненадо определять, это выдержка из кода интерфейса приложения инвенотри-интерфейсес
09:05
ты же фильтруешь по типу
09:05
стп
09:06
вои и вприши туда не айди, а тип- стп, и без ферст
buggy-funhouse #
09:12
HaLVeR: NameError: name 'Interface' is not defined
09:13
я зашёл в noc shell и там набираю для начала i = Interface.objects.filter(type=lldp) так?
HaLVeR #
09:13
gjujlb
09:13
погоди
09:13
ты все линки снести вообще хочешь?
buggy-funhouse #
09:15
нет, только одного типа
09:15
stp неверно их построил
09:15
я могу хоть все снести, не страшно
09:15
для теста, так сказать
HaLVeR #
09:20
from noc.inv.models.link import Link
09:20
for i in Link.objects.all():
09:20
if i.is_ptp:
09:20
i.delete()
09:20
это снесет все
buggy-funhouse #
09:22
Ок. а как только то, то построенно по какому-то типу дискавери?
09:22
Например, стп
09:23
HaLVeR: нигде не ошибся? iF подсвечивает
HaLVeR #
09:24
пробелы смотри
buggy-funhouse #
09:25
смотрю, но:
09:25
>>> for i in Link.objects.all():
09:25
... if i.is_ptp:
09:25
File "<console>", line 2
09:25
if i.is_ptp:
09:25
^
09:25
IndentationError: expected an indented block
HaLVeR #
09:26
пробел добавь
09:26
не надо копипаст делать)
09:26
по типу удалить - for i in Link.objects.filter(discovery_method = "lldp"):
09:27
остальное так же
buggy-funhouse #
09:27
перед if пробел?
HaLVeR #
09:27
в питоне по 4 пробела отступы
buggy-funhouse #
09:27
питон так пробелозависим? о_О
HaLVeR #
09:27
в ирц могло скопироваться табуляцией
buggy-funhouse #
09:27
возможно
09:30
HaLVeR: с пробелами прокатывает. потом надо как-то выходить из режима ... ?
09:31
потому что пока всё на месте =)
HaLVeR #
09:32
энтер нажми пару раз
buggy-funhouse #
09:34
о, спасибо!
09:34
хорошего дня!
HaLVeR #
09:40
развлекайся)
dvolodin #
11:18
проверьте последний коммит
11:18
у него самые серьезные и самые долгоиграющие последствия
11:19
в solution'ы можно выносить сложную логику, которую затруднительно конфигурировать
HaLVeR #
11:21
объясни схему пользования?
dvolodin #
12:03
простая, как пять копеек
12:03
делаешь свой solution, определяешь в нем модули и прописываешь их в конфиге
12:03
и они будут использоваться вместо стандартного
zi_home #
12:52
dvolodin, примеры есть?
dvolodin #
12:52
solutions/
zi_home #
12:55
то есть fqdn template из конфига выпилишь
dvolodin #
12:57
почему?
12:58
дефолтное решение его как раз из конфигов берет
12:58
а если этого мало -- делай любое свое
zi_home #
12:58
ааа
12:58
ммм, все равно жесть
12:58
и я так и не понял зачем оно надо, ну и хрен с ним
dvolodin #
12:59
допустим, хочешь FQDN генерить по биллингу :)
zi_home #
13:00
dvolodin, хочу реквестировать поле project для managed object, ip address, lag и subinterface
HaLVeR #
13:00
dvolodin, про дискавери новых мыслей пока не было?)
dvolodin #
13:00
:)
13:00
всему свое время
HaLVeR #
13:00
с проджектом, я бы хотел сначала каталог сервисов
13:01
чтобы можно было прикреплять сервис к проекту
zi_home #
13:01
и это тоже
dvolodin #
13:01
у адреса -- project есть
HaLVeR #
13:01
п уже потом к инфраструктуре
dvolodin #
13:01
а с каталогом сервисов - думаю
zi_home #
13:01
но происать по какому проекту поставили новую железку и настроили лаг тоже хочется
13:01
и это просто сделать уже сейчас
dvolodin #
13:01
там должен быть абонент, сервис, задействованные ресурсы
zi_home #
13:01
мне кажется для всего это поле можно прописать
13:02
еще пиры по проектам включаются
dvolodin #
13:02
на LAG -- нужно просто в JS добавить выбор
HaLVeR #
13:02
у нас еще секурити менеджмент вообще без действия. А хотя бы iGetAccessLists стоило б добавить
zi_home #
13:03
и отдельный раздел куда кидать сообщения про безопасность
HaLVeR #
13:03
это отдельная группа должна быть, типа пиринг-менеджмента
zi_home #
13:05
dvolodin, кстати про сислог, железки часто присылают сообщения которые сложно определить в какой-то класс, часто это аппаратно специфично, то есть вообще классы на все эти сообщения воротить нереально, можно что-то придумать? моя мысль пока т
13:05
олько сделать отдельный класс куда всю эту специфику кидать, можно несколько по платформам
HaLVeR #
13:06
есть же вендорские классы
13:06
там вся специфика
dvolodin #
13:06
в вендорские классы
HaLVeR #
13:06
посмотри классы Cisco SCE
dvolodin #
13:06
если они вообще осмысленны
HaLVeR #
13:06
я делал там пару
13:06
(вроде комиттил)
buggy-funhouse #
13:07
народ, а например, если нет в get_chassid_id ответа у скрипта, значит что-то неверно ищет и надо происать костыль в скрипте?
HaLVeR #
13:07
дебаг посмотри
13:07
что там железка отвечает
13:08
может команда немного другого вида
13:08
или параметр требует какой то
buggy-funhouse #
13:08
допустим, немного другого вида.
HaLVeR #
13:08
скорректировать
13:08
только так, чтобы и по старому работало
buggy-funhouse #
13:08
там есть разделение по версиям, в sa/profiles/?
HaLVeR #
13:09
зависит от профиля, но обычно нет
13:09
в самом скрипте можно сделать проверку версии
13:09
и в зависимости от н ее дергать разные команды
13:09
есть такая штука - декораторы
13:09
в питоне
buggy-funhouse #
13:10
паттерны?
HaLVeR #
13:10
нет
13:11
@NOCScript.match(platform__contains="4612")
13:11
def execute_4612(self):
13:11
это например по платформе
buggy-funhouse #
13:11
а, и в зависимости от платформы, разный код
HaLVeR #
13:11
скрипт name = "EdgeCore.ES.get_arp"
13:12
там отдельно для 4612, и отдельно для всего остального
13:12
как пример
13:12
там может быть и версия софта
13:12
и платформа и т д
13:12
атрибуты что в гет-версион есть
13:15
если это надо транзитом в коде делать, то есть второй вариант
13:15
if self.match_version(platform__contains="4626"):
13:15
то же самое
13:15
по платформе
13:15
но в первом случае у тебя отдельные функции, а тут транзитом по условию ветвление
13:16
лучше придерживаться декораторов, оно лучше воспринимается в коде и более читабельно.
Huko #
14:31
а как обрабатывтаь vrrp интерфейсы ? как обычнй L3 SVI когда они в состоянии актив ? а если в состоянии backup не отдавать ?
zi_home #
14:40
Huko, как так, для vrrp всегда есть активный l3 интерфейс, просто есть еще виртуальный ip, который скачет, или что у тебя за железка
Huko #
14:42
есть реальный ip на влане и виртуальный на vrrp на 2 железках который в одно время активент только на одной. не пойму как их занести в базу. железо - Avaya.
14:43
#sh ip vrrp interface
14:43
VLAN VR Virtual Admin Primary Master
14:43
ID ID IP Address State State IP Address IP Address
14:43
---- --- --------------- ---------- ----- --------------- ---------------
14:43
10 6 10.15.253.11 Backup Up 10.15.253.10 10.15.253.9
14:43
1010 1 10.15.10.1 Backup Up 10.15.10.104 10.15.10.103
14:43
как-то так
zi_home #
14:46
Huko, вариант, виртуальный ip на обоих железках возвращать как второй
14:46
IPv4 addresses там списком идет, так что проблем быть не должно
Huko #
14:47
только виртуальный ip в одно время активен на одной железке
zi_home #
14:47
ну и что
14:47
нок сейчас ничего не знает про fhrp
14:47
так что только так
Huko #
14:47
получится что 1 ip на 2х железках
zi_home #
14:47
да
14:48
не самый лучший вариант, но тоже нормально
Huko #
14:48
я думаю отдавать только когда он в стостоянии active
zi_home #
14:48
у меня полно таких, когда точку терминации клиента перетаскиваешь
14:48
в старым месте интерфейс гасишь, в новом поднимаешь
14:48
и вот оно уже в жвух экземплярах на сети
14:49
и в ноке соответственно
Huko #
14:49
падает основаня железка, vrrp подхватывается на backupи переходит в состояниее актив
zi_home #
14:49
да
14:49
но
14:49
база это так оперативно не отследит
14:50
вообще хороший вопрос
14:50
я думаю надо пинать dvolodin чтобы сделал интерфейс для FHRP
Huko #
14:50
а так я точно не узнаю где у меня реально терминируется ip на каком из 2х ядер
zi_home #
14:51
а надо?
Huko #
14:51
fhrp это vrrp ?
zi_home #
14:51
fhrp - first hop redundancy protocol - это все vrrp, hsrp, glbp, carp etc.
Huko #
14:53
хз, наверное надо. с точки зрения логики мне было бы удобней видеть где в данный момент живет этот виртуальный интерфейс
zi_home #
15:05
задй вопрос сам знаешь кому, когда здесь появится, у меня на сети есть vrrp, отслеживать его статус меня пока не парит
Huko #
15:16
у меня пости вся сеть постороена на vrrp, точнее default gw для почти всех сегментов именно vrrp указан, поэтому мне имеет смысл заморочится
zi_home #
15:20
use routing protocols :)
Huko #
15:27
Ok Luke, I will :)
buggy-funhouse #
18:04
zi_home: доброй ночи =) Как протоколы маршрутизации помогут корректной записи в noc?)
zi_home #
18:05
не придется заморачиваться с вррп и виртуальными адресами
buggy-funhouse #
18:06
только если так =)
18:07
zi_home: если приоритеты на интерфейсы вешать в плоской сети?
zi_home #
18:07
чего?
buggy-funhouse #
18:08
как ты избыточность сделаешь?
zi_home #
18:09
с роутингом как раз все прозрачно
Huko #
18:11
vrrp у нас юзается исключитаельно в целях HA, от 2 ядер идет 2 линка на доступ, на достуах роутинг на vrrp интерфейс, в случае выхода из строя одного ядра - все продолжает работать
18:12
при чем тут роутинг - тоже хз ;)
zi_home #
18:13
ты сказал что сеть построена :)
buggy-funhouse #
18:15
понятно
18:15
что ничего не понятно
18:15
смысла писать какие-то новые фичи
18:15
надо текущие доделать
18:16
я уже python ide скачал
Huko #
18:16
да, сеть уже построена
zi_home #
18:19
buggy-funhouse, самое главное сделал, теперь начинай доделывать :)
buggy-funhouse #
18:19
тоже так подумал
18:19
а как-то можно целиком нок добавить?
18:20
чтобы прыгать по определениям функций
18:20
а то грепать и добавлять по-одному не очень
zi_home #
18:20
без понятия
buggy-funhouse #
18:20
ок
18:20
так тоже норм
Huko #
18:22
zi_home: в lldp силен ?
zi_home #
18:22
вообще никак
buggy-funhouse #
18:22
а что такое?
18:22
у меня есть пара lldp-only девайсов
Huko #
18:23
не могу понять логику noc
18:24
"remote_port":"24", а в другом месте "remote_port":"00:12:CF:C8:2B:39"
18:24
это из разных бифов
buggy-funhouse #
18:25
а с самого девайса detail смотрел?
18:25
скорее всего, он так и отдаёт
zi_home #
18:25
разнве железки могут разные идентификаторы отдавать, там кажется еще где-то тип указывается, какой именно идентификатор использовался
buggy-funhouse #
18:25
у меня подобная фигня с dlink
Huko #
18:25
не пойму как noc учитывает этот параметр или вообще на него забивает и смотрит только на "remote_chassis_id":
18:26
мои железки remote_port отдают как mac
zi_home #
18:26
Port ID Subtype : MAC Address
18:26
Port ID : 00-21-91-A6-F0-FF
Huko #
18:27
но когда я строю строю таблицу интерфейсов L2 маки я беру от chassis_id
buggy-funhouse #
18:27
у меня некоторые отдают порт id как chassis_id с заменой последнего октета на ff
18:27
вот как zi_home сейчас написал
Huko #
18:27
LLDP neighbor
18:27
-------------------------------------------------------------------------------
18:27
Port: 4/47 Index: 398 Time: 43 days, 09:43:23
18:27
ChassisId: MAC address 6c:fa:58:6b:2f:00
18:27
PortId: MAC address 6c:fa:58:6b:2f:30
18:27
SysName: ood-rsa-lan-5
18:27
SysCap: rB / B (Supported/Enabled)
18:27
PortDesc: Port 48
18:27
SysDescr:
18:27
Ethernet Routing Switch 5650TD HW:07 FW:6.0.0.15 SW:v6.3.0.012
18:27
-------------------------------------------------------------------------------
18:27
Sys capability: O-Other; R-Repeater; B-Bridge; W-WLAN accesspoint; r-Router;
18:28
T-Telephone; D-DOCSIS cable device; S-Station only.
buggy-funhouse #
18:29
Huko: у тебя есть поле Port-descr
Huko #
18:29
хорошо что ChassisId: совпадает, думаю по этому принципу уже можно строить линки
zi_home #
18:29
Huko, ну вон там написано MAC address так и учитывает
18:29
должен по крайней мере
18:29
я не знаю как ллдп в ноке работает
18:29
никогда не парился
18:29
у меня циски
18:30
я через оам и udld дискаверю
18:30
и еще немного cdp
Huko #
18:30
а мне похоже придется запарится с lldp, изучаю матчасть
buggy-funhouse #
18:31
Huko: тебе нужно будет ноку отдавать инфу о порте
18:31
ему надо(
Huko #
18:31
смотрю у кого на какой платформе как реализовано
18:33
есть еще команда sh lldp local-sys-data где описаны PortId: MAC address локальной железки, я думаю нужны мне они в каком-то виде или нет
18:33
т.е. эти маки используются только для lldp. наверное..
buggy-funhouse #
18:33
по факту, тебе надо remote port, remote id
18:33
т.е. в этом виде отдавать
18:34
т.е. port id в виде мака не прокатит
zi_home #
18:34
/opt/noc/sa/profiles/DLink/DxS/get_lldp_neighbors.py
18:34
смотрите как у длинка реализовано
buggy-funhouse #
18:34
да, только я как раз это хотел допилить, некоторое железо упорно мак отдаёт
18:34
у dlink
Huko #
18:35
ну у меня уже в базе есть ChassisId: каждой железки, по lldp это хорошо резолвится и совпадает с истинной - думаю достаточно ли этого будет
buggy-funhouse #
18:36
а как ноку понять какой порт с каким соединять?
Huko #
18:36
хотя надо же знать как какому порту удаленной железки идет линк
18:36
точно
18:36
PortDesc: Port 48 наверное мне в помощь
buggy-funhouse #
18:36
ага
18:37
у тебя так, а у меня надо включать lldp-ful-information и мне будут порт писать в дополнительном поле. и на том спасибо =)
Huko #
18:37
у меня тоже есть detail, но там много воды имхо
buggy-funhouse #
18:37
придётся включать
18:37
что за вендор?
Huko #
18:38
мне хватит ChassisId: и PortDesc: для идентефикации соседа, осталось понять что такое remote_capabilities и remote_chassis_id_subtype
18:39
Avaya
18:39
в юнешестве Nortel
buggy-funhouse #
18:39
нортел помню
Huko #
18:40
угу, сейчас это все называется Avaya ERS
buggy-funhouse #
18:41
на xgu просто и со вкучом пишут
18:41
даже вроде был lldpdu разобран
18:42
смысл такой же, как и у всех: router, switch, bridge
Huko #
18:42
это понятно
18:42
Sys capability: O-Other; R-Repeater; B-Bridge; W-WLAN accesspoint; r-Router;
18:43
просто в каком виде это noc принимат и делает ли он что-то с этой информацией
buggy-funhouse #
18:43
а. ну для discovery оно вряд ли нужно
Huko #
18:43
ну я тоже так думаю
18:43
прочто смутило что в ноке целых два параметра по этому поводу передается
buggy-funhouse #
18:44
самая проблема, это со всего парка девайсов одного вендора отдавать однотипную инфу
18:44
из get_lldp и get_cdp, например
Huko #
18:50
здесь вендор 1
18:51
все линейки свичей отдают одинаково, по крайне мере я так думаю
buggy-funhouse #
18:52
возможно. контора нормальная, это не dlink =)
Huko #
18:53
да, это несомненно плюс :)
zi_home #
18:59
если новый профиль и делаешь для себя то можно не сильно париться по повду железок которых нет
Huko #
19:05
да, профиль дедаю с нуля.
Tweet
Share this page
Share this page: Tweet