выбран новый «велосипед» с 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, чтобы сам инженер мог добавить парсер для своего вывода и это автоматом подхватилось бы инструментом, а потом не потребовалось бы ассоциировать каждое устройство с его парсер-профайлом.
Не судите строго за мой вопрос — я наткнулся на согласованное хеширование при изучении L4 балансировщиков. Правильно ли я понимаю, что данный алгоритм хеширования используется при большом количестве балансировщик, которые могут быть увечеличены горизонтально. В таком случае слоты — это балансировщики в данном алгоритме, правильно ли я понимаю? Если у нас есть 10 балансировщиков, каждый из них независимо друг на друга будет считать хеш для тех пакетов, которые на него пришли (LB на схеме)?
Правильно ли я понимаю, что сам оператор связи ( в вашем тесте это MTC и Мегафон) должны поддерживать SD-WAN? или заслуга SD-WAN заключается в том, что CPE железка устанавливает 2 BGP сессии через 2-ух провайдеров для сигнализации к контроллеру, от него она получает обо всех других удаленных офисах, а также тип балансировки (per-packet, per-session) опять же через 2 активные BGP Сессии? и как CPE узнает, что первый канал может 10 Мбит, в второй — 50? Это нужно задавать в настройках вручную? То есть по сути versa как и другой SD-WAN провайдер предлает WEB-интерфейс для удаленного управления CPE, а также «услуги» в виде BGP route-reflector-a?
продавец перетыкает шнурок из одной «коробки» в другую
То есть это в том случае когда у нас резервирование не только через несколько модемов, но и физическое резервирование CPE устройств? т.е они работают только в режиме Active-Standby?
интересно было бы узнать как обстоит дело с визой, когда меняешь работу в Ирландии. Виза прикрепляется за определенным работодателем, т.е. увольняешься и нужно вновь собирать документы на оформление рабочей визы?
Спасибо за статью. Однако у меня вопрос: до этого (до вашей статьи) для меня TCP Congestion Control Algorithm-ы это были Fast Retransmit and Recovery (FRR) и Selective ACK (SACK), а в ваших примерах TCP Veno и проч. Правильно ли я понял, что BIC, CUBIC, Highspeed, H-TCP, NewReno, Illinois — это как пакеты, которые описывают работу TCP Congestion алгоритмов. Т.е. возможно в одном из этих «пакетов» также присутствует алгоритмы Fast Retransmit и Selective ACK?
хм, да, верно, не очень точная аналогия. А если суммируешь маршруты в Cisco через summary-address, то summary будет анонсироваться до момента, пока хотя бы 1 специфический маршрут будет в RIB-e. Правда в Cisco это не называется static route.
А что по поводу стабильности работы?.. В GNS 1.3.3 можно работать полдня, а потом пропадает соединение с один/несколькими роутерами и их нужно рестартовать, чтобы восстановить связь. В Unitlab как обстоит с этим дело?
Я был в городе Сыктывкар и с удовольствием посетил пиццерию, которую сейчас открыл Федор Овчинников (как раз этим и заканчивается книга как он устроился работать в фастфуд для получения опыта).
Спасибо за статью,
поясните, пожалуйста, Вы указываете пользоваться Wireshark-ом версии 1.6, а на скриншотах у вас установлена самая последняя версия 1.12, т.е. как я понял, что это работает не только на версии до 1.6?..
Если Вы имеете в виду VXLAN применительно к Дата центрам (а если точнее то для применению их на Nexus 1000v и проч Nexus ), то это уже немного другая религия под названием «Дата центры», туда же можно было бы отнести и технологию OTV, для объединения нескольких дата центров через IP, но это я сознательно опустил.
Через ssh вполне справедливое замечание и я так понимаю, что она относится к Remote Access? Однако, представьте задачу объяснить, допустим, женщине из бухгалтерии, которой нужно в выходные подключиться к корпоративной сети для сверки баланса, проделать следующее: «запускаете Putty, стучитесь по ssh на такой то IP, авторизуетесь и вуа-ля — теперь можно подключаться на свой лупбэк» ) Если это выглядит как-то по-другому, то поправьте меня.
Спасибо!
На самом деле по хронологии событий сначала я написал статью для Сетей для самых маленьких и только потом Марат предложил мне опубликовать её здесь)
Здравствуйте, они задаются через переменные окружения в docker-compose.override.yml:
После этого нужно с иницировать их создание, т.е. после запуска docker-compose up -d, выполнить один раз такой запрос:
Спасибо за столь развернутый комментарий!)
GRE c OSPF необходимо установить лишь до одной ноды в каждой area, чтобы полностью знать, что происходит в этой area.
Все верно: N area = N необходимых соседств, при этому это число еще больше можно уменьшить, если устанавливать OSPF over GRE до ABR устройств.
Да, вендоров много, гораздо легче работать с одним вендором на борту, тогда неважно с кем строится OSPF соседство - формат OSPF LSDB на Quagga один и тот же.
Принцип работы 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 смог сообщить об этом инциденте.Ospfwatcher по сути это и делает, он парсит вывод дебаг OSPF процесса у себя локально, который предоставляет ему Quagga процесс.
Да, все верно, правда справедливости ради лучше описать раскладку именно в такой последовательности: "у нас не один OSPF, ISIS в сети может быть, а так же static routes, (i)BGP, EIGRP и даже RIP" :) Но может быть иметь несколько IGP протоколов в одной сети это не так оправдано и стоит переходить к сети только лишь с одним OSPF/ISIS в качестве IGP? Хотя я уверен, что так получается не от того, что админу стало скучно жить и он решил настроить все что мог, просто так получается при объединении компаний или банально "так исторически сложилось" и никто не меняет это.
Да, анализ RIB показал бы точный маршрут, но в таком случае надо кардинально менять архитектуру решения: вместо получения данных из 1 или несколько устройств в разных area, до подключения к каждому устройству в сети. И когда речь заходит о каком-либо инструменте, который просит передать ему на вход логин и пароль для подключения ко всем железкам, то ряды таких добровольцев значительно редеют. И даже если будет доверие к инструменту, то для того, чтобы это реализовать - разработчику необходимо иметь пример вывода RIB с устройства каждого вендора, что весьма затруднительно. Нужен универсальный метод или подход, основанный на поддержку community, например как у textfsm, чтобы сам инженер мог добавить парсер для своего вывода и это автоматом подхватилось бы инструментом, а потом не потребовалось бы ассоциировать каждое устройство с его парсер-профайлом.
Еще раз спасибо за комментарий!)
root123
поясните, пожалуйста, Вы указываете пользоваться Wireshark-ом версии 1.6, а на скриншотах у вас установлена самая последняя версия 1.12, т.е. как я понял, что это работает не только на версии до 1.6?..
Через ssh вполне справедливое замечание и я так понимаю, что она относится к Remote Access? Однако, представьте задачу объяснить, допустим, женщине из бухгалтерии, которой нужно в выходные подключиться к корпоративной сети для сверки баланса, проделать следующее: «запускаете Putty, стучитесь по ssh на такой то IP, авторизуетесь и вуа-ля — теперь можно подключаться на свой лупбэк» ) Если это выглядит как-то по-другому, то поправьте меня.
На самом деле по хронологии событий сначала я написал статью для Сетей для самых маленьких и только потом Марат предложил мне опубликовать её здесь)