Общеизвестно, что существуют несколько версий протокола OSPF. Однако не только лишь все знают о том, что для OSPFv2 есть несколько вариантов RFC; подавляющая часть реализаций OSPF соответствуют RFC 1583 или RFC 2328. Пикантность ситуации в том, что эти RFC несовместимы между собой, о чём говорит и показывает вендор-которого-нельзя-называть. Ну и зачем же тогда IETF заморочилось созданием второго стандарта? Ответ прост: RFC 1583 содержит архитектурные недостатки, которые могут привести к образованию в сети петель маршрутизации.

Одно из наиболее ярких отличий между стандартами – вычисление метрики суммарного маршрута на ABR.

В предыдущей заметке я описал, как можно заткнуть дыру в кривом дизайне OSPF – костылём, который усложняет и так запутанный OSPF.

NSSA-зона ещё больше усугубляет ситуацию: OSPF использует Forwarding Address в Type-5 LSA, которые транслированы из Type-7 LSA, чтобы обеспечить оптимальную маршрутизацию.

В первой заметке я описал типичный (насколько его проповедуют в интернете) сценарий использования Forwarding Address (FA): два ASBR подключены к одному внешнему сегменту, причём redistribution маршрутов настроен только на одном из них.

Очевидно, что такой дизайн плох с точки зрения отказоустойчивости, но, возможно, существуют сценарии, когда использование OSPF FA уместно?

Один из моих читателей прислал мне любопытный вопрос об NSSA (подробнее в будущей статье), который побудил меня копнуть глубже вопрос о том, зачем понадобилось поле OSPF Forwarding Address (FA) в Type-5 и Type-7 LSA.

Коллеги-сетевики, привет. К написанию данной статьи меня сподвигли задачи, с которыми приходилось сталкиваться во время работы с OSPF/IS-IS и тот набор решений, к которому я в конечном итоге пришел. Речь идет о насущном вопросе сетевых инженеров, когда приходится применять настройки на живой сети (пусть и с программируемым откатом на крайний случай) без возможности посмотреть как это отразится на всей сети в целом. Если отдельные команды и сценарии еще можно проверить в лабе, то получить полную реплику сети практически невозможно. В связи с этим я задался вопросом о наличии инструмента, который позволял бы строить слепок сети и рассчитывать её реакцию на ранее примененные настройки. Об этом сегодняшний туториал.

На написание статьи меня сподвиг интересный Tutorial от Валерия Лутошкина с настройкой BGP и VPS на оборудовании MikroTik. Это решение натолкнуло меня на домашнюю практику с протоколами динамической маршрутизации. Попробовав его реализовать, я понял, что мой домашний провайдер не даёт манёвров для действий и блокирует порт TCP 179 по умолчанию. В дополнение к этому у меня нет белого IP адреса и я за NATом. В общем все прелести рядового пользователя. Разбираемся как облегчить себе жизнь с помощью MikroTik.

Если вы хоть раз настраивали MPLS L3VPN, то у вас не возникнет сомнения в том, что весь подход вертится вокруг BGP. Будучи протоколом маршрутизации с развитым чувством собственного достоинства (в конце концов, он является основой для интернета), BGP использует внушительный список атрибутов префикса, которые лежат в основе алгоритма выбора лучшего маршрута. Несмотря на неприличную длину этого списка, большинство параметров предназначены для обеспечения детерминированности результата алгоритма, а не для управления трафиком руками инженера. Впрочем, иногда даже самые популярные параметры не подходят для решения определённой задачи. Если вы видите EIGRP в связке с L3VPN, возможно, это наш сегодняшний пациент.

Роли LSA довольно подробно разобраны в разных источниках: router LSA описывает узлы графа, network LSA предназначен для широковещательных сегментов сети, summary LSA обеспечивает взаимодействие разных зон между собой… Однако собрать эти структуры данных воедино в целостный граф кажется мне достаточно нетривиальной задачей. Безусловно, RFC является источником абсолютного знания в такого рода вопросах, но лично мне сравнительно долго не удавалось его полноценно осознать. В этой статье я хотел бы поделиться своим представлением о назначении типов LSA, а также процессом построения графа на основе LSDB.

Хотелось ли вам когда-нибудь выборочно фильтровать LSA5? Надоело, что исключать внешние префиксы можно только на ASBR? Вы обратились по адресу! Сегодня я бы хотел рассказать про подход, позволяющий фильтровать LSA5 в том числе на ABR.

Собственно один из сценариев с OSPF - распространение маршрутной информации от одного филиала в другой, и в 6-ке проблем не было. Настроил зону, включил туда диапазон выдаваемый любым PtP сервером и адреса клиентов полетели по всем филиалам. Да, очень неудобно, когда таких маршрутов много, их обычно можно агрегировать и проблемы нет. Но в 7-ке проблема в другом, то ли из-за бага, то ли я что-то делаю не так, но маршруты для PtP клиентов не распространяются.

Disclaimer: только для гиков; устаревшая технология; статья в режиме “just for fun”.

OSFP, будучи link-state протоколом, исключает петли в топологии за счёт построения дерева кратчайшего пути. Впрочем, тёмный гений изобрёл инструмент разрушения стройной идеи OSPF – речь пойдёт о функции OSPF Virtual Link.

(первая часть тут: https://habr.com/ru/post/456446/)

CEPH

Введение

Поскольку сеть является одним из ключевых элементов Ceph, а она в нашей компании немного специфична — расскажем сначала немного о ней.
Тут будет сильно меньше описаний самого Ceph, в основном сетевая инфраструктура. Описываться будут только сервера Ceph-а и некоторые особенности серверов виртуализации Proxmox.

• транспортный протокол: IPv4;
• протокол динамической маршрутизации OSPFv2 [1, 2];
• исходящий и входящий трафик одного пользовательского IP-адреса проходит через один и тот же шлюз услуг и через один и тот же NAT-маршрутизатор [3];
• балансировка трафика осуществляется между 2 шлюзами услуг (BNG [4]);
• балансировка трафика осуществляется между 2 NAT-маршрутизаторами, не использующими динамическую маршрутизацию;

• балансировка трафика в точке подключения пользовательских устройств к сети;
• равномерное распределение пользовательского трафика между BNG;
• обеспечение симметричной маршрутизации входящего и исходящего трафика при использовании NAT.

Дано: