nocproject.org

dvolodin, пояснить можешь почему не строиться линк между Juniper и Cisco catalist по LLDP? Друг друга видят корректно

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

секунду, дебагом {'local_interface': 'GigabitEthernet0/0/23',

'neighbors': [{'remote_capabilities': 4,

'remote_chassis_id': '00:22:56:5B:CE:85',

'remote_chassis_id_subtype': 4,

'remote_port': 'Gi0/5',

'remote_port_subtype': 1,

'remote_system_name': 'Kan-ME3400'}]}]

это на Huawei S5300 видиться сиська

{'local_interface': 'Gi 0/5',

'neighbors': [{'remote_capabilities': 4,

'remote_chassis_id': '00:25:9E:98:14:20',

'remote_chassis_id_subtype': 4,

'remote_port': 'GigabitEthernet0/0/23',

'remote_port_subtype': 5,

'remote_system_name': 'S5300_ATS-CATS_SW1'}]},

вот на каталисте 3400

dvolodin, какие еще необходимы условия для построения линка?

remote chassis id и report_port с обоих сторон

remote

remote_port как видно 'Gi 0/5' 'Gi0/5'

В этом дело?

в инвертори имя интерфейса с пробелом, а по LLDP циска отдает без пробела

dvolodin, статус Feedback в NOC-952?

Что означет?

ss_: нужна обратная связь от открывшего заявку - ну там работает или нет и всё такое

обновиться чтоль и проверить?

ну да... или вручную изменённые файлы накатить

сделал ход конем на хуявее

{'local_interface': 'GigabitEthernet0/0/23',

'neighbors': [{'remote_capabilities': 4,

'remote_chassis_id': '00:22:56:5B:CE:85',

'remote_chassis_id_subtype': 4,

'remote_port': 'Gi 0/5',

'remote_port_subtype': 1,

'remote_system_name': 'Kan-ME3400'}]}]

'Gi 0/5'

#FOR CISCO

n["remote_system_name"] = n["remote_system_name"].replace(".cisco.com","")

n["remote_port"] = n["remote_port"].replace("Gi0","Gi 0")

#END CISCO

remote chassis id в данном случае MAC

в инвертори интерфейс они совпадают

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

где линки?

s5300

{'local_interface': 'GigabitEthernet0/0/23',

'neighbors': [{'remote_capabilities': 4,

'remote_chassis_id': '00:22:56:5B:CE:85',

'remote_chassis_id_subtype': 4,

'remote_port': 'Gi 0/5',

'remote_port_subtype': 1,

'remote_system_name': 'Kan-ME3400'}]}]

me3400

{'local_interface': 'Gi 0/5',

'neighbors': [{'remote_capabilities': 4,

'remote_chassis_id': '00:25:9E:98:14:20',

'remote_chassis_id_subtype': 4,

'remote_port': 'GigabitEthernet0/0/23',

'remote_port_subtype': 5,

'remote_system_name': 'S5300_ATS-CATS_SW1'}]},

вот get_interfaces с обоих железок http://pastebin.com/DhRW1zgB

Что же не так?

http://pastebin.com/Lx8dgFdv вот все чего должно хватать

dvolodin, посмотришь?

zi_rus может ты поможешь?

с чем?

http://pastebin.com/Lx8dgFdv а линка нет(

даже не знаю

ss_, так смотри

get_chassis_id Kan_ME3400

00:22:56:5B:CE:80

а китай видит

'remote_chassis_id': '00:22:56:5B:CE:85'

zi_rus, это мак порта

ss_, но на сколько я знаю алгоритм, он работает по chassis_id

если это не так то только Он тебе поможет

у меня сеть на этих МЕ-шках но ллдп мы не используем так что ничего не смогу проверить

zi_rus, chassis_id что за сущность?

ну, опять же, на сколько я знаю (не я же писал алгоритм), это мак которым светит эта железка в разных протоколах, например в REP

Base ethernet MAC Address : 68:BD:AB:AA:16:80 - это chassis id

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

Bridge MAC: 68bd.abaa.1680

а в ивертори на каждом интерфейсе свой мак

на 3400

hg resolve sa/profiles/Juniper/JUNOS/get_lldp_neighbors.py

merging sa/profiles/Juniper/JUNOS/get_lldp_neighbors.py

This Vim was not compiled with the diff feature.

merging sa/profiles/Juniper/JUNOS/get_lldp_neighbors.py failed!

как быть?

в стп он тоже как id используется

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

ss_, а как на циске выглядит вывод команды про ллдп?

просто длинк возвращает

Chassis ID : 00-21-91-A7-0A-00

и

Port ID : 00-21-91-A7-0A-FF

а у этого свича так и есть

MAC Address : 00-21-91-A7-0A-00

хотя наоборот

это хуавей мутит чего-то

это он chassis_id не тот показывает

на нем надо смотреть

zi_rus, какой chassis_id должен он показать?

тот который циска возвращает по get_chassis_id

он говорит что за портом у него 'remote_chassis_id': '00:22:56:5B:CE:85'

а дожен быть 00:22:56:5B:CE:80

выполни команду на хуавее, что он покажет?

по честному, не через скрипт

zi_rus, секунду

GigabitEthernet0/0/23 has 1 neighbors:

Neighbor index : 1

Chassis type :macAddress

Chassis ID :0022-565b-ce85

Port ID type :interfaceAlias

Port ID :Gi0/5

Port description :link to S5300 gi0/0/23

System name :Kan-ME3400.cisco.com

System description :Cisco IOS Software, ME340x Software (ME340x-METROIPACCESSK9-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2)

Copyright (c) 1986-2008 by Cisco Systems, Inc.

Compiled Thu 21-Aug-08 17:27 by nachen

System capabilities supported :bridge router

System capabilities enabled :bridge

Expired time :110s

Port VLAN ID(PVID) :1

Protocol identity :

Auto-negotiation supported :Yes

Auto-negotiation enabled :Yes

OperMau :speed(1000)/duplex(Full)

Power port class :PD

PSE power supported :No

PSE power enabled :No

PSE pairs control ability:No

Power pairs :Unknown

Port power classification:Unknown

Link aggregation supported:No

Link aggregation enabled :No

Aggregation port ID :0

Maximum frame Size :0

MED Device information

Device class :Network Connectivity

HardwareRev :ME-3400G-12CS-D (PowerPC405):C0

FirmwareRev :NA

SoftwareRev :12.2(46)SE

SerialNum :NA

Manufacturer name :Cisco Systems, Inc.

Model name :ME-3400G-12CS-D

Asset tracking identifier :NA

Media policy type :Voice

Unknown Policy :Unknown

VLAN tagged :No

Media policy VlanID :0

Media policy L2 priority :0

Media policy Dscp :0

Power Type :PSE

PoE PSE power source :Unknown

Port PSE Priority :Unknown

Port Available power value:0

Location format :Civic Address LCI

Location information:what(DHCP server) country()

Ca type Ca value

GigabitEthernet0/0/24 has 0 neighbors

http://pastebin.com/ оставлю это здесь

все вывалил

похоже китаец гонет

думаю, без костыля не обойтись

ss_, зарепорть хуавею баг :)

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

китаец должен возвращать chassis_id, а он возращает port id

Chassis ID :0022-565b-ce85 должен быть 00:22:56:5B:CE:80 ? правильно?

NOC-952 подтвердил

zi_rus, помоему это баг в скрипте get_chassis_id

на циско

он выдает только 1 мак, а должен диапазон

ss_, посмотри на циске stp, что написано в bridge_id

просто sh spanning tree

No spanning tree instance exists.

там его нет

ну создай какой-нибудь влан

на своих можешь глянуть?

на моих как надо

zi_rus, один мак везде?

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

да

один

rep/stp/udld

есть вообщем мысль по костылю

хотя udld по серийнику работает

осилю или нет не факт, если кто поможет сейчас начну

берем Chassis ID :0022-565b-ce85 берем Port ID :Gi0/5 выбираем 5 и отнимаем последнюю цифру из мака если в System description :Cisco IOS Software находим

как такие костыли?

баг репорт хуявею писать конечно можно

но когда они ипсравят

по моему дико

zi_rus, да ладно, этож хуявей

проще, заигнорить chassis_id и построить связь по system_name

zi_rus, как?

не знаю, ты же решил костыль делать

zi_rus, ну чтобы игнорить chassis_id то нужно понимать как работает алгоритм построения линка

еще не работает построение линком между джуниперами и хуявеяви

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

здесь

<ss_> dvolodin, какие еще необходимы условия для построения линка?

<dvolodin> remote chassis id и report_port с обоих сторон

<dvolodin> remote

совпадение с обоих концов

кстати, напрашивается у нас метод ManagedObject.get_interface(name)

с нормализацией имени по профилю

dvolodin, т.е. проблема с кривой реализаций протоколов может уйти?

да нет

это так, красотизм

нужно чтобы совпадали объекты и интерфейсы с обоих сторон

Huawei, вот, description вообще шлет

ss_, а не проше ли написать get_chassis_id и не изобретать костыли?

ApmeM_Skripnik, для какой железки:?

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

вот для этого профиля и писать/править

ApmeM_Skripnik, на обоих нормально они работают

ss_: get_chassis_id на твоем каталисте что возвращает? Особенно тебя интересует поле MAC

если вернет диапазон, в который входит мак 5-го порта, тогда из вывода хуавея НОК должен определить соседа и проблему надо искать дальше

в именах портов

mikevlz, для каталистов возвращается один мак

тогда ой

значит надо, чтоб get_chassis_id возвращал и остальные для каталистов

<ss_> zi_rus, помоему это баг в скрипте get_chassis_id

<ss_> на циско

<ss_> он выдает только 1 мак, а должен диапазон

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

вот про это тебе иговорят

база ведется, если включена

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

<mikevlz>, а snmp_ifindex участвует в построении линков?

нет. Для lldp по-крайней мере нет такой функции. Ремотпорт может найти по маку и по имени.

но всегда можно такую функцию дописать

тогда станет искать

<mikevlz>, у меня есть проблема с алкателем. он по ллдп отдает не имя порта, а ifindex

использование snmp_ifindex решило бы проблему

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

я до сих пор считаю что get_chassis_id должен возвращать все маки которые есть на циске, например каждый интефейс имеет свой уникальный мак

т.е. {'first_chassis_mac': '00:22:56:5B:CE:80',

'last_chassis_mac': '00:22:56:5B:CE:80'}

last_chassis_mac = first_chassis_mac + 16 Gigabit Ethernet interfaces

1 - убедиться, что все соседи всех алкателей отдают в get_interfaces еще и ifindex, который пишется в базу

2 - дописать поиск remote port по ifindex

ss_: bt.

mikevlz, усь?

ss_: nocpro

=)

issue делай вот шо имею в виду

ApmeM_Skripnik, джиниперы по LLDP тоже индекс отдают

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

mikevlz, неосилю

давай лучше костыль

осиливай

иначе будет только у тебя костыль

а так - может попадет в основную ветку

<mikevlz>, наверное я не правильно обьяснил - у меня только алкател отдает вместо порта ifindex. соседи отдают алкателю информацию коректно

ss_ закинешь шаблонов ?

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

и не будут толпы гулять с вопросом "а чо у меню хуавей с циской по ллдп не нюхаются?"

ufir, ща

ApmeM_Skripnik: мммм. На ком исполняется поиск нейборов?

еджкор и длинк

ApmeM_Skripnik: то есть что-то в духе: "Если запустить на алкателе get_lldp_neighbors, то он, собака, в ответе скажет, что на порту ifindex он нашел соседа длинка с портом portname"

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

<mikevlz>, давай я покажу вывод с алкателя и с соседа. тогда станет понятно

ApmeM_Skripnik: то-есть, если я правильно понял, спрашиваем у длинка/эджкора кто у них соседи - они отвечают: алкатель какой-то, порт его - Ifindex

показывай

ss_: чтобы понять, как работает поиск соседей надо залезть в исходники: Inv/discovery/jobs/link_discovery.py и lldp_discovery.py

mikevlz, джунипер + хуявей

mikevlz, спасибо глянем

кстати циска замечательно себе видит хуавей по ллдп

ss_: ты уже определись. Кто там с хуавеем рядом. Всю дорогу мы говорим, что для циски в ид возвращается только один мак, а нюхаются у нас джуниппер с хуавеем

только странно

и так имеем вывод с алкателя,

{'local_interface': '1/25',

'neighbors': [{'remote_capabilities': 22,

'remote_chassis_id': '00:21:91:C7:D6:F7',

'remote_chassis_id_subtype': 4,

'remote_port': 'TenGigabitEthernet 1/1',

'remote_port_subtype': 5,

ufir, и у меня

'remote_system_name': 'DGS3610'}]}]

и вывод с его соседа, 3610-26G

{'local_interface': 'Te 1/1',

'neighbors': [{'remote_capabilities': 20,

'remote_chassis_id': '00:E0:B1:88:7A:B8',

'remote_chassis_id_subtype': 4,

'remote_port': '1025',

'remote_port_subtype': 7,

'remote_system_name': 'Alcatel6850'}]}]

т.е. сосед видит порт как 'remote_port': '1025', вместо 1/25

cs02#sh lldp neighbors

Device ID Local Intf Hold-time Capability Port ID

jsw02-yla-laz Gi1/0/47 120 B,R 536

Quidway Gi1/0/45 120 B Ethernet0/0/24

жунипер тоже

похоже индекс интерфейса

ufir, индекс, точно я проверял вчера

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

т.е. надо сначала ifindex выдаргивать

ApmeM_Skripnik: решение чуть проще. get_interfaces для алкателя возвращает ifindex портов?

ufir, в интерфейс инвертори уже есть

нет, он возвращает 1/25

не-не-не... Скрипт кроме имени МОЖЕТ возвращать еще и индекс порта

просто грязным хаком это обходить не стОит

какой параметр за это отвечает?

snmp_ifindex,

выполни на алкателе get_interfaces

выполнил

если возвращает, то надо будет дописать get_interface_by_ifindex в lldp_discovery.py

что искать?

mikevlz, сделаешь?

вот часть вывода

{'admin_status': False,

'enabled_protocols': ['LLDP'],

'mac': '00:E0:B1:88:7A:CF',

'name': '1/22',

'oper_status': False,

'subinterfaces': [{'admin_status': True,

'description': '',

'enabled_afi': ['BRIDGE'],

ApmeM_Skripnik: тот самый snmp_ifindex

'is_bridge': True,

'mac': '00:E0:B1:88:7A:CF',

'name': '1/22',

'oper_status': True,

'snmp_ifindex': 1022,

'untagged_vlan': 1}],

'type': 'physical'},

'snmp_ifindex': 1022, оно?

ага... возвращает

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

lldp_discovery

ss_: не-а, не сделаю :/

еще момент - в базу он их не пишет

ApmeM_Skripnik: как проверил?

ufir, куда слать

1. визуально - посмотрел в inventory - interfaces

2. посмотрел в монге

хотя в логах имеется информация что snmp_ifindex найден

в веб-морде нет поля для ифиндекса вообще. В монге поле зовется ifindex, а не snmp_ifindex

лучше в шелле попробуй

что именно?

from noc.inv.models import *

s1 = SubInterface.objects.filter(name='1/22',mac='00:E0:B1:88:7A:CF')

s1

если получишь непустой массив, то s1[0].ifindex еще выведи

[<SubInterface: 6850-u24x 1/22>]

>>> s1[0].ifindex

1022

>>>

вот

видишь, есть в базе индекс...

значит делай issue, что длинки и эджкоры видят порт алкателя в lldp как locla(7), при этом порт идентифицируется по ifindex

понял, а я его смотрел в noc.interfaces

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

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

[{'local_interface': 'Eth 1/9',

'neighbors': [{'remote_capabilities': 20,

'remote_chassis_id': '00:E0:B1:88:7A:B8',

'remote_chassis_id_subtype': 4,

'remote_port': '31-30-31-37',

'remote_port_subtype': 5,

'remote_system_name': 'Alcatel6850'}]}]

'remote_port': '31-30-31-37' - вот это собственно о чем?

и как с ним работать?

а вот хрен его знает... порт алкателя 17-й?

с remote_chassis_id_subtype какие варианты бывают?

из разряда догадок :)

кстати да, 17-й

вот удиви меня - откуда догадка?

я конечно наивный албанский дурачок, но разве 0х31 это не 1? %)

получается просто строка 1-0-1-7, убираем минусы - получаем 1017, только тип порта неверный, это опять ифиндекс, а не портнэйм

кататак

вот как тут обойтись без мата?????

0х31 - кто бы мог подумать ???

у каждого свой lldp с блек джеком и шлюхами

0х31 - имелось в виду что 31 шестнадцатиричное соотвествует коду цифры 1

а так да... индусам-программистам надо вешать перед носом плакат с надписью "не пей и не кури!"

поздно... это уже на генном уровне.

осталось придумать что с этим счастьем теперь делать.

ApmeM_Skripnik, тихонько напевает "А мы сделаем свои костыли с "блек джеком и шлюхами""

))))

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

>>> s1 = SubInterface.objects.filter(mac='00:22:56:5B:CE:81')

>>> s1

[<SubInterface: Kan_ME3400 Gi 0/1>]

>>> s1 = SubInterface.objects.filter(mac='00:22:56:5B:CE:85')

>>> s1

[<SubInterface: Kan_ME3400 Gi 0/5>]

remote_chassis_id_subtype кто скажет какие бывают?

subtypo'в 7, если память мне не изменяет

смотри LLDP-MIB

http://www.ieee802.org/1/files/public/MIBs/LLDP-MIB-200505060000Z.txt нашел тут The enumeration 'macAddress(3) и The enumeration 'networkAddress(4)'

dvolodin, если поменять в sa/profiles/Huawei/VRP/get_lldp_neighbors.py n = {"remote_chassis_id_subtype": 4} на n = {"remote_chassis_id_subtype": 3}

не будет ли это указанием тому что приходит от железки не get_chassis_id а mac порта

ну да

dvolodin, линки нарисовать тогда должен?

в share/mibs/LLDP-MIB.mib

ss_: погоди, я не вижу общей картины

dvolodin, http://pastebin.com/Lx8dgFdv вот она

единсвенно сейчас на 5300 {'local_interface': 'GigabitEthernet0/0/23',

'neighbors': [{'remote_capabilities': 0,

'remote_chassis_id': '00:22:56:5B:CE:85',

'remote_chassis_id_subtype': 3,

'remote_port': 'Gi 0/5',

'remote_port_subtype': 1,

'remote_system_name': 'Kan-ME3400'}]}]

'remote_chassis_id_subtype': 3

dvolodin, смотришь? Еще вопрос есть

может кто подскажет - как вот такую хрень '31-30-31-37' определить?

жаль <_4ePTeHok> редко появляется

все сбегают

)

неуловимый dvolodin

Dmitry11, может ты подскажешь

?

я не могу до сих пор с новой тушенкой разобраться.

фиг с этотой тушенко

й

Часть функциональности попросту отсутствует, или непонятно как делать

скажи почему линк не рисует

Нет данных

С обеих сторон должны бвть данные

http://pastebin.com/Lx8dgFdv

вот они

ну так там разные имена интерфейсов.

как?

точнее не то

У тебя

./noc debug-script get_chassis_id Kan_ME3400   {'first_chassis_mac': '00:22:56:5B:CE:80',  'last_chassis_mac': '00:22:56:5B:CE:80'}

а MAC адрес интерфейса - 'mac': '00:22:56:5B:CE:85',

я знаю это

сделал так {'local_interface': 'GigabitEthernet0/0/23',

'neighbors': [{'remote_capabilities': 0,

'remote_chassis_id': '00:22:56:5B:CE:85',

'remote_chassis_id_subtype': 3,

'remote_port': 'Gi 0/5',

'remote_port_subtype': 1,

'remote_system_name': 'Kan-ME3400'}]}]

Судя по всему, lldp_discovery смотрит только на get_chassis_id

должен по 'remote_chassis_id_subtype': работать

и не смотрит на MAC адрес интерфейса

похоже на то

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

диапазон, конечно

пиля

{'first_chassis_mac': '00:22:56:5B:CE:80',

'last_chassis_mac': '00:22:56:5B:CE:80'}

отдал а должен был last_chassis_maс + count интерфесов

sa/profiles/Cisco/IOS/get_chassis_id.py

тем более, что в inv/discovery/jobs/lldp_discovery.py ошибка

В строке 62

потому как MAC Address - это 3-й subtype, а не 4-й

Потому оно и не работает

Dmitry11, о как, а как исправить?

<Dmitry11>, а с патчем для длинка что-то решилось?

исправь на 3.

ApmeM_Skripnik: Я не могу прогнать тесты :(

Тушенка не работает

жаль. будем ждать

Без тестов никаких коммитов в SA не делаю

Все дружно ждем dvolodin'а

Dmitry11, не нарисовал линки

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

перезапустил на обоих железках

а get_chassis_id так и отдает один мак?

да

тогда и не нарисует

get_chassis_id надо перепиливать я так понимаю

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

да.

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

т.е. диапазон. "от" и "до"

Это я и думал

а вертает не то

sa/profiles/Cisco/IOS/get_chassis_id.py сдесь видно что для 4000/4500 7600 и прочего диапазон

По идее оно смотрит и MAC адреса интерфейсов. Но, опять же повторюсь, из-за бага в lldp_discovery.py оно не работает

Dmitry11: а что с тестами? у меня одна проблема - заливка их в репо, а локально - работает: ./noc test --beef-filter=Zyxel.ZyNOS noc.stop

как-то так, например

точно работает?

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

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

У меня %./noc test --beef-filter=DLink.DxS noc.stop

начал какого-то тестировать прпофиль Dlink.DxS_Cisco_CLI

Dmitry11, баг исправляется 3: self.get_remote_port_by_mac, # macAddress(3)

так?

Dmitry11: ну так он тоже под фильтр попадает, получается так

ss_: по идее так

попробуй так, например: ./noc test --beef-filter=DLink.DxS.get_chassis_id noc.stop

DLink.DxS.get_chassis_id проходит

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

ну да... надо посмотреть, может фильтр регэкспы умеет

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

о, вот так: ./noc test --beef-filter=DLink.DxS. noc.stop

$%^$^%

Все дружно ждем dvolodin'а

таки да, я поторопился... есть там баги с тестами, так что ждём

например DLink.DxS_Cisco_CLI.get_version - у меня такое же при тесте Zyxel.ZyNOS.get_interfaces...

откуда-то там появляется u перед некоторыми строками

lexus-omsk, юникод?

да, но почему так выборочно?

точнее даже наоборот:

new_result = {'platform': 'DGS-3610-26G', 'vendor': 'DLink', 'version': '10.3(5T16),'}

old_result = {u'platform': 'DGS-3610-26G', u'vendor': 'DLink', u'version': '10.3(5T16)'}

в старой тушёнке: result={'platform': 'DGS-3610-26G', 'vendor': 'DLink', 'version': '10.3(5T16)'}

Все дружно ждем dvolodin'а

опять же для DLink.DxS, например, отрабатывают нормально тесты - в чём фокус?

Dmitry11: в последнее время наблюдается тенденция "делай сам, если хочешь, чтобы это было сделано" (ни в коем случае не наезд, просто мне так кажется)

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

и в этом есть и минусы, и свои плюсы тоже

Я могу коммитить только в часть каталогов. dvolodin хочет держать руку на пульсе

lexus-omsk, каждый творец своего нока

Когда создавался NOC, было по-моему три разработчика. Из них остался только dvolodin. Кроме него никто не знает "потроха". Я же охватил только маленький кусочек.

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

Кроме того, если смотреть http://kb.nocproject.org/display/SITE/DevTeam то вакансий очень много

Особенно нужны документописатели, потому как документация совершенно не отражает текущее состояние дел

Плюс порог вхождения очень высок

Dmitry11, что за порог вхождения?

{'first_chassis_mac': '00:22:56:5B:CE:80',

'last_chassis_mac': '00:22:56:5B:CE:90'}

cisco catalist me3400

Ну, человек должен как минимум знать python, django и т.п.

## Catalyst 2960/3560/3750/3120 on IOS SE

## Catalyst 2950 on IOS EA

##

rx_small_cat = re.compile(r"^Base ethernet MAC Address\s*:\s*(?P<id>\S+)",

re.IGNORECASE | re.MULTILINE)

rx_mac = re.compile(r"\s+Hardware is EtherSVI|Gigabit Ethernet, address is (?P<mac>\S+)", re.IGNORECASE | re.MULTILINE)

@NOCScript.match(version__regex=r"SE|EA")

def execute_small_cat(self):

v = self.cli("show version")

match = self.re_search(self.rx_small_cat, v)

first_mac = match.group("id")

#cisco new

v2 = self.cli("show int | include bia")

for l in v2.splitlines():

match = self.rx_mac.search(l)

if match:

if match.group("mac")!= first_mac:

last_mac = match.group("mac")

if not last_mac:

last_mac = first_mac

return {

"first_chassis_mac": first_mac,

"last_chassis_mac": last_mac

}

Dmitry11, джанго не умею) питон на поверхносном уровен

Cisco.IOS.get_chassis_id выдает маки все от железа и последний от интерфейса

я не уверен, что нужно мучать get_chassis_id. Оно само достает информацию из get_interfaces. get_chassis_id сделан для тех профилей, которые не умеют выдавать MAC адреса на интерфейсах

Но это нужно уточнить у dvolodin'а

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

Все дружно ждем dvolodin'а

толку уже спрашивал

с каталисты 2950 {'first_chassis_mac': '00:12:D9:40:B5:40',

'last_chassis_mac': '00:12:D9:40:B5:5A'}

Dmitry11, ну, я не знаю ни питона (хоть и написал на нем штук пять скиптов под свои нужды), ни джанги, это не мешает пользоваться ноком

каталист сам выдает свои MAC адреса

Вот пример вывода шеститонника

6509_switch#show catalyst6000 chassis-mac-addresses

chassis MAC addresses: 1024 addresses from 0005.7497.4900 to 0005.7497.4cff

Dmitry11, 2950 3400 нет

там нет такой команды

можно так посмотреть на них show int | include bia

Логика выдачи MAC адресов у других вендоров может быть совсем другой

другие и не трогаем

только каталисты

У тех же роутеров совсем другой алгоритм выдаси MAC адресов. Поэтому забей на get_chassis_id

Оно должно смтреть MAC адреса на интерфейсах

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

а не рисует

2 день уже бъюсь

дебаг дать?

./noc debug-script get_lldp_neighbors S5300_ATS-CATS_SW1 {'local_interface': 'GigabitEthernet0/0/23',

'neighbors': [{'remote_capabilities': 0,

'remote_chassis_id': '00:22:56:5B:CE:85',

'remote_chassis_id_subtype': 4,

'remote_port': 'Gi 0/5',

'remote_port_subtype': 1,

'remote_system_name': 'Kan-ME3400'}]}]

у 'Kan-ME3400' в базе есть интерфейс Gi 0/5?

я болван

<mikevlz>, если в базе у subinterfaces имеется значение ifindex оно должно отображаться в веб-е?

Kan-ME3400 в ноке был записан как Kan_ME3400

не уверен, но врядли это существенно

вообщем линков так и нет

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

))) ждем mikevlz, может он что интересного скажет.

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

вообщем я сдаюсь

а хотел еще джинипер

ss_: хотя вроде в lldp_discovery.py все правильно

3: self.get_remote_port_by_mac, # macAddress(3)

4: self.get_neighbor_by_mac, # macAddress(4)

5: self.get_remote_port_by_name, # interfaceName(5)

7: self.get_remote_port_by_name # local(7)

так сделал

mikevlz, подсобишь?

вопрошай

ss_. у себя тоже нашел пару железок которые не не находят линки между собой. хотя с другими соседями все в порядке. в частности длинк 3200 и еджкор 3510

щаз на пастебин вывод запилю чтоб чат не засирать

и такая же ситуация как у тебя. вроде все нормально а не работает.

вот и думаю, может тут remote_port_subtype, remote_chassis_id_subtype, remote_capabilities как-то замешаны?

не находит линк между парой железок?

ApmeM_Skripnik, тут особая магия

под парой подразумевается железка и сосед

from noc.inv.models.pendinglinkcheck import *

o1 = PendingLinkCheck.objects.filter(local_object="id первого объекта")

o2 = PendingLinkCheck.objects.filter(local_object="id второго объекта")

o1,o2

mikevlz, http://pastebin.com/xG7MynGK если нужно еще что напиши

ss_: 2 линка между ними?

mikevlz, да

"id первого объекта как узнать то?

а все в веб морде по ссылкам нашел

ну например, так...

>>> o1 = PendingLinkCheck.objects.filter(local_object="14")

>>> o2 = PendingLinkCheck.objects.filter(local_object="712")

>>> o1,o2

([], [])

нифига в базу не добавило?

mikevlz, непойму

может просто как то не так работает?

o1,o2 либо там масив

о1 и о2 массивы, т.к. используется фильтр

>>> o2.count()

0

эт нормально

тогда смотри логи дискавери. Оно пишет, что и как происходит...

o1 = PendingLinkCheck.objects.all()

>>> o1

[<PendingLinkCheck: lldp:S5300_ATS-CATS_SW1:GigabitEthernet0/0/22:Kan-ME3400:Gi 0/10>, <PendingLinkCheck: lldp:S5300_ATS-CATS_SW1:GigabitEthernet0/0/23:Kan-ME3400:Gi 0/5>]

mikevlz, что это значит?

это значит, что в базе есть две записи. Первая запись - о линке по lldp от S5300_ATS-CATS_SW1 с порта GigabitEthernet0/0/22 до Kan-ME3400 в порт Gi 0/10

во всей базе всего два линка?

на карте нет этих линков

второе - по аналогии расшифруй. проблема в том, что скорее всего интерфейсы S5300_ATS-CATS_SW1 в базе имеют не такие имена

это еще не линки. Это кандидаты

а

mikevlz, подскажи как через шел найти

в вебе имена совпадают

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

почитай в блогах, я общий ход дискавери линков расписывал

Т.е. две панели. На них два устройства

mikevlz, пруф?

для каждого из этих устройств пишется, по каким критериям выбрало "соседа"

Чтобы можно было посмотреть

http://kb.nocproject.org/pages/viewpage.action?pageId=7766259

Dmitry11: NOC-949

осталось полирнуть и закоммитить

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

ну как-то так

т.е. выбираем две железки, по порту на них. И смотрим, что на discovery говорит для этих портов

по сути это морда к Pending Link Check "подтвердить этот линк"

нет

вручную залинковать можно из инвентори

mikevlz, я читал блог

в Inventory->Interfaces у ME3400 name Gi 0/xx

Inventory->Interfaces у S5300 name GigabitEthernet0/0/xx

не уловимый)))

трудноуловимый

dvolodin, можут ты можешь?

dvolodin, http://pastebin.com/xG7MynGK

чего я можут?

>>> from noc.inv.models.pendinglinkcheck import *

>>> o1 = PendingLinkCheck.objects.all()

>>> o1

[<PendingLinkCheck: lldp:S5300_ATS-CATS_SW1:GigabitEthernet0/0/22:Kan-ME3400:Gi 0/10>, <PendingLinkCheck: lldp:S5300_ATS-CATS_SW1:GigabitEthernet0/0/23:Kan-ME3400:Gi 0/5>]

>>>

чтож линк то не рисует?

dvolodin, mikevlz log http://pastebin.com/7uFz77cb

и?

2013-02-21 16:18:54,843 [inv.discovery: lldp_discovery(S5300_ATS-CATS_SW1)] Link candidate found: GigabitEthernet0/0/23 -> Kan-ME3400:None

ну что ему не хватает?

mikevlz, NOC-949 как запусить и куда ставить? В коерь распаковывать?

в inv/apps распаковать, постапдейт. рефрешнуть веб-морду

Traceback (most recent call last):

File "manage.py", line 34, in <module>

import noc.urls

File "/opt/noc/urls.py", line 15, in <module>

site.autodiscover()

File "/opt/noc/lib/app/site.py", line 447, in autodiscover

{}, {}, "*")

File "/opt/noc/inv/apps/pendinglink/views.py", line 16, in <module>

class PendingLinkCheckApplication(ExtDocApplication):

File "/opt/noc/inv/apps/pendinglink/views.py", line 22, in PendingLinkCheckApplication

model = PendingLinkCheck

NameError: name 'PendingLinkCheck' is not defined

post-update: : sync-perm failed

Terminating

mikevlz, что не так?

раскомментируй там импорт PendingLinkCheck

в views.py

Traceback (most recent call last):

File "manage.py", line 34, in <module>

import noc.urls

File "/opt/noc/urls.py", line 15, in <module>

site.autodiscover()

File "/opt/noc/lib/app/site.py", line 447, in autodiscover

{}, {}, "*")

File "/opt/noc/inv/apps/pendinglink/views.py", line 12, in <module>

from noc.inv.models import PendingLinkCheck

ImportError: cannot import name PendingLinkCheck

закомментируй назад =)

NameError: name 'PendingLinkCheck' is not defined

post-update: : sync-perm failed

пиля ромашка)

эт понятно....

в inv/models/__init__.py есть импорт этой модели?

## Python modules

import re

import datetime

## NOC modules

from noc.lib.nosql import *

from noc.sa.models import ManagedObject, ManagedObjectSelector

нет

добавь туда from noc.inv.models.pendinglinkcheck import PendingLinkCheck

Дима наверное смотрит на это и тихо негодует %)

mikevlz, отчего?

прошло

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

mikevlz, что с ними?

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

знаю, не раз уже делал так)

ну тогда я спокоен

2013-02-23 16:46:49.582000

Kan-ME3400

S5300_ATS-CATS_SW1

GigabitEthernet0/0/23

lldp

local interface пустой

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

mikevlz, [<PendingLinkCheck: lldp:Kan-ME3400:None:S5300_ATS-CATS_SW1:GigabitEthernet0/0/22>, <PendingLinkCheck: lldp:Kan-ME3400:None:S5300_ATS-CATS_SW1:GigabitEthernet0/0/23>] Тут в сторону хуявея или циски копать?

в сторону МЕ3400. У нее же нет интерфейса?

mikevlz, дебаг говорит есть

{'local_interface': 'Gi 0/5',

'neighbors': [{'remote_capabilities': 4,

'remote_chassis_id': '00:25:9E:98:14:20',

'remote_chassis_id_subtype': 4,

'remote_port': 'GigabitEthernet0/0/23',

'remote_port_subtype': 5,

'remote_system_name': 'S5300_ATS-CATS_SW1'}]},

{'local_interface': 'GigabitEthernet0/0/23',

'neighbors': [{'remote_capabilities': 0,

'remote_chassis_id': '00:22:56:5B:CE:85',

'remote_chassis_id_subtype': 4,

'remote_port': 'Gi 0/5',

'remote_port_subtype': 1,

'remote_system_name': 'Kan-ME3400'}]}]

'remote_port_subtype': 1

'remote_port_subtype': 5,

не в этом вся проблема?

хз

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

пиля, шли вторые сутки

руками бы быстрее прописал

zi_rus, руками не итнересно

еееееее

ура ЗАРАБОТАЛООООО

ss_: в этом

def get_remote_port(self, object, remote_port, remote_port_subtype):

f = {

3: self.get_remote_port_by_mac, # macAddress(3)

5: self.get_remote_port_by_name, # interfaceName(5)

7: self.get_remote_port_by_name # local(7)

}.get(remote_port_subtype)

Нигде нету упоминания про 'remote_port_subtype': 1

Dmitry11, уже понял

но сиська отдает GigabitEthernet0/0/23 has 1 neighbors:

Neighbor index : 1

Chassis type :macAddress

Chassis ID :0022-565b-ce85

Port ID type :interfaceAlias

Port ID type :interfaceAlias

interfaceAlias

сделал так n["remote_port_subtype"] = {

"interfaceAlias": 5,

"macAddress": 3,

"interfaceName": 5,

"local": 7

иначе валилось lldp на s5300 при обнаружении линка

линка с циской

ну еще одну строку добавь

чтоб 1-ку определяло как имя порта

mikevlz, эм

пример

Надо править не циску, а lldp_discovery.py

сам добавил InterfaceName,

еще одну фигню добавь, чтоб индекс имела 1

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

get_lldp_neighbors костыль на костыле

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

в том то и дело

там еще знаешь что сделал? #FOR CISCO

n["remote_system_name"] = n["remote_system_name"].replace(".cisco.com","")

n["remote_port"] = n["remote_port"].replace("Gi0","Gi 0")

#END CISCO

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

незнаю нужно сейчас илин нет

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

сделай еще один тип remote_port_subtype, который будет соответствовать единице

в инвентори-интерфейсы щелкни по значку Линк - оно разлинкует

mikevlz, "ТУТ ЧТО ПИСАТЬ НЕЗНАЮ": 1,

NOC-883 тут потом исправлю

будем пилить джинимер/алкатель

следуюущие

там index порта возвращается

mikevlz, "ТУТ ЧТО ПИСАТЬ НЕЗНАЮ": 1,

все без костылей находит

Dmitry11: как ты увидишь причину?

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

почему не обнаружился линк между X и Y

:)

постанова нормальна

два окна. В каждом - железка

Выбираем в каждом окне интерфейс

Смотрим, по каким критериям NOC может создать линк.

Т.е. куски скриптов get_spannong_tree, get_lldp_neighbors и т.п., что именно относится к выбранным интерфейсам

mikevlz, fe

вот и убежал dvolodin

Dmitry11, поможещь допилить huawei + cisco?

линки рисовать

не помогу

почему?

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

без тушенки я править скрипты не буду

Уже осталось всего пара вещей, мешающих нормальной работе с тушенкой

Вроде уже почти все победил

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

Dmitry11, get_chassis_id необходим для дисковери?

на juniper его далать как то не логично

не логично

да

get_chassis_id используется в основном для свичей

Dmitry11, а он необходим для построения карт?

да

пиля

но для свичей

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

т.е. тех железяк, которые не умеют gat_interfaces и т.п.

по MAC, ARP, LLDP

ээээээ

не вводи в заблуждение

LLDP в общемсделал но есть нюанс

mikevlz, ?

get_discovery_id нужен для того чтоб собрать таблицу соответствия MO <-> chassis_id/topology_id

свич или не свич - ему пофигу

в тех джобах, что я смотрел, remote_object определяется исключительно через discovry_id

Надо dvolodin'а сюда выдернуть хотя-бы на пол-дня

а стоп

кажись я гоню

разговор про chassis_id

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

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

играет роль, для поиска по MAC или LLDP, когда на другом конце линка свич 2-го уровня

mikevlz, Dmitry11 какие скрипты нужны для рисования линков по lldp на juniper

get_interfaces и get_lldp_neighbors

Если удаленное устройство - свич 2-го уровня, то get_chassis_id

И get_mac_addresss_table на удаленном свиче и get_arp на juniper

удаленное устройство S5300 хуявей

Поэтому я и говорю, надо приложение, которое покажет, какие скрипты отработали, и что выдали

get_discovery_id требует скрипты get_fqdn и get_chassis_id

хотябы один из двух

get_chassis_id ээ как бы его на juniper замутить?

открой кошкин скрипт и посмори

копипаста рулит

будь индусом :)

mikevlz|3, я на джинипере команд мало знаю) какую вводиь чтоб маки увидить на интерфейсах?

у меня нет джуниперов

show interfaces xe* | match "Hardware address"

вместо xe можно писать любые

вот пример

{master}

km@jnr01-yla-pet> show interfaces * | match "Hardware address"

Current address: 78:19:f7:07:26:72, Hardware address: 78:19:f7:07:26:72

Current address: 78:19:f7:07:26:73, Hardware address: 78:19:f7:07:26:73

Current address: 78:19:f7:07:26:74, Hardware address: 78:19:f7:07:26:74

Current address: 78:19:f7:07:26:75, Hardware address: 78:19:f7:07:26:75

Current address: 78:19:f7:07:26:76, Hardware address: 78:19:f7:07:26:76

ufir, а маки не попорядку

Current address: 5c:5e:ab:08:10:90, Hardware address: 5c:5e:ab:08:10:90

Current address: 5c:5e:ab:08:10:a8, Hardware address: 5c:5e:ab:08:10:a8

Current address: 5c:5e:ab:08:10:11, Hardware address: 5c:5e:ab:08:10:11

да..

а это обязательно ?

ну в get_chassis_id вроде диапазон

или можно как то по другому?

а задача-то какая - получить список сортированных маков ?

нет диапазон маков принадлежащих железке

km@jnr01-yla-pet> show chassis mac-addresses

MAC address information:

Public base address 78:19:f7:07:20:00

Public count 1984

Private base address 78:19:f7:07:27:c0

Private count 64

о

круто

это на MX480

на других МХ должно быть так же

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

надо скрипт запилить)

начало есть

надо распарсить

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

(С) КО

В той же OS.FreeBSD, если всунуть карточки разных вендоров

Поэтому get_chassis_id только для свичей L2

Dmitry11, лучше скажи ка прибавить к 78:19:f7:07:20:00 + 1984

А для L2+ и выше - get_interfaces

ss_: get_interfaces используй

Dmitry11, есть он

работает

тогда зачем тебе get_chassis_id ?

Dmitry11, линк не рисуется

Значит нужно понять, почему он не рисуется

кто бы помог

я знаю одно, что джинипер отдает линк хитро

<S5300_ATS-CATS_SW2>dis lldp neighbor interface XGigabitEthernet 0/1/1

XGigabitEthernet0/1/1 has 1 neighbors:

Neighbor index : 1

Chassis type :macAddress

Chassis ID :5c5e-ab08-10c0

Port ID type :local

Port ID :511

Port description :Huawei_S5300_AG6

System name :MX80_Kanash

System description :Juniper Networks, Inc. mx80 , version 10.4R7.5 Build date: 2011-09-08 06:06:42 UTC

System capabilities supported :bridge router

System capabilities enabled :bridge router

Expired time :112s

Port ID Port ID type

это его так с 5300 видно

а у тебя на huawei есть порт 511 ?

нет

ой. На Juniper

это порт джинипер это индекс

Dmitry11: чтоб джоб понял, кто у него на другом конце сидит, он должен отрезолвить соседа по маку. Поэтому на джуне надо get_chassis_id

X80_Kanash> show interfaces xe-0/0/3

Physical interface: xe-0/0/3, Enabled, Physical link is Up

Interface index: 145, SNMP ifIndex: 511

Description: Huawei_S5300_AG6

ifIndex: 511

О!

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

mikevlz|2, говорит но линк не строит

это MAC не шасси, а интерфейса

Dmitry11, значит надо чтоб все маки интерфейсов были chassis_id?

19:09:14] <ss_> Chassis type :macAddress

[19:09:14] <ss_> Chassis ID :5c5e-ab08-10c0

А Juniper.GUNOS.get_interfaces выдает "snmp_ifindex"

Всего-то надо по этому ifindex найти интерфейс

\хе

нифига

джоб должен сначала узнать кто сосед в базе МО

Что, кстати, сделано в fm/classifier/__init__.py в функции fixup_ifindex()

джоб сделает поиск в базе DiscoverId по маку, нифига не найдет

MAC должен вернуть get_interfaces

потому что нет get_chassis_id для джунипера

ёпт

почитай код джоба

Т.е. искать не только по MAC адресам get_chassis_id, но и по MAC адресам, возвращаемым get_interfaces

lldp_discovery

Так это не ко мне, а к dvolodin'у

затык будет именно на поиске remote_object

в базу ни одного каднидадта не попало

не найдется remote_object - не будет кандидата. Нет кандидата - нет линка

Я ему в личке уже написал, чтобы он исправил lldp_discovery

до поиска интерфейса не дойдет

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

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

Как минимум 4 issue по lldp_discovery

Dmitry11, рядом с 62 строкой # Find by id

f = {

3: self.get_neighbor_by_mac, # macAddress(3)

4: self.get_neighbor_by_mac, # macAddress(4)

5: self.get_neighbor_by_ip, # networkAddress(5)

7: self.get_neighbor_by_local # local(7)

}.get(chassis_subtype)

File: inv/discovery/jobs/lldp_discovery.py

Нет. Не то

Жто я ложанулся

Надо добавить в get_remote_port(self, object, remote_port, remote_port_subtype):

1: self.get_remote_port_by_name, # interfaceAlias(1)

ёпт

НЕ ДОЙДЕТ до порта

А в функцию et_remote_port_by_name() вызов fixup_ifindex(), имя интерфейса - число больше тысячи

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

А для этого lldp_discovery должна искать MAC адрес не только те, которые возвращаются get_chassis_id, но и те, которые возвращаются get_interfaces

Dmitry11, get_remote_port_by_name() где?

inv/discovery/jobs/lldp_discovery.py

ss_: link_discovery.py еще посмотри. Там тоже функции есть веселые

Dmitry11, def get_remote_port_by_name(self, object, port):

return object.profile.convert_interface_name(port)

не пойму как добавить

Dmitry11: убедил

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

вон, HaLVeR-а надо озадачить

ss_: if int(port) > 1001:

Dmitry11, джунипер с 500 отдает

def get_remote_port_by_name(self, object, port):

if int(port) > 501: ###NEW

fixup_ifindex()

return object.profile.convert_interface_name(port)

так?

значит нужно workaround делать для железок. Т.е. костыль в lldp_discovery.py

типа так. Но не заработает. там еще нужно импортировать нужные классы

Dmitry11, подскажи какие

поробуем

скоро на работе жить буду )))

Если мы узнали, что за железкак у нас на другом конце, то мы знаем ее профиль SA, соответственно можем конвертить интерфейс, как нам вздумается

ss_: Завтра попробую достучаться до dvolodin'а

Dmitry11, скажи хотябы про классы какие подгрузить

да я не знаю сам

Dmitry11, лог дискавери посмотреть хочешь?

я в нем ничего не понимаю

2013-02-21 19:39:16,795 [inv.discovery] Running job lldp_discovery(MX80_Kanash)

2013-02-21 19:39:19,497 [inv.discovery: lldp_discovery(MX80_Kanash)] get_neighbor(00:25:9E:97:CF:18, 4) -> S5300_ATS-VOST_SW1

object = <ManagedObject: MX80_Kanash>

'remote_system_name': 'S5300_ATS-CATS_SW2'}]}]

object = <ManagedObject: MX80_Kanash>

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

'remote_system_name': 'S5300_ATS-CATS_SW2'}]}]

{'object': <ManagedObject: MX80_Kanash>,

'remote_system_name': 'S5300_ATS-CATS_SW2'}]}]}

2013-02-21 19:36:27,202 [inv.discovery: lldp_discovery(MX80_Kanash)] get_neighbor(00:25:9E:97:CF:18, 4) -> S5300_ATS-VOST_SW1

object = <ManagedObject: MX80_Kanash>

'remote_system_name': 'S5300_ATS-CATS_SW2'}]}]

object = <ManagedObject: MX80_Kanash>

'remote_system_name': 'S5300_ATS-CATS_SW2'}]}]

{'object': <ManagedObject: MX80_Kanash>,

'remote_system_name': 'S5300_ATS-CATS_SW2'}]}]}

2013-02-21 19:33:10,476 [inv.discovery: lldp_discovery(S5300_ATS-CATS_SW2)] get_neighbor(4C:B1:6C:34:7C:44, 4) -> 33-30LetPob27p2

object = <ManagedObject: S5300_ATS-CATS_SW2>

'remote_system_name': 'MX80_Kanash'}]}]

object = <ManagedObject: S5300_ATS-CATS_SW2>

'remote_system_name': 'MX80_Kanash'}]}]

{'object': <ManagedObject: S5300_ATS-CATS_SW2>,

'remote_system_name': 'MX80_Kanash'}]}]}

Dmitry11, т.е. они вроде как видят друг друга но каких то условий не хватает

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

Надо

домой

привет.

есть кто?