Комментарии 7
«Но гораздо эффективней и рациональней предоставить возможность сервису читать актуальные служебные сообщения OSPF (LSA) в режиме реального времени и таким образом логировать изменения на сети.»
А почему для этой цели выбран новый «велосипед» с GRE и OSPF до (каждой!) ноды под капотом - мне не понятно.
Может быть объяснение кроется в том, что хотели получить «вендор-агностик» парсинг на конечной коробке (ospfwatcher)? Но были ли исследованы другие менее "инвазивные" в control-plane методы (например grpc/snmp, в конце-концов парсинг обычных log-сообщений)?
На мой взгляд такая реализация - это дополнительный оверхед + лишняя зависимость на control-plane для железок.
Поясню: имея соседство со всеми железками по OSPF в сети, можно случайно или намеренно выстрелить себе в ногу - например через объявление дефолтного маршрута с этой железки.
Кроме того, OSPF может быть многозонным - в какой(их) зоне(ах) делается соседство через GRE?:)
Касаемо тематики самой статьи - для меня здесь виден чисто академический интерес. Ведь с точки зрения решения прикладных задач - у нас не один OSPF в сети может быть, а так же (i)BGP, EIGRP,ISIS, и даже RIP (во всех смыслах:)). На практике это говорит о ненадежности получения информации с данного инструмента для анализа изменений и прокладывания актуального пути трафика. В этом плане для анализа лучше использовать снапшоты таблицы маршрутизации (RIB) (ну и не буду говорить тут про возможные усложнения в виде VRF-leaking и прочем - оставим это за кадром).
Однако очень понравился подход со снапшотами состояний - это круто в том плане, что мы можем посмотреть КОНСИСТЕНТНО, а не в пределах одной ноды, состояние всей сети в определенный момент времени (т.н bird-view).
Если этот подход смиксовать с RIB, возможно, получится вполне сносный инструмент для ретроспективного анализа сети - и я даже не исключаю, что такой уже есть, просто я о нем не знаю :)
В любом случае, автору респект, спасибо за статью - заставила вспомнить об OSPF :)
Спасибо за столь развернутый комментарий!)
выбран новый «велосипед» с GRE и OSPF до (каждой!) ноды под капотом - мне не понятно.
GRE c OSPF необходимо установить лишь до одной ноды в каждой area, чтобы полностью знать, что происходит в этой area.
Кроме того, OSPF может быть многозонным - в какой(их) зоне(ах) делается соседство через GRE?:)
Все верно: N area = N необходимых соседств, при этому это число еще больше можно уменьшить, если устанавливать OSPF over GRE до ABR устройств.
Может быть объяснение кроется в том, что хотели получить «вендор-агностик» парсинг на конечной коробке (ospfwatcher)
Да, вендоров много, гораздо легче работать с одним вендором на борту, тогда неважно с кем строится OSPF соседство - формат OSPF LSDB на Quagga один и тот же.
Но были ли исследованы другие менее "инвазивные" в control-plane методы (например grpc/snmp, в конце-концов парсинг обычных log-сообщений)
Принцип работы Ospfwatch-а - это прослушивание служебных (debug) сообщений OSPF в режиме online, то есть если не происходит ничего более, чем обновление времени жизни LSA, то никаких действий не предпринимается. В случае SNMP, есть два варианта: когда мы опрашиваем железку с какой-то периодичностью и пытаемся найти diff, либо делаем snmp listener и ловим trap. В первом варианте мы сталкиваемся всё с тем же вопросом как часто делать опрос и зависим от вендора, который предоставляет или не предоставляет такую информацию через snmp. Во-втором случае мы также зависим от формата snmp trap-а и получается дополнительная необходимость настройки snmp trap server на всех железках area. Это нужно будет сделать, если в случае схемы Ospfwatcher -- Router1 - OSPF adjacency - Router2 , когда потерялась связность между роутерами и Router2 отправил snmp trap, то он не дойдет до Ospfwatcher-a. SNMP trap server нужно будет настраивать как и на Router1, так и на Router2, чтобы Router1 смог сообщить об этом инциденте.
в конце-концов парсинг обычных log-сообщений)
Ospfwatcher по сути это и делает, он парсит вывод дебаг OSPF процесса у себя локально, который предоставляет ему Quagga процесс.
Ведь с точки зрения решения прикладных задач - у нас не один OSPF в сети может быть, а так же (i)BGP, EIGRP,ISIS, и даже RIP (во всех смыслах:)).
Да, все верно, правда справедливости ради лучше описать раскладку именно в такой последовательности: "у нас не один OSPF, ISIS в сети может быть, а так же static routes, (i)BGP, EIGRP и даже RIP" :) Но может быть иметь несколько IGP протоколов в одной сети это не так оправдано и стоит переходить к сети только лишь с одним OSPF/ISIS в качестве IGP? Хотя я уверен, что так получается не от того, что админу стало скучно жить и он решил настроить все что мог, просто так получается при объединении компаний или банально "так исторически сложилось" и никто не меняет это.
В этом плане для анализа лучше использовать снапшоты таблицы маршрутизации (RIB)
Да, анализ RIB показал бы точный маршрут, но в таком случае надо кардинально менять архитектуру решения: вместо получения данных из 1 или несколько устройств в разных area, до подключения к каждому устройству в сети. И когда речь заходит о каком-либо инструменте, который просит передать ему на вход логин и пароль для подключения ко всем железкам, то ряды таких добровольцев значительно редеют. И даже если будет доверие к инструменту, то для того, чтобы это реализовать - разработчику необходимо иметь пример вывода RIB с устройства каждого вендора, что весьма затруднительно. Нужен универсальный метод или подход, основанный на поддержку community, например как у textfsm, чтобы сам инженер мог добавить парсер для своего вывода и это автоматом подхватилось бы инструментом, а потом не потребовалось бы ассоциировать каждое устройство с его парсер-профайлом.
Еще раз спасибо за комментарий!)
Касаемо тематики самой статьи - для меня здесь виден чисто академический интерес. Ведь с точки зрения решения прикладных задач - у нас не один OSPF в сети может быть, а так же (i)BGP, EIGRP,ISIS, и даже RIP (во всех смыслах:)). На практике это говорит о ненадежности получения информации с данного инструмента для анализа изменений и прокладывания актуального пути трафика.
Почему? У вас же другие RP не сами по себе живут, какая-никакая редистрибуция в основной (а если вы выбираете этот инструмент, то это OSPF) настроена, и соответствующие LSA об изменениях в маршрутах вы увидите. А то, что в основной протокол не редистрибутится, очевидно, не так уж и важно.
Мысль про RIB поддерживаю, и это не кажется слишком сложным: похоже, что это будет просто ещё один граф, на этот раз настоящий, на основании которого принимаются решения о рутинге.
Если у вас такой здоровенный OSPF домен, который нельзя залабить в GNS3, может что-то не так с дизайном сети?
Подскажите Дефолтный логин и пароль для Topolograph, после установки через Докер. Нигде нет этой информации, ни здесь, ни на GitHub
Здравствуйте, они задаются через переменные окружения в docker-compose.override.yml:
TOPOLOGRAPH_WEB_API_USERNAME_EMAIL: 'ospf@topolograph.com'
TOPOLOGRAPH_WEB_API_PASSWORD: 'ospf'
TOPOLOGRAPH_WEB_API_AUTHORISED_NETWORKS: '127.0.0.1/32,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16'
SWAGGER_HOST: 'localhost:8088'После этого нужно с иницировать их создание, т.е. после запуска docker-compose up -d, выполнить один раз такой запрос:
import requests
res = requests.post('http://localhost:8088/create-default-credentials')
res.json()
{'errors': '', 'status': 'ok'}
Насколько хорошо у вас настроен OSPF/IS-IS или помогатор для сетевых инженеров