[wtyd]

Есть желание создать карту/таблицу коммутаций сети. Т.е. таблица есть, но в ней есть ошибки, т.к. её делали люди, которым очень свойственно ошибаться. В таблице есть связи, какой коммутатор с каким соединён какими портами.

 

У руководства возникла идея: написать скрипт, который бы по таблицам мас-адресов составил бы такую же таблицу коммутаций. Потом надо будет сравнить таблицы и обратить внимание на несовпадения.

 

Посоветуйте опенсорс софт для linux или хотя бы алгоритм для написания скрипта.

 

NOC не предлагать (!), он наверное хороший, но разобраться в нём это выше моих сил :-), мы его не понимаем и поэтому использовать не будем.

 

Из входных данных есть имена свичей, их ip-адреса, маки свичей, есть доступы по telnet и по snmp. Свичи в основном длинки, есть несколько цысок и совсем мало e-core с q-tech. cdp и lldp использовать нельзя.

 

P.S. Я обычно пользуюсь имеющейся таблицей, но всегда отношусь к ней с сомнением и проверяю. Попробовал руками по таблицам mac-адресов что-то построить и понял, что запрограмировать такое в скрипте у меня с ходу не получится. Т.е. без знания примерной топологии сети у меня вообще не получается составить таблицу коммутаций правильно :-).

[kamae1ka]

мы его не понимаем и поэтому использовать не будем.

ну тут сложно что-то советовать

[wtyd]

мы его не понимаем и поэтому использовать не будем.

ну тут сложно что-то советовать

 

А что, кроме NOC ничего нет ? Я совета про другое спрашивал вообще-то.

[alibek]

или хотя бы алгоритм для написания скрипта.

Алгоритм очень простой.

1. Получить с каждого коммутатора таблицу MAC-адресов.

2. Проанализировать таблицы и составить топологию соединений (на основе совпадения набора MAC-адресов).

 

cdp и lldp использовать нельзя

Напрасно.

Строить топологию по MAC-адресам очень ресурсоемко.

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

 

А что, кроме NOC ничего нет

Много чего есть (например LanTopolog).

Но советую разобраться с NOC.

[wtyd]

или хотя бы алгоритм для написания скрипта.

Алгоритм очень простой.

1. Получить с каждого коммутатора таблицу MAC-адресов.

2. Проанализировать таблицы и составить топологию соединений (на основе совпадения набора MAC-адресов).

 

cdp и lldp использовать нельзя

Напрасно.

Строить топологию по MAC-адресам очень ресурсоемко.

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

 

А что, кроме NOC ничего нет

Много чего есть (например LanTopolog).

Но советую разобраться с NOC.

 

Вот пункт 2 как раз и интересует :-). Что ресурсоёмко это понятно, но это надо делать 1 раз в месяц или вообще 1 раз, пока не решили.

 

NOC у нас есть, мы его даже использовали. Это наша самая большая и самая ресурсоёмкая виртуалка, ей всё время чего-то мало, она всё время

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

спорить на эту тему бесполезно. Вот если бы она не росла и не жрала ресурсы, то моё мнение было бы другим. Жрёт проц с ОЗУ и диском, а из реального

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

 

За lantopolog спасибо, посмотрим, хоть он и не для линукса.

[alibek]

Вот пункт 2 как раз и интересует

Там сложности только в том, как это оптимизировать и распараллелить.

А сам по себе алгоритм примитивный, нужно сравнивать на совпадение наборы MAC-адресов.

Если набор MAC-адресов на коммутаторе SW1 совпадает с набором MAC-адресов на порту #1 коммутатора SW2, значит SW1 подключен в порт #1 коммутатора SW2.

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

[Negator]

Я писал скрипт на php под это дело. Алгоритм такой-

1.пингуем все свичи чтобы таблица заполнилась.

2. Собираем все маки со всех свиичей в базу(мускуль) по snmp.

3. Работаем с базой. Отрисовки топологии graphviz.

Но все равно не совсем корректно работает. Маки свиичей не всегда есть в fdb таблицах.

[pppoetest]

php+javascript Мы так сделали.

[zhenya`]

как это не всегда?

в случае звезды все нормально строится.

[apm]

Я писал скрипт на php под это дело. Алгоритм такой-

1.пингуем все свичи чтобы таблица заполнилась.

2. Собираем все маки со всех свиичей в базу(мускуль) по snmp.

3. Работаем с базой. Отрисовки топологии graphviz.

Но все равно не совсем корректно работает. Маки свиичей не всегда есть в fdb таблицах.

 

поделитесь?

[Negator]

Нет, не поделюсь к сожалению. Он давно похерен, да и был сделан только под нашу сеть и и длинки. Но повторить несложно- основная проблема маки с номером порта собрать.

Лучше lldp использовать.

[Morbid]

python+mysql+grphviz но все данные берутся именно через LLDP.

 

А почему нельзя использовать lldp? Он ведь для этого и предназначен по сути.

[wtyd]

Нет, не поделюсь к сожалению. Он давно похерен, да и был сделан только под нашу сеть и и длинки. Но повторить несложно- основная проблема маки с номером порта собрать.

Лучше lldp использовать.

 

В Т.З. lldp нельзя юзать не потому, что он плохой, а потому что он примерно только на 60% свичей есть, ещё он отключен, ещё его нет на цысках. Так то конечно было бы клёво на lldp всё собрать.

[apm]

Дайте кто нить решение плиз под адаптацию, хочется чего то не как noc, но простенького

[Ancient]

Полно же проектов всяких, ищите и ставьте

https://sourceforge.net/projects/switchportmap/

https://sourceforge.net/projects/netdisco/

https://github.com/search?utf8=%E2%9C%93&q=network+map

[s.lobanov]

ещё его нет на цысках

 

нет его только на оооочень древних cisco. на всех актуальных моделях есть. для многих старых моделей тоже есть в обновлениях ПО

[zi_rus]

на оооочень древних cisco

древних, но не очень, 3550 его не умеет, по-моему не такой он и старый

[alibek]

На Cisco есть CDP. Он похож на LLDP и научить скрипт понимать оба протокола несложно.

Я бы советовал строить топологию по LLDP/CDP, а анализ MAC-адресов производить изредка, для поиска устройств с отключенным LLDP.

Постоянно собирать MAC-адреса со всех устройств в сети накладно во всех отношениях.

[zi_rus]

я бы сказал что lldp похож на cdp

[s.lobanov]

на оооочень древних cisco

древних, но не очень, 3550 его не умеет, по-моему не такой он и старый

 

У него end-of-sale=May 2, 2006. Ну то, что их за 10 лет не смогли убить это конечно круто

 

Да, в условиях РФ и тотального нищебродства в ISP можно весь этот хлам увидеть и сейчас - и 2950 и 3550 с этими самым gbic-ами.

Да, нужно научить скрипт и lldp и cdp. но на стыке длинка с 3550 не будет топологии, поэтому надо использовать все доступные методы, в том числе и мак-таблицу, только нужно чтобы система мониторинга постоянно пингала свитчи, чтобы мак шлюза был у всех в таблицах

[wtyd]

Хорошо, а lldp чем обрабатывать ? Разные вендоры по-разному show lldp выводят.

[alibek]

И сколько в сети разных вендоров? 4 или 5?

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

К тому же IP-адрес, MAC-адрес и номер порта можно распознать по значению с любым типом вывода, а для топологии больше ничего и не нужно.

[snvoronkov]

Да, в условиях РФ и тотального нищебродства в ISP можно весь этот хлам увидеть и сейчас - и 2950 и 3550 с этими самым gbic-ами.

Хлам? Работает - не трогай! :-)

XXXXX uptime is 2 years, 50 weeks, 1 day, 15 hours, 17 minutes

System returned to ROM by power-on

System restarted at 04:21:04 YEKT Mon Nov 18 2013

System image file is "flash:/c2950-i6q4l2-mz.121-22.EA6.bin"

 

cisco WS-C2950T-24 (RC32300) processor (revision R0) with 21013K bytes of memory.

[s.lobanov]

Хорошо, а lldp чем обрабатывать ? Разные вендоры по-разному show lldp выводят.

 

По snmp LLDP-MIB более-менее похож у разичных вендоров