Спасибо за обратную связь.
Да, развивать плагин планирую. Но в последний месяц брал небольшую паузу ото всех сайд-проектов. :) Issue на ГитХабе относительно совместимости с NB 2.11 уже есть. Буквально только что выпустил новый релиз для фикса – доступен в исходниках и на PyPi.
В качестве Source-of-Truth могу посоветовать присмотреться к NetBox. В нем уже имеется необходимый для подобных задач набор абстракций и моделей данных (Devices, Interfaces, Cables и т.п.), хороший API, чтобы эти данные положить и достать, и широкие возможности для расширения, если нужно что-то нестандартное. Есть хорошая документация, статьи, видео и сложившееся комьюнити (в том числе русскоязычное).
А из основы решения из этой статьи как раз родился плагин NextBox-UI для визуализации топологий в NetBox.
С мая 2020 тоже использую похожий стек для написания и перевода своих статей: VSCode + Markdown + git + минорные итоговые правки в старом Хабраредакторе. Было удобно.
Спасибо, кстати, за наводку на Grammarly-плагин для VSCode. :)
Присоединяюсь к пожеланиям и комментариям выше: обратная связь для участников, не вошедших в число победителей, и список финалистов были бы полезны и наглядны. Иначе результат участия выходит бинарным — победил или нет.
идею с визуализацией можно развить и в этой плоскости, формируя объект топологии на основании связей и данных в Netbox, доставаемых через API. Экспериментами в этом направлении, скорее всего, и займусь.
В результате экспериментов в свободное время родилась бета-версия плагина для интеграции топологий напрямую в Netbox (функционал плагинов добавили недавно в версии 2.8.0).
Код выложил на GitHub, если кого-то заинтересует.
Это сильно зависит от применяемых на доступе технологий, типов клиентских устройств и т.д.
Для корпоративных доменных сетей минимально можно смотреть MAC-адреса на портах, по ним из ARP узнавать IP-адреса, а из IP-адресов пытаться ресолвить хостнеймы.
При внедренном 802.1x предсказуемость результата становится уже выше. И так с каждым дополнительным источником информации об устройствах.
Но сама задача, построения схемы на основе cdp/lldp мне кажется немного не нужной.
иногда получается слишком много соединений и все это трудно анализировать на схеме, в табличном виде лучше
Как и всегда, не существует универсальных решений. Инструменты хороши в совокупности, и схемы с таблицами обычно дополняют друг друга. LLPD/CDP же дает базовое понимание топологии, поверх него уже можно накладывать дополнительные слои, обогащать схему деталями по потребностям и визуализировать более сложные кейсы (например, визуализацию путей из моей прошлой статьи).
Для случаев с большим количеством линков и нод в NeXt UI, кстати, есть хороший функционал Node Sets (наборы нод), с помощью него можно группировать отдельные ноды и сворачивать их в одну пиктограмму (и разворачивать по клику) при визуализации.
нужен хороший источник sourth of truth, типа netbox или другой откуда брать информацию о линках и проверять их на правильность, используя похожий как увас скрипт. И должны быть схемы всей сети, нормальные, детальные с различными срезами и уровнями.
С необходимостью SoT в той или иной реализации полностью согласен. И идею с визуализацией можно развить и в этой плоскости, формируя объект топологии на основании связей и данных в Netbox, доставаемых через API. Экспериментами в этом направлении, скорее всего, и займусь. Если сообществу будет интересно, может, опубликую отдельную статью.
С учетом того, что у Netbox открытый код, можно даже интегрировать вкладку с визуализацией напрямую в его интерфейс (например, в /dcim/sites/$site_slug).
У меня есть другой скрипт(не совсем доработанный), который строит логическую схему сети третьего уровня, она более сложная задачка сама по себе, но им я пользуюсь более часто
Было бы интересно почитать статью с описанием подобного опыта. :)
Интересный опыт, спасибо.
И еще пара вопросов, если возможно.
Это netmiko, это pysnmp, это jinja2 и etc.
1. А Nornir не доводилось использовать? Не так давно для себя его обнаружил, выглядит многообещающе. Это дополнительная абстракция над netmiko и napalm с инвентори и мультитредингом.
2. Какой подход к безопасному хранению учеток/паролей и их импорту в скрипты используете в сетевой автоматизации?
Схема оклад+премия (квартальная, годовая) по собственному опыту и опыту знакомых практикуется многими крупными энтерпрайзами и телекомами. В особенности, на лидствующих и начальствующих позициях.
karaboz В этом случае сейчас следует указывать годовой доход, делённый на 12?
Было бы полезно сделать опцию с возможностью указания годового дохода (и окладной части по желанию).
Я ответил, что в данном примере разницы нет и оба True и даже попытался объяснить ему почему Python не C/C++.
Не могли бы раскрыть свою мысль и направить в документацию в правильном направлении?
На мой, не специализирующийся на Python, взгляд, вопрос имеет под собой почву:
a == b # сравнение по значению
a is b # сравнение по object id, на который ссылаются переменные
И в случае с мутабельными объектами разница может быть:
a = [1, 2, 3]
b = a # произойдет присвоение по ссылке
с = a.copy() # произойдет присвоение по значению
d = a[:] # произойдет присвоение по значению
# Значения всех трех переменных равны:
a == b # True
a == c # True
a == d # True
# Но переменные a и b ссылаются на один и тот же объект списка:
b is a # True
# А переменные c и d ссылаются на отдельные объекты:
c is a # False
d is a # False
# Модифицируем данные:
a.append(4)
b.append(5)
c.append(6)
d.append(7)
# И получим:
a == b # True
a == c # False
a == d # False
b is a # True
c is a # False
d is a # False
# Через переменные a и b был поочередно модифицирован один и тот же объект.
# Значения этих переменных по-прежнему равны:
a # [1, 2, 3, 4, 5]
b # [1, 2, 3, 4, 5]
# А для переменных c и d - нет:
c # [1, 2, 3, 6]
d # [1, 2, 3, 7]
Жарковато бывает редко, 5-6 дней за лето. Пляжи в получасе езды от Лиссабона. Широкие и не очень забиты людьми даже в выходные.
Стоит заметить, что вода довольно холодная (не больше 22°C в пике в августе).
Без гидрокостюма или подготовки может быть не очень комфортно.
А еще недалеко от Лиссабона есть деревня Назаре, где зимой, в сезон, приходят самые большие волны в мире, на которых катаются бигвейв-серферы (в том числе и российские). Мировые рекорды по размеру взятых волн (нынешний — 80футов/24,384м) поставлены именно там. Знакомые очевидцы этого зрелища очень советовали, планирую добраться по возможности.
Строго говоря, это не совсем так. 127.0.0.0/8 — это блок локалхост (localhost) адресов. А лупбеки (loopback) — это виртуальные интерфейсы, на которые могут назначаться любые unicast адреса, в т.ч. и локалхост. Но это может быть и, к примеру, адрес 1.2.3.4/32. Пакеты, приходящие на адреса лупбек интерфейсов, маршрутизируются хостом самому себе (отсюда и название). Адрес на лупбеке может быть доступен извне, для этого должен быть маршрут до него через адрес какой-либо из физических интерфейсов этого же хоста. Как правило, это используется для обеспечения доступности адресов и/или балансировки трафика.
Пример: на Шри-Ланку просто нет прямых рейсов из РФ
Или Москва — не Россия, или информация из статьи успела устареть в процессе написания. Аэрофлот чуть менее недели назад запустил прямые регулярные рейсы на Шри-Ланку, и АК Россия — на Бали в Индонезию. Что характерно, по ценам не сильно дороже альтернативных регулярных рейсов со стыковками через Дубай/Доху для Шри-Ланки и Сингапур для Бали. За вариантами по сёрф-направлениям регулярно слежу.
А по поводу интровертов и их soft skills интересный взгляд есть в книге Девора Зак «Нетворкинг для интровертов» («Networking for People Who Hate Networking: A Field Guide for Introverts, the Overwhelmed, and the Underconnected» by Devora Zack в оригинале).
Но вообще же разница между интровертами и экстравертами прежде всего в том, что вторые заряжаются при общении, а первые разряжаются
Для себя нашел еще одну аналогию: люди — это усилители. Не даром ведь существует выражение «на одной волне с кем-то». Экстраверты — широкополосные усилители. У них большой рабочий диапазон частот, т.е. им легче с ходу найти общий язык со многими. Интроверты же — узкополосные усилители, они резонируют с определенными категориями людей. Но ширина полосы обратно пропорциональна возможному коэффициенту усиления. Интроверты способны на кратно большую интенсивность в общении на своих рабочих частотах (попробуйте остановить интроверта, который рассказывает Вам что-то, что ему действительно интересно). Т.е. нужно учиться перестраиваться в некоторых границах и искать окружения единомышленников. И отдыхать, восстанавливаться, конечно.
Род задачи определяется точкой зрения на нее. Помимо внутренних служб, есть еще и внешние консультанты (интеграторы, вендорская техподдержка и т.д.). Для последних анализ и аудит сети, которую видишь впервые, явление несколько более частое. А доступ к оборудованию, как правило, сильно ограничен. Постановка задачи из статьи (напомню, сформулирована не мной) с этой перспективы более характерна и логична.
Кроме того, задача сводится к анализу не только префиксов/путей, а еще и маршрутов:
Пример:
PATHS TO 192.168.204.204 FROM csr1000v-01
Detailed info:
Path 1:
['csr1000v-01', 'csr1000v-03', 'csr1000v-04']
ROUTER: csr1000v-01
Matched route string:
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
ROUTER: csr1000v-03
Matched route string:
D 192.168.204.0/24
[90/130816] via 192.168.34.204, 00:37:22, GigabitEthernet2
ROUTER: csr1000v-04
Matched route string:
L 192.168.204.204/32 is directly connected, Loopback204
Path 2:
['csr1000v-01', 'csr1000v-02', 'csr1000v-04']
ROUTER: csr1000v-01
Matched route string:
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
ROUTER: csr1000v-02
Matched route string:
D 192.168.204.0/24
[90/130816] via 192.168.24.204, 00:37:26, GigabitEthernet3
ROUTER: csr1000v-04
Matched route string:
L 192.168.204.204/32 is directly connected, Loopback204
Path search on csr1000v-01 has been completed in 0.000 sec
Откуда сразу видим, что, скажем, на csr1000v-01 пакет на 192.168.204.204 уйдет по маршруту из EIGRP с двумя equal-cost (131072) next-hop'ами через 192.168.13.203 и 192.168.13.202.
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
И так далее по всей цепочке.
Даже если отбросить все ограничения выше, как добиться передачи аналогичной информации через (i)BGP?
Full View в изначальных условиях не было, я его привёл в пример лишь в качестве одного из наиболее частых и возможных случаев тяжёлых таблиц маршрутизации, чтобы обозначить верхнюю границу применимости скрипта не в попугаях.
Основная цель — узнать цепочку промежуточных устройств до любого адреса с любого из имеющихся устройств. Попутно анализируя, какими маршрутами пойдёт пакет (например, должен по EIGRP, а где-то не удаленная статика осталась и т.п.). Или альтернативно — узнать какие фаерволы нужно пройти по дороге.
Вариантов применимости может быть много. Первоначальную же постановку вопроса взял из топика на одном форуме, как и обозначил выше.
Спасибо за обратную связь.
Да, развивать плагин планирую. Но в последний месяц брал небольшую паузу ото всех сайд-проектов. :)
Issue на ГитХабе относительно совместимости с NB 2.11 уже есть. Буквально только что выпустил новый релиз для фикса – доступен в исходниках и на PyPi.
В качестве Source-of-Truth могу посоветовать присмотреться к NetBox. В нем уже имеется необходимый для подобных задач набор абстракций и моделей данных (Devices, Interfaces, Cables и т.п.), хороший API, чтобы эти данные положить и достать, и широкие возможности для расширения, если нужно что-то нестандартное. Есть хорошая документация, статьи, видео и сложившееся комьюнити (в том числе русскоязычное).
А из основы решения из этой статьи как раз родился плагин NextBox-UI для визуализации топологий в NetBox.
– Да.
Спасибо, кстати, за наводку на Grammarly-плагин для VSCode. :)
Код выложил на GitHub, если кого-то заинтересует.
Для корпоративных доменных сетей минимально можно смотреть MAC-адреса на портах, по ним из ARP узнавать IP-адреса, а из IP-адресов пытаться ресолвить хостнеймы.
При внедренном 802.1x предсказуемость результата становится уже выше. И так с каждым дополнительным источником информации об устройствах.
Как и всегда, не существует универсальных решений. Инструменты хороши в совокупности, и схемы с таблицами обычно дополняют друг друга. LLPD/CDP же дает базовое понимание топологии, поверх него уже можно накладывать дополнительные слои, обогащать схему деталями по потребностям и визуализировать более сложные кейсы (например, визуализацию путей из моей прошлой статьи).
Для случаев с большим количеством линков и нод в NeXt UI, кстати, есть хороший функционал Node Sets (наборы нод), с помощью него можно группировать отдельные ноды и сворачивать их в одну пиктограмму (и разворачивать по клику) при визуализации.
С необходимостью SoT в той или иной реализации полностью согласен. И идею с визуализацией можно развить и в этой плоскости, формируя объект топологии на основании связей и данных в Netbox, доставаемых через API. Экспериментами в этом направлении, скорее всего, и займусь. Если сообществу будет интересно, может, опубликую отдельную статью.
С учетом того, что у Netbox открытый код, можно даже интегрировать вкладку с визуализацией напрямую в его интерфейс (например, в /dcim/sites/$site_slug).
Было бы интересно почитать статью с описанием подобного опыта. :)
И еще пара вопросов, если возможно.
1. А Nornir не доводилось использовать? Не так давно для себя его обнаружил, выглядит многообещающе. Это дополнительная абстракция над netmiko и napalm с инвентори и мультитредингом.
2. Какой подход к безопасному хранению учеток/паролей и их импорту в скрипты используете в сетевой автоматизации?
Схема оклад+премия (квартальная, годовая) по собственному опыту и опыту знакомых практикуется многими крупными энтерпрайзами и телекомами. В особенности, на лидствующих и начальствующих позициях.
karaboz В этом случае сейчас следует указывать годовой доход, делённый на 12?
Было бы полезно сделать опцию с возможностью указания годового дохода (и окладной части по желанию).
В чем в примере выше ошибка по существу?
Был бы признателен за конструктивную критику.
На мой, не специализирующийся на Python, взгляд, вопрос имеет под собой почву:
И в случае с мутабельными объектами разница может быть:
Без гидрокостюма или подготовки может быть не очень комфортно.
А еще недалеко от Лиссабона есть деревня Назаре, где зимой, в сезон, приходят самые большие волны в мире, на которых катаются бигвейв-серферы (в том числе и российские). Мировые рекорды по размеру взятых волн (нынешний — 80футов/24,384м) поставлены именно там. Знакомые очевидцы этого зрелища очень советовали, планирую добраться по возможности.
Для себя нашел еще одну аналогию: люди — это усилители. Не даром ведь существует выражение «на одной волне с кем-то». Экстраверты — широкополосные усилители. У них большой рабочий диапазон частот, т.е. им легче с ходу найти общий язык со многими. Интроверты же — узкополосные усилители, они резонируют с определенными категориями людей. Но ширина полосы обратно пропорциональна возможному коэффициенту усиления. Интроверты способны на кратно большую интенсивность в общении на своих рабочих частотах (попробуйте остановить интроверта, который рассказывает Вам что-то, что ему действительно интересно). Т.е. нужно учиться перестраиваться в некоторых границах и искать окружения единомышленников. И отдыхать, восстанавливаться, конечно.
Кроме того, задача сводится к анализу не только префиксов/путей, а еще и маршрутов:
PATHS TO 192.168.204.204 FROM csr1000v-01
Detailed info:
Path 1:
['csr1000v-01', 'csr1000v-03', 'csr1000v-04']
ROUTER: csr1000v-01
Matched route string:
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
ROUTER: csr1000v-03
Matched route string:
D 192.168.204.0/24
[90/130816] via 192.168.34.204, 00:37:22, GigabitEthernet2
ROUTER: csr1000v-04
Matched route string:
L 192.168.204.204/32 is directly connected, Loopback204
Path 2:
['csr1000v-01', 'csr1000v-02', 'csr1000v-04']
ROUTER: csr1000v-01
Matched route string:
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
ROUTER: csr1000v-02
Matched route string:
D 192.168.204.0/24
[90/130816] via 192.168.24.204, 00:37:26, GigabitEthernet3
ROUTER: csr1000v-04
Matched route string:
L 192.168.204.204/32 is directly connected, Loopback204
Path search on csr1000v-01 has been completed in 0.000 sec
И так далее по всей цепочке.
Даже если отбросить все ограничения выше, как добиться передачи аналогичной информации через (i)BGP?
Full View в изначальных условиях не было, я его привёл в пример лишь в качестве одного из наиболее частых и возможных случаев тяжёлых таблиц маршрутизации, чтобы обозначить верхнюю границу применимости скрипта не в попугаях.
Основная цель — узнать цепочку промежуточных устройств до любого адреса с любого из имеющихся устройств. Попутно анализируя, какими маршрутами пойдёт пакет (например, должен по EIGRP, а где-то не удаленная статика осталась и т.п.). Или альтернативно — узнать какие фаерволы нужно пройти по дороге.
Вариантов применимости может быть много. Первоначальную же постановку вопроса взял из топика на одном форуме, как и обозначил выше.