Комментарии 13
За пример работы с Next UI спасибо. Я наверное за вас голосовал в devnet cisco :) Но сама задача, построения схемы на основе cdp/lldp мне кажется немного не нужной. Я когда-то тоже написал скрипт, который на основе cdp строил схему, правда на основе Graphviz, получалось не так красиво, как c использованием Next UI. Но проблема, что я им практически не пользовался, задачка больше игровая, чем для применения в реальности. Дело в том, что для enterprise это не нужно, а нужен хороший источник sourth of truth, типа netbox или другой откуда брать информацию о линках и проверять их на правильность, используя похожий как увас скрипт. И должны быть схемы всей сети, нормальные, детальные с различными срезами и уровнями. Для интегратора тоже не особо нужен данный инструментарий, так как не всегда возможно запустить lldp/cdp у заказчика, а если и получается, то это присылается ввиде текстовых файлов, которые я обрабатываю и создаю на основе их excel/csv таблицы для анализа, если же строить схемы, иногда получается слишком много соединений и все это трудно анализировать на схеме, в табличном виде лучше. У меня есть другой скрипт(не совсем доработанный), который строит логическую схему сети третьего уровня, она более сложная задачка сама по себе, но им я пользуюсь более часто, так как иногда присылают конфиги и их нужно проанализировать и я пытаюсь их пропустить через скрипт, для быстрого построения логической схемы третьего уровня, но только в том случае, если у заказчика нет нормальных схем своей сети.
Но сама задача, построения схемы на основе cdp/lldp мне кажется немного не нужной.
иногда получается слишком много соединений и все это трудно анализировать на схеме, в табличном виде лучшеКак и всегда, не существует универсальных решений. Инструменты хороши в совокупности, и схемы с таблицами обычно дополняют друг друга. LLPD/CDP же дает базовое понимание топологии, поверх него уже можно накладывать дополнительные слои, обогащать схему деталями по потребностям и визуализировать более сложные кейсы (например, визуализацию путей из моей прошлой статьи).
Для случаев с большим количеством линков и нод в NeXt UI, кстати, есть хороший функционал Node Sets (наборы нод), с помощью него можно группировать отдельные ноды и сворачивать их в одну пиктограмму (и разворачивать по клику) при визуализации.
нужен хороший источник sourth of truth, типа netbox или другой откуда брать информацию о линках и проверять их на правильность, используя похожий как увас скрипт. И должны быть схемы всей сети, нормальные, детальные с различными срезами и уровнями.С необходимостью SoT в той или иной реализации полностью согласен. И идею с визуализацией можно развить и в этой плоскости, формируя объект топологии на основании связей и данных в Netbox, доставаемых через API. Экспериментами в этом направлении, скорее всего, и займусь. Если сообществу будет интересно, может, опубликую отдельную статью.
С учетом того, что у Netbox открытый код, можно даже интегрировать вкладку с визуализацией напрямую в его интерфейс (например, в /dcim/sites/$site_slug).
У меня есть другой скрипт(не совсем доработанный), который строит логическую схему сети третьего уровня, она более сложная задачка сама по себе, но им я пользуюсь более частоБыло бы интересно почитать статью с описанием подобного опыта. :)
идею с визуализацией можно развить и в этой плоскости, формируя объект топологии на основании связей и данных в Netbox, доставаемых через API. Экспериментами в этом направлении, скорее всего, и займусь.В результате экспериментов в свободное время родилась бета-версия плагина для интеграции топологий напрямую в Netbox (функционал плагинов добавили недавно в версии 2.8.0).
Код выложил на GitHub, если кого-то заинтересует.
Lldp + snmp.
На практике лично мне пришлось делать модули, которые собирают lldp, всякие проприетарные протоколы (cdp, edp итд), fdb таблицу в влане управления и даже stp. Причём не только по snmp, что-то приходится забирать по ssh и даже по telnet. Каждый модуль пишет собранные данные в отдельную для каждого способа/протокола табличку в постгресе. Таблички регулярно (несколько раз в минуту) обрабатывает сервис на Go, формирует топологию, определяет её разницу с текущей и апдейтит итоговую таблицу связности.
И вот только в таком виде топология для мультивендорной сети становится практически полностью известной. Ну и можно исторические данные сохранять бонусом — иногда полезно в прошлое посмотреть.
Работаю в крупном энтерпрайзе, сеть мультивендорная (cisco, juniper, huawei, moxa, d-link).
Остро стоит вопрос автоматизации построения топологии и формирования так называемого sourth of truth.
В качестве Source-of-Truth могу посоветовать присмотреться к NetBox. В нем уже имеется необходимый для подобных задач набор абстракций и моделей данных (Devices, Interfaces, Cables и т.п.), хороший API, чтобы эти данные положить и достать, и широкие возможности для расширения, если нужно что-то нестандартное. Есть хорошая документация, статьи, видео и сложившееся комьюнити (в том числе русскоязычное).
А из основы решения из этой статьи как раз родился плагин NextBox-UI для визуализации топологий в NetBox.
Для корпоративных доменных сетей минимально можно смотреть MAC-адреса на портах, по ним из ARP узнавать IP-адреса, а из IP-адресов пытаться ресолвить хостнеймы.
При внедренном 802.1x предсказуемость результата становится уже выше. И так с каждым дополнительным источником информации об устройствах.
Спасибо, а D-link так же можно?
Визуализация сетевых топологий, или зачем еще сетевому инженеру Python #2