Отрисовка топологии сети из коммутаторов.

[onspeed83]

Всем привет.

Первый раз пишу здесь, потому не судите строго.

Хочу поделиться своим проектом, который позволяет автоматически рисовать топологии сетей доступа (посредством опроса железок по SNMP или telnet), которые состоят из коммутаторов доступа и узла агрегации.

 

Ссыль на ютуб. Видео на 5 минут.

 

Кто посмотрит, прошу того прокомментировать проект.

На сколько данный вопрос актуальный и есть ли в этом мире :) подобные решения.

[snvoronkov]

https://en.wikipedia.org/wiki/HP_OpenView

[LostSoul]

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

 

[onspeed83]

есть. длинквью. но оно не всеядное. а опенвью тоже может сама сканировать железо и строить топологию сети?

[snvoronkov]

2 минуты назад, onspeed83 сказал:

есть. длинквью. но оно не всеядное. а опенвью тоже может сама сканировать железо и строить топологию сети?

Сейчас -х/з. Лет 10-15 назад - точно умела. Причем на жутком миксе железа.

[sergiusk]

я писал на perl
Визуализация топологии сети используя протоколы LLDP - Topology Discovery

http://forum.dlink.ru/viewtopic.php?f=2&t=156053
 

Edited March 4, 2019 by sergiusk

[Sacrament]

Прикольная штука, но как пощупать то можно?)

[pppoetest]

9 часов назад, onspeed83 сказал:

подобные решения.

Или покупают готовое и допиливают, либо изначально пилят сами. Мы сами напилили на perl+php.

[Veroncheg]

Есть такая софтина, LanTopolog называется

[s.lobanov]

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

 

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

 

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

[onspeed83]

да. именно этим мы сейчас и занимаемся. создание общей базы топологий сетей и их анализ.

по поводу LLDP - условно, у нас есть 15-20к железок, среди которых процентов 30 не умеют этот протокол. так что он автоматически отпадает.

по поводу LanTopolog . видел я этот софт, но он мне не понравился и я вот только сейчас понял по какой причине. он ОООООЧЕНЬ долго рисует топологию.

взял я своих два свичтика, на которых настроено VPU (vlan-per-user). скан этих свитчей занял около 5 минут. сначала он вытянул арп-таблицу, потом маки, потом порты, потом валны, потом еще хз что и выдал на гора мне картинку... два свитча за 5 минут) все это дело смотрел акулой. задумка у софта интересная, но вот он точно не справился бы с хуавеями ls2300 и старыми цисками, т.к. первые таблицу маков отдают без привязки к портам, а вторые - не умеют по снмп это вообще делать :)

 

может еще кто-то что-то использовал в своей практике? как по мне, то данная тема очень слабо раскрыта в Инете :(

[alibek]

17 минут назад, onspeed83 сказал:

по поводу LLDP - условно, у нас есть 15-20к железок, среди которых процентов 30 не умеют этот протокол. так что он автоматически отпадает.

Странное решение.

Более правильным было бы использовать разные протоколы (LLDP, CDP и прочие *DP, а также получение таблицы MAC-адресов по telnet/ssh/snmp), а для каждой модели устройства использовать плагин/адаптер, чтобы делать это оптимальным образом.

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

[onspeed83]

меня один раз спросили, по чему я использую vim, а не, например, nano? ответ простой - я прочитал не тот мануал)) вот здесь получилось точно также. стартовал я с отрисовки коммутаторов zte2900, которые не умеют LLDP (не путать с 2900Е, которые умеют). с зте все получилось, а потом пошли длинки, которые по СНМП опрашиваются вообще прекрасно... а потом пошел зоопарк железа, который так же по СНМП опрашиватся.

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

на будущее планирую перевести проект с пхп на пайтон+многопоточность. люблю я скорость :)

[fox_m]

Visio - наше все)

 

В 05.03.2019 в 14:16, s.lobanov сказал:

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

 

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

 

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

 

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

[onspeed83]

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

[pppoetest]

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

[onspeed83]

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

[s.lobanov]

@onspeed83 значит скорее всего вы работаете в среднем или большом операторе. и пока вы не наладите нормальное взаимодействие, у вас так и будут вечные костыли (дискавери топологии вместо хранения+валидации, бэкап и ручная настройка свитчей вместо генерации и сервис-активатора, получающего запросы из биллинга и т.д.) . лучше наладьте взаимодействие с коллегами. вам же не обязательно заставлять их генерить конфиги, вам нужно просто получить доступ к их данным, возможно немного расширить набор данных, которые они хранят

[onspeed83]

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

может еще что-то есть? кто что вспомнит?

[alibek]

NOC

[ichthyandr]

В 04.03.2019 в 20:52, onspeed83 сказал:

Всем привет.

Первый раз пишу здесь, потому не судите строго.

Хочу поделиться своим проектом, который позволяет автоматически рисовать топологии сетей доступа (посредством опроса железок по SNMP или telnet), которые состоят из коммутаторов доступа и узла агрегации.

 

Ссыль на ютуб. Видео на 5 минут.

 

Кто посмотрит, прошу того прокомментировать проект.

На сколько данный вопрос актуальный и есть ли в этом мире :) подобные решения.

а зачем? У админа должна быть схема(карта) сети. Если её нет, то это максимум странно

[Telesis]

On 3/15/2019 at 10:57 AM, ichthyandr said:

а зачем? У админа должна быть схема(карта) сети. Если её нет, то это максимум странно

всё как всегда - мы строили, строили, а что же мы построили?

[smelnik]

https://www.librenms.org/

Строит карту по lldp

[ichthyandr]

В 26.03.2019 в 09:00, Telesis сказал:

всё как всегда - мы строили, строили, а что же мы построили?

это как так строить, не зная то что строишь???

[Telesis]

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