Модель описания многоуровневых сетевых топологий для хранения и анализа динамической маршрутной информации

Развитие любой компании или организации приводит к усложнению используемой ими IT-инфраструктуры, в основе которой всегда лежит сетевая инфраструктура. А чем сложнее и больше сетевая инфраструктура, тем труднее становится отслеживать стабильность ее работы, управлять ей и автоматизировать. Автоматизация, в свою очередь, требует точного понимания структуры построения сетевой инфраструктуры, глубокого представления о ее функционировании в настоящий момент времени и возможности прогнозировать возникновение ошибок и аномалий в ближайшем будущем. Основой любой автоматизации является множество различных данных - например, полученные из разнообразных сервисов мониторинга, конфигураций сетевых устройств, из бизнес требований по автоматизации и т.д. Но одной из ключевых категорий данных является топология сетевой инфраструктуры с детальным описанием ее структуры и внутренних связей. Практически все остальные данные так или иначе связаны с топологией - они либо происходят из топологии, либо определяют процессы формирования и использования топологии, либо связывают различные ресурсы (например, IP-адреса и физическое оборудование) с конкретными элементами топологии сети.

В направлении создания и описания сетевых топологий в разное время проводилось несколько исследований (RFC 8345/8346 [1,2], Google MALT [3], ONF T-API [4]) и авторами вводился термин модели топологии - абстрактной структуры данных, которая описывает топологию сети в виде графа. Использование такой модели позволяет решить множество задач мониторинга, управления и автоматизации работы с сетевой инфраструктурой, среди которых можно выделить:

• 1)    Source of Truth. Любой процесс управления сетевой инфраструктурой требует наличия источника данных, который максимально соответствует действительности. Фактически модель описания топологии сети определяет структуру этого источника данных как хранилища, которое обладает максимально полной информацией о сети и данные из которого могут быть использованы другими сервисами.

• 2)    Мониторинг связности и функционирования сети. Благодаря наличию модели топологии, которая используется для описания всей сетевой инфраструктуры, ее можно наполнять данными из различных сервисов мониторинга. Эти данные затем используются для решения аналитических задач и для реагирования на аномалии -например, на нарушения связности, перегрузку сетевых узлов и т.д.

• 3)    Управление конфигурациями сетевых устройств. С помощью модели описания топологии сети можно хранить конфигурации сетевых устройств. Это может быть как явное описание конфигураций (например, в формате OpenConfig YANG [5]), так и их адаптированное представление (Google MALT [3]). Модель с данными о конфигурациях можно использовать для создания сервисов по управлению оборудованием, которые будут использовать модель для описания и хранения текущей конфигурации устройств, истории ее изменений и т.д.

• 4)    Описание многоуровневых топологий. Сети по своей природе являются многоуровневыми - в частности, модель OSI насчитывает семь уровней абстракции. Важно уметь связывать эти уровни между собой - например, понимать, как соотносятся L2- и LS-устройства, соответствие между логическими и физическими портами устройств и т.д. С помощью модели можно строить и описывать подобные соответствия, что еще больше расширяет область ее применимости - в частности, для решения задач корреляции событий, произошедших на разных уровнях абстракции сети, поиске первопричин (root-cause) возникших в сети проблем и т.д.

• 5)    Верификация сетей. Одним из наиболее активно развивающихся современных направлений исследований является направление по верификации сетей (Network

2.    Обзор существующих моделей описания топологии сети 2.1.    Модель IETF

Verification) [6-9]. Основной задачей верификации является ответ на вопрос о правильности работы сети и введение формальной спецификации сети, в основе которой лежит задача проверки достижимости (наличие/отсутствие маршрутов прохождения трафика между точками А и В). Для решения задач верификации также необходимо наличие комплексной модели описания топологии сети.

В данной работе проводится исследование применимости различных моделей описания топологии сети для решения задач мониторинга и автоматизации управления сетевой инфраструктурой, а также представлена модель и предложена архитектура системы мониторинга и управления, которая использует созданную модель для хранения динамической маршрутной информации для протоколов OSPF и BGP.

Перейдем к обзору существующих моделей описания топологии сети - как они позволяют объединять данные из разных систем и как способствуют всесторонней автоматизации сетевой инфраструктуры.

Сообщество Internet Engineering Task Force (IETF) в 2018 году выпустило серию RFC, посвященных созданию и стандартизации YANG-моделей, предназначенных для описания различных сетевых взаимодействий (RFC 8341-8349). В том числе среди них есть YANG-модели, предназначенные для описания топологии сети. Далее рассмотрим только RFC 8345 [1] с описанием общей модели топологии сети, которая должна быть связующим звеном между остальными моделями, а также RFC 8346 [2] с описанием модели для ЬЗ-топологий.

| Abstract Network Model |

Inventory Model(s)

| Abstract |

I Topology I Model

LI Topology Model

L2 :   :     L3     :   :  Service

Topology :  : Topology :  : Topology

Model :  :   Model  :  :   Model

Рис. 1. Структура модели описания топологии Рис. 2. Пример иерархии топологии сети, RFC сети, RFC 8345 [1]                                 8345 [1]

В RFC 8345 IETF определяет универсальную (generic) абстрактную структуру данных, предназначенную для описания топологии сети. Структура данных задается при помощи YANG-мод ел ей. Модель определяет такие сущности, как граф топологии, узлы и ребра графа, и другие. На рисунке 1 обозначена общая структура модели топологии - она состоит из множества «модулей», которые позволяют описывать различные уровни сети: LI, L2, L3 и т.д. Кроме того, каждые из этих уровней можно связывать друг с другом и, таким образом, получать соответствие между, например, физическими устройствами и их логической взаимосвязью друг с другом (в частности, маршрутизацией), а также образовать многоуровневое представление топологии (см. рис. 2).

Одним из модулей, который встраивается в общую (RFC 8345) модель, является приведенная в RFC 8346 модель описания топологии L3. В частности, авторы приводят пример моде- ли топологии для протокола OSPF, однако явно указывают на то, что она «не представляет собой полноценную топологическую модель OSPF, которая может быть более сложной и полной» [2]. В RFC 8345 авторы приводят возможные применения описанных ими моделей. В частности, они предлагают использовать их модель для стандартизации формата данных, который будет использоваться оборудованием для передачи топологии во внешние системы. То есть маршрутизатор в сети, знающий топологию (например, OSPF или ISIS), будет способен передать эту топологию в некоторую систему мониторинга/управления в стандартизированном формате [1]. Кроме того, авторы предлагают использовать модель топологии внутри некоторого SDN-контроллера (например, OpenDaylight [10]), который будет содержать всю информацию о сети и ее топологии. Затем информацию, полученную из SDN-контроллера, можно будет использовать для решения других задач - в частности, управления наложенными сетями (overlay), сетевыми сервисами и т.п [1].

Если общая идея предложенного IETF-подхода к созданию абстрактной многоуровневой модели описания топологии сети звучит разумно, то к деталям реализации возникает множество вопросов:

• 1)    Описанная модель является слишком универсальной и не учитывает специфику протоколов и построения сетей в целом, что приводит к невозможности использования предложенной модели в «чистом виде» без дополнительных доработок.

• 2)    Структура описанной YANG-модели - дерево. Безусловно, с помощью древовидных структур можно описывать графы, но это накладывает определенные расходы на операции с данными. Например, для получения соответствия между физическими устройствами (L1) и устройствами L3 необходимо обойти два поддерева и т.п.

2.2.    Модель ONF

В настоящий момент времени авторам неизвестны решения, которые используют предложенные комитетом IETF-модели.

Open Networking Foundation (ONF) в 2014 году выпустил первую версию своей модели для описания топологии сети - Transport-API (Т-API). Сама модель, аналогично созданной IETF, описывается при помощи формата YANG [11]. ONF позиционирует Т-API как интерфейс для общения между различными сервисами-контроллерами в одном большом SDN контроллере - Open Network Operating System (ONOS), который разрабатывается и поддерживается сообществом ONF. Кроме того, ONF формулирует список задач (или примитивов), которые позволяет решать T-API [12]:

• 1)    Описание и получение топологии сети или информации о доступности ресурсов и их текущем статусе.

• 2)    Дать возможность создавать связи между узлами существующих сервисов или запрашивать вычисление путей для построения будущих сервисов.

• 3)    Предоставлять информацию обо всех событиях и изменениях в сети подписавшимся на уведомления клиентам.

• 4)    Виртуализация или разбиение всей сети на изолированные виртуальные части (partitions), которые предназначены для использования конкретными клиентами или приложениями.

2.3.    Модель MALT (Google)

В целом Т-API (как модель описания топологии сети и как API для общения с сетью) позволяет получить множество данных, которые можно использовать в более верхнеуров-невых сервисах и приложениях. Аналогичную идею предлагает и RFC 8345 [1].

Модели описания топологии сети IETF и ONF разрабатывались в разное время, поэтому имеют несколько различий. В основном они заключаются в структуре описания модели - например, в отличие от IETF, у ONF узел сети (Node на рис. 3) может содержать в себе информацию о том, каким уровням сети (Topology на рис. 3) он принадлежит, в то время как у IETF узел принадлежит уровню сети. Таким образом, на каждом уровне сети необходимо указывать все устройства, даже если они соответствуют одному физическому устройству. Между сущностями моделей IETF и ONE можно построить соответствие и таким образом добавить поддержку моделей IETF в проект ONE [4]. На момент времени написания данной работы этого сделано не было. Однако у модели ONE те же минусы, что и у модели IETF. Также отметим, что SDN-контроллер ONOS в последние годы перестал активно развиваться.

Рис. 3. Слева: модель топологии T-API 2.2; Справа: модель топологии RFC 8345 [4]

В 2020 году компанией Google была представлена модель описания топологии сети Multi-Abstraction-Layer Topology (MALT). MALT, помимо модели топологии, включает в себя распределенную систему хранения данных, специализированный язык запросов к ней для получения данных из модели и т.д. Google в своей статье [3] приводит следующую мотивацию для создания MALT:

• 1)    Поддержка полного цикла управления сетью. Google использует модель MALT для решения задач планирования, анализа надежности, высокоуровневого и детального проектирования сети, планирования и аудита развертывания, а также в качестве одного из источников для генерации конфигурации устройств и SDN-контроллера. MALT также используется совместно с внутренними системами мониторинга и управления пропускной способностью.

• 2)    Единообразие. До внедрения MALT в Google использовалось множество систем, которые поддерживали свое представление топологии сети для своих собственных целей. Эти системы часто должны были обмениваться данными о топологии. Без единого и унифицированного представления это приводило не только к О( N 2) обменам топологиями между системами, но также и к возможности потери данных или их неоднозначности, что делало реальную автоматизацию практически невозможной.

Единообразие также позволяет сотням разработчиков Google с небольшими затратами писать взаимодействующие друг с другом системы без значительных накладных расходов на координацию между собой (которые также склонны увеличиваться, как N 2.

• 3)    Несколько уровней абстракции. Многие процессы проектирования, эксплуатации, исправления ошибок и анализа требуют явного понимания связей между высокоуровневым проектным намерением (intent) и низкоуровневыми реализациями. Например, при анализе плана развития сети широкополосного доступа (ШПД), чтобы понять, будет ли он соответствовать требованиям доступности SLO [13], нужно знать физическое расположение низлежащего оптоволокна - например, будут ли два оптоволоконных кабеля проходить через один и тот же мост или под одним и тем же полем (что необходимо для обеспечения отказоустойчивости сети в случае повреждения одного из кабелей в ходе ремонтных работ, стихийных бедствий и т.п.). MALT позволяет явно представлять эти абстрактные отношения.

Рис. 4. Пример простейшего графа топологии MALT [3]

В отличие от моделей IETF и ONE, в модели MALT не используется представление в формате YANG. Вместо этого MALT использует свое собственное представление данных, оперирующее понятиями сущностей (Entities) и отношений между ними (Relationships). Каждой сущности и отношению соответствует определенный тип данных, описывающий их структуру - Entity Kind ( ЕК~) и Relationship Kind ДЕК). Например, для описания физического устройства задается сущность ЕК_ROUTER, которая содержит в себе всю необходимую информацию о роутере. Для описания логических интерфейсов введена сущность ЕК_INTERFACE, для физических портов ЕК_PORT. Далее, при помощи отношений эти сущности можно связывать друг с другом. Например, для того чтобы показать принадлежность логического интерфейса и физического порта какому-то конкретному физическому устройству, их можно соединить отношением - ЕК ROUTER - RК CONTAINS ^ ЕК INTERFACE _ _ _

(см. рис. 4). Эту же логику можно использовать для связывания сущностей различных уровней между собой - например, чтобы показать, что логический интерфейс принадлежит некоторому конкретному физическому порту, можно сделать такое отношение - ЕК-INTERFACE - RК_TRAVERSES ^ ЕК-PORT (см. рис. 4). Таким образом,

MALT позволяет описать всю топологию сети в наглядном и простом для понимания человека формате.

Для хранения MALT используется разработанная в Google распределенная реляционная база данных Spanner [14]. Однако поверх БД для работы с данными MALT был разработан свой уровень абстракции - MALTshop. MALTshop фактически является интерфейсом, который, с одной стороны, взаимодействует с базой данных, а с другой - обрабатывает поступающие от клиентов запросы, которые описываются при помощи специально разработанного языка запросов. Этот язык создает графовую абстракцию поверх традиционной реляционной СУБД для упрощения работы с данными.

Если подытожить, то Google на своем примере показал, что хранение топологии сети -очень важная часть автоматизации, а также что можно создать такие модели описания топологии сети, которыми будет удобно пользоваться. Отметим, что, к сожалению, разработанных моделей MALT нет в открытом доступе.

2.4.    Другие модели

Существуют и другие модели описания топологии сети. Одной из первых публичных систем, которая развивалась в направлении разработки модели и системы хранения данных для нее, была COOLAID [15]. Кроме того, многие крупные компании, подобно Google, так же разрабатывают системы, позволяющие работать с топологией сети. Среди них можно выделить: Statesman компании Microsoft [16] и Toposync компании Facebook [17].

Отдельно отметим, что в коммерческих системах, которые работают с многоуровневыми сетевыми топологиями, тоже, вероятно, используются модели описания топологии. Однако они, по понятным причинам, не публикуются. К таким решениям можно отнести IPFabric [18], Ciena BluePlanet [19], Cisco WAE [20], Juniper NorthStar [21] и другие. Некоторые авторы этих систем в том числе принимали участие в разработке RFC 8345 [1].

2.5.    Выводы

Подведем итоги обзора моделей описания топологии сети. В первую очередь отметим, что доступные в Open Source модели (IETF, ONF) обладают рядом недостатков и не получили должного распространения в сообществе. Вероятно, это могло произойти из-за оторванности этих моделей от жизни - без наличия инструментов, которые позволяют работать с этими моделями, без системного подхода к их составлению, без поддержки пользователей и работы над ошибками эти модели стали синтетическими исследованиями. Однако нельзя не отметить, что эти стандарты подняли ряд больших проблем и задали новое направление развития для отрасли.

В то же время разработка моделей систем мониторинга и управления сетевой инфраструктурой активно ведется крупными компаниями (Google, Microsoft, Facebook, Yandex), что говорит об актуальности этого направления и необходимости проведения новых исследований, а также в пересмотре и расширении открытых стандартов моделей описания топологии сети.

3.    Предлагаемая модель описания топологии сети

Перейдем к описанию предлагаемой модели описания топологии сети. За основу были взяты наработки компании Google и их модели MALT [3]. Описанная в работе модель представляет собой граф, в котором есть сущности заданных типов и отношения между ними. Модель делится на «уровни», каждый из которых соответствует типу информации, получаемой из системы сбора и мониторинга топологии конкретного протокола - в разбираемом в работе случае это протоколы OSPF и BGP. На каждом «уровне» топологии есть опорные точки (в случае OSPF и BGP - это сущности типа роутер). Эти опорные точки позволяют связывать различные уровни модели между собой. Далее в работе описываются модели топологии для уровней OSPF и BGP, а также приведена общая модель описания топологии, которая связывает их друг с другом. Все сущности модели описываются при помощи protobuf. Данный формат описания данных был выбран в качестве основного, т.к. он удобен в работе, сериализуемый и не зависит от языка программирования.

3.1.    Модель описания топологии OSPF Рис. 5. Модель описания топологии OSPF

Топология OSPF описывается при помощи следующих сущностей:

• 1)    OSPF_ROUTER

Сущность описывает опорный узел топологии OSPF - фактически является обозначением маршрутизатора OSPF. Содержит в себе только идентификатор маршрутизатора - адрес его Loopback интерфейса.

Идентификатор: OSPF _ROUTE R/routerlD

Листинг 4.1. Определение типа OSPF_ROUTER i message OSPF_ROUTER {

• 2    google.protobuf.Timestamp timestamp = 1;

• з    string routerID = 2;

• 4   }

• 2)    OSPF_PROCESS

Сущность описывает процесс OSPF, настроенный на маршрутизаторе. Содержит в себе всю информацию обо всех соединениях маршрутизатора в рамках одной OSPF Area, в том числе данные о количестве соединений, типе соединений (Stub, Transit, P2P), подсетях соединений, метриках OSPF на интерфейсах и т.п.

Идентификатор: OSPF_PROCESS nmUMD^rcalD

Листинг 4.2. Определение типа OSPF_PROCESS

i

message 0spfP2PLink { string linkID = 1;

string neighboringRouterlD = 2;

string routerlnterfaceAddress = 3;

uint32 metric = 4;

string associatedOspfStubLinkID = 5; } message OspfTransitLink { string linkID = 1;

string designatedRouterAddress = 2;

string routerlnterfaceAddress = 3;

uint32 metric = 4;

} message OspfStubLink { string linkID = 1;

хе

string networkAddress = 2;

string networkMask = 3;

uint32 metric = 4;

message OSPF_PROCESS { google.protobuf.Timestamp timestamp = 1;

string routerID = 2;

string arealD = 3;

string eventUUID = 4;

uint32 numOfLinks = 5;

repeated 0spfP2PLink ospfP2PLinks = 6;

repeated OspfTransitLink ospfTransitLinks = 7;

repeated OspfStubLink ospfStubLinks = 8;

• 3)    OSPF_LOGICAL_LINK

Сущность описывает логическое соединение OSPF между маршрутизаторами.

Содержит в себе информацию о статусе соединения (активно/неактивно), а также метрику OSPF. Создается на прямой и обратный пути для описания различий по метрикам, т.к. метрики на прямой и обратный пути не обязаны совпадать.

Идентификатор: OSPF _ LOGICAL _ LINK/srcRouterlD- dstRouterID:areaID:subNetwork

Листинг 4.3. Определение типа OSPF_LOGICAL_LINK

1	enum OspfLinkStatus {
2	OSPF LINK STATUS NULL = 0;
3	OSPF LINK STATUS INACTIVE = 1;
4	OSPF LINK STATUS ACTIVE = 2; A
5 6	J enum OspfLogicalLinkType {
7	OSPF LOGICAL LINK NULL = 0;
8	OSPF LOGICAL LINK P2P = 1;
9	OSPF LOGICAL LINK TRANSIT = 2;
10	OSPF LOGICAL LINK VIRTUAL = 3;
11 12	J message OspfTransitLinkAttributes {
13	string linkStatelD = 1;
14	uint32 networkMask = 2;
15	string advertisingRouter = 3;
16	repeated string attachedRouterlDs = 4;
17	1
18	message OSPF_LOGICAL_LINK {
19	google.protobuf.Timestamp timestamp = 1;
20	string sourceRouterlD = 2;
21	string destinationRouterlD = 3;
22	string arealD = 4;
23	string subNetworkIPv4 = 5;
24	string eventUUID = 6;
25	OspfLogicalLinkType ospfLogicalLinkType = 7;
26	OspfLinkStatus ospfLinkStatus = 8;
27	OspfTransitLinkAttributes ospfTransitLinkAttributes = 9;
28	1

Схема топологии, которая описывается моделью OSPF, изображена на рис. 5. Сущности OSPF _ROUTER порождают сущности OSPF _PROCESS. На одном OSPF_ROUTER в случае настройки нескольких Area OSPF может быть несколько

OSPF_PROCESS. Сами OSPF_PROCESS соединяются друг с другом при помощи OSPF LOGICAL LINK. _ _

Данная модель позволяет полностью описывать топологию OSPF и поддерживает LSA сообщения типов 1 (Router LSA) и 2 (Network LSA).

Отметим, что в текущей реализации модели не поддерживаются LSA типов 3 (Summary LSA) и 5 (External LSA), которые агрегируют информацию о подсетях из соседних OSPF Area или других протоколов (в частности, ISIS). Однако это не мешает точно описывать топологию OSPF.

3.2.    Модель описания топологии BGP

Рис. 6. Модель описания топологии внешней связности BGP

Топология внешней связности BGP описывается при помощи следующих сущностей:

• 1)    BGP_ROUTER

Сущность описывает опорный узел топологии BGP - фактически является обозначением маршрутизатора BGP. Содержит в себе только идентификатор маршрутизатора - адрес его Loopback интерфейса.

Идентификатор: BGP_ROUTER routerlD

Листинг 4.4. Определение типа BGP_ROUTER

• 1    message BGP_ROUTER {

• 2    google.protobuf.Timestamp timestamp = 1;

• з    string routerlD = 2;

uint32 asn = 3;

• 5   }

• 2)    BGP_NEXTHOP

Сущность описывает точку выхода маршрутов из сети - фактически пограничный маршрутизатор, который подключен к внешней автономной системе. Формируется на основе полученных анонсов маршрутов BGP по полю nexthop.

Идентификатор: BGP_NEXTHOP routerlD:asn

Листинг 4.5. Определение типа BGP_NEXTHOP

1 message BGP_NEXTHOP {

• 2 google.protobuf.Timestamp timestamp = 1;

з string nexthopID = 2;

uint32 asn = 3;

5   }

• 3)    BGP_WATCHER

Сущность описывает точку прослушивания сообщений BGP. Фактически каждый сосед компонента сбора маршрутной информации BGP, от которого система получает сообщения, описывается с помощью BGP_WATCHER. Эта сущность помогает отслеживать доступность соседей компонента сбора маршрутной информации BGP.

Идентификатор: BGP_W ATCHER/router!D:asn

Листинг 4.6. Определение типа BGP_WATCHER

• 1    message BGP_WATCHER {

• 2      google.protobuf.Timestamp timestamp = 1;

• з      string watcherlD = 2;

uint32 asn = 3;

5      string readerName = 4;

• 4 ) BGP _ AS

Сущность описывает внешние автономные системы BGP. Из сущностей этого типа формируется граф внешней связности сети.

Идентификатор: BGP_AS/asn

Листинг 4.7. Определение типа BGP AS

• 1    message BGP_AS {

• 2    google.protobuf.Timestamp timestamp = 1;

з uint32 asn = 2;

• 4   }

Схема топологии, которая описывается моделью внешней связности BGP, изображена на рис. 6. Сущности BGP_ROUTER порождают сущности BGP_NEXTHOP и BGP_WATCHER. Причем могут существовать следующие вариации соединений:

• 1)    BGP_ROUTER порождает только BGP_NEXTHOP. Такая ситуация означает, что данный BGP_ROUTER был получен в результате анонса BGP маршрута, полученного от некоторого маршрутизатора в сети. То есть с данным BGP_ROUTER система не устанавливала соседство и не знает всей его таблицы маршрутизации.

• 2)    BGP_ROUTER порождает только BGP_WATCHER. Такая ситуация означает, что данный BGP ROUTER является BGP Route Reflector и не имеет подключения _

к внешним автономным системам.

• 3)    BGP_ROUTER порождает ii BGP_WATCHER ii BGP_NEXTHOP. В этом случае BGP_ROUTER является пограничным маршрутизатором, и система точно знает его таблицу маршрутизации, т.к. она подключена к нему напрямую (с ним настроено соседство BGP).

Сущность BGP_NEXTOP соединяется с внешними автономными системами - сущностями BGP_AS. Отношения между BGP_AS (их направленность) обусловлены получением маршрута BGP, который содержал AS-Path вида: AS 1 ^ AS 3 ^ AS 4 (см. рис. 6).

Топология внутренней связности BGP описывается при помощи следующих сущностей:

Рис. 7. Модель описания топологии впутреппей связности BGP

• 1)    BGP_PROCESS

Сущность описывает процесс BGP на маршрутизаторе. Содержит в себе информацию об IP-адресах интерфейсов, настроенных на маршрутизаторе, через которые установлено соседство.

Идентификатор: BGP_PROCESS гоиРтИУанп

• 2)    BGP_LOGICAL_LINK

3.3. Общая модель описания топологии сети

Сущность описывает логическое соединение между процессами BGP на маршрутизаторах. Содержит в себе информацию о статусе соединения (активно/неактивно) Идентификатор: BGP_LOGICAL_LINK/srcRouterID:asn-dstRouterID:asn

Схема топологии, которая описывается моделью внутренней связности BGP, изображена на рис. 7. Сущность BGP_ROUTER порождает сущности BGP_PROCESS. а соединение между процессами BGP (TCP сессия) описывается при помощи сущности BGP_LOGICAL_LINK. Отметим, что эту модель возможно получить (наполнить данными) только при помощи BGP Monitoring Protocol или CLI.

Рис. 8. Общая модель описания топологии сети

Общая модель описания топологии сети изображена на рис. 8. Модель описывает топологию сети, используя несколько уровней абстракции - OSPF, BGP и L2. Опорные сущности уровней OSPF ( OSPF _ROUTER). BGP (BGP_ROUTER) ii L2 1.2 ROUT ER используются для объединения с сущностью «базового уровня» ROUTER. Таким образом, получается связь между различными уровнями топологии сети. Причем каждый из уровней топологии может существовать независимо от других, т.к. они собираются независимыми друг от друга инструментами и раздельно хранятся. О деталях реализации такого представления рассказано в разделе 4.

Однако для поддержания соответствия между уровнями недостаточно объединить друг с другом только опорные сущности, т.к. между уровнями существуют и другие связи, которые необходимо учитывать. Среди них, например, отображения процессов OSPF и BGP на логические интерфейсы сетевых устройств, т.е. на уровень L2. В разработанной модели, по аналогии с MALT [3], это реализовано путем использования специального типа отношений - Traverse. Оно указывает на соответствие между интерфейсами и логическими соединениями - например, логический интерфейс на уровне L2 может быть транспортом как для процесса OSPF (одного из интерфейсов, которые используются в OSPF), так и для процесса BGP (также для одного интерфейса, по которому установлено логическое соединение или в текущий момент времени проходит маршрут).

Обратим внимание на то, что подобная структура модели топологии позволяет довольно легко ее расширять и добавлять поддержку новых типов протоколов, уровней и связей. Кроме того, она достаточно наглядно описывает всю топологию, что, безусловно, упрощает работу с ней со стороны пользователей.

4.    Архитектера системы хранения топологии сети

Изображение архитектуры системы приведено на рис. 9. Вся система спроектирована на основе микросервисной архитектуры - каждый компонент системы представляет собой самостоятельный сервис. Такой подход позволяет добиться высокой масштабируемости системы для работы с высокими нагрузками.

bgp-model-api

ClickHouse

Events

Events

Dedic ated

NIC

Network

OSPF\ messages

Nebula

Graph DB gRPC query

ClickHouse

Nebula Graph DB gRPC queries network-model-api (Facade)

>gRPC

^queries gRPC REST

<     / daemon

HTTP REST queries pcap file

/ BGP messages gRPC stream

Events

Events,

Kafka ospf-event-consumer bgp-event-reader

Dedk ated ser/er ospf-event-reader bgp-event-consumer

Web-UI

Рис. 9. Общая архитектура системы

Инструменты сбора маршрутной ифнормации OSPF и BGP взаимодействуют с сетевыми устройствами, разбирают сетевые протоколы и передают данные в брокер сообщений Apache Kafka, который позволяет, с одной стороны, балансировать нагрузку на микросервисы, а с другой - не потерять данные в случае сбоя какого-либо из компонентов системы. Данные из Kafka читаются сервисами ospf-event-consumer и bgp-event-consumer. В их задачи входит группирование сообщений в батчи и их параллельная отправка в сервисы обработки и хранения маршрутной информации OSPF и BGP - ospf-model-api и bgp-model-api соответственно.

Сервисы обработки и хранения разбирают полученные сообщения, создают структуры данных, соответствующие модели описания топологии (OSPF и BGP), и записывают эти данные в БД - ClickHouse [22] и Nebula Graph [23]. Далее находится сервис network-model-api - с ним взаимодействует веб-интерфейс, а также он выступает в роли фасада к сервисам ospf-model-api и bgp-model-api, работает с их данными и скрывает логику их работы от пользователя.

4.1.    Подсистемы хранения топологии и телеметрии OSPF и BGP

Рассмотрим устройство подсистем хранения топологии и телеметрии на примере обработки протокола BGP (см. рис. 10). Процесс обработки OSPF построен аналогичным образом.

Обработка начинается с сервиса bgp-event-consumer (ospf-event-consumer для OSPF). Архитектурно он построен по принципу FanOut - один процесс считывает сообщения из брокера сообщений Kafka, группирует их в батчи, которые затем в несколько потоков отправляются в сервис обработки и хранения - bgp-model-api (ospf-model-api для OSPF). Отправка сообщений в сервис обработки и хранения производится по протоколу gRPC.

Сервис обработки сообщений устроен как классический сервер - он имеет gRPC и REST API (описанное в нотации OpenAPI) и обрабатывает запросы клиентов. Сервис построен на базе подхода «чистой архитектуры» (Clean Architecture), в котором вся логика работы приложения разделена на слои с интерфейсами - например, слой работы с базами данных обладает только публичным набором методов по работе с данными (загрузить данные в БД, выгрузить данные из БД и т.д.), таким образом скрывая реализацию хранилища.

Слой бизнес-логики сервиса устроен следующим образом: из пришедших на вход сообщений (OSPF, BGP) собираются структуры данных, соответствующие модели описания топологии сети. Далее эти данные записываются в базы данных. Система использует две базы данных -

Рис. 10. Архитектура подсистемы храпения топологии и телеметрии для протокола BGP

OLAP хранилище ClickHouse и OLTP хранилище Nebula Graph. Использование двух баз данных необходимо по следующим причинам:

• 1)    Nebula Graph - графовая база данных. В ней хранится «скелет» модели описания

топологии сети. В том же виде, что описано в разделе 3, толвко адаптированном под реализацию БД. Это позволяет сохранитв графовую структуру модели, что сильно упрощает работу с данными.

• 2)    ClickHouse - столбцовая база данных для хранения timeseries данных. Она используется для хранения всех событий в виде сырых логов. Поскольку в общем случае событий, которые приходят в систему, может быть достаточно много, то необходимо иметь производительное хранилище, предназначенное для хранения большого числа timeseries-данных. Графовые БД плохо подходят для такой задачи, поэтому для этих целей используется отдельная БД.

• 3)    Использование графовой БД в связке со столбцовой БД позволяет, с одной стороны, получить преимущества от хранения данных в виде графа, поскольку становится гораздо проще (по сравнению с реляционными СУБД) делать графовые запросы (например, осуществлять обходы графа). С другой стороны, полученные «скелеты» модели можно наполнять состояниями, которые получаются из ClickHouse. Таким образом реализовано версионирование модели топологии сети. Помимо этого, данные, которые хранятся в ClickHouse, можно визуализировать сторонними инструментами, в числе которых Grafana.

4.2.    Подсистема объединения моделей Рис. 11. Архитектура подсистемы объединения моделей

Далее, благодаря наличию API, сервисы bgp-model-api и ospf-model-api могут обрабатывать запросы от других сервисов. Например, по выгрузке топологии сети или аналитические запросы.

Подсистема объединения моделей (network-model-api) работает за счет осуществления запросов в сервисы хранения топологии и телеметрии (ospf-model-api, bgp-model-api). Общая архитектура изображена на рис. 11. Происходит это следующим образом:

• 1)    Предположим, что в подсистему объединения моделей приходит запрос от пользователя или веб-интерфейса: «показать полную топологию сети для OSPF и BGP в момент времени Т».

• 2)    Сервис обрабатывает полученный запрос и делает соответствующие запросы в сервисы хранения топологии и телеметрии (ospf-model-api, bgp-model-api) и получает от них топологию для выбранного сегмента сети в момент времени Т.

• 3)    После получения топологий от сервисов сервис network-model-api производит простейшее объединение топологий, используя опорные узлы

5.    Результаты тестирования

каждой из них. Если соответствие идентификаторов было найдено - результат (аналогичный изображенному на рис. 8) возвращается пользователю или на веб-интерфейс, который произведет рендеринг топологии и отобразит ее в виде графа.

Наличие подсистемы объединения моделей позволяет упростить логику работы с моделями описания сетевых топологий.

В рамках тестирования разработанной системы по хранению маршрутной информации протоколов OSPF и BGP на лабораторном стенде отслеживались следующие параметры:

• 1)    Корректное восстановление топологической связности сети. Проверка корректности осуществлялась визуально и путем чтения таблиц маршрутизации на маршрутизаторах.

• 2)    Корректное отслеживание состояния топологии при нарушениях связности. Нарушения связности моделировались при помощи отключения интерфейсов на маршрутизаторах. Для тестирования OSPF использовалось отключение одного из внутренних интерфейсов на маршрутизаторе, а для тестирования изменения внешних маршрутов BGP использовалось отключение интерфейса, подключенного к соседу из внешней автономной системы.

  

  12. Результат восстановления топологии OSPF и реакция на отключение интерфейса марш-

  рутизатора router-3

  
  

Рис.

External BGP connectivity Threshold 5%

У

О

В

О

172.20.22.1

-----------------1--------

28/10/2022,14:03 MSK

Play/Skip by 1 minute 27/10/202212:21 — 29/10/202212:21 MSIK

Рис. 13. Результат восстановления топологии BGP на диаграмме SanKey

Результаты тестирования восстановления топологии OSPF и реакция на отключение интер- фейса изображены на рис. 12. Более насыщенным цветом выделено то соединение, которое в выбранный момент времени было неактивно. Восстановленная топология сети полностью совпала с лабораторным стендом.

Результаты тестирования восстановления топологии внешней связности для BGP изображены на рис. 13. Для отображения использовалась диаграмма SanKey - на ней в процентном соотношении показано, какое количество префиксов выходит через граничные маршрутизаторы в сети.

В результате тестирования разработанная модель описания сети была провалидирована и доказана ее применимость для описания многоуровневых сетевых топологий на примере анализа протоколов динамической маршрутизации OSPF и BGP.

6.    Заключение

Задача автоматизации процессов управления сетями является одной из самых сложных в области телекоммуникаций - это обусловлено множеством факторов, в числе которых: отсутствие единой архитектуры построения сетей, большое количество различного оборудования и вендоров, огромное количество сетевых протоколов и т.д. Для того чтобы автоматизировать такую сложную структуру, необходимо создать абстракцию над ней -иными словами, нужен единый стандартизированный интерфейс, посредством которого будет осуществляться взаимодействие с сетевыми устройствами. Эту сложную задачу решает создание модели описания топологии сети. В рамках данной работы была предпринята попытка создать такую модель, руководствуясь опытом других исследователей. Помимо создания модели описания топологии была разработана система, которая позволяет работать с описанной в работе моделью и выступает для нее в роли инструментов заполнения и хранения данных. Разработанная система обладает высокой гибкостью и масштабируемостью, что обеспечивает возможность её легкого расширения для добавления поддержки новых протоколов, моделей или интеграции с внешними решениями по мере необходимости.