Мониторинг EVPN-фабрики и BGP. Часть 1

Привет, Хабр! Меня зовут Елена Сахно, я старший сетевой инженер в группе сетевых сервисов отдела сетевых технологий в Ozon. Наша команда отвечает за развитие и сопровождение сервисов, которые помогают отслеживать состояние сети, автоматизировать рутинные задачи, прогнозировать рост и своевременно оповещать коллег об аномальных событиях.

Мы снимаем сотни тысяч метрик и используем их, чтобы повысить стабильность работы нашей сети. В качестве источников метрик мы используем всем известные SNMP, телеметрию, логи, Netstream-статистику, скрипты, а с недавнего времени — протокол BMP.

На основе BMP мы запустили мониторинг EVPN-фабрики ЦОД, получили отличные результаты и хотели бы поделиться опытом. Статья будет интересна всем, кто имеет отношение к сетевым технологиям и протоколу BGP.

Наша история будет состоять из двух частей.

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

Во второй части подробно разберём решение, и посмотрим внимательнее на каждый компонент системы.

Почему важно мониторить состояние BGP?

В настоящее время протокол BGP уже является не только основным протоколом распространения маршрутной информации в сети Интернет, но и основным протоколом, на котором строятся распределённые корпоративные сети, сети провайдеров связи, огромные ЦОДы и фабрики.

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

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

Чего же мы ожидали от мониторинга BGP?

В первую очередь для нас была важна поддержка различных AFI/SAFI. BGPv4 с момента выхода первого стандарта RFC 4271 был доработан и в стандарте RFC 4760 получил расширение — MP-BGP, которое позволяет передавать не только адресную информацию IPv4 Unicast, но и обмениваться маршрутной информацией в других адресных пространствах (AFI/SAFI): EVPN, L3VPN, IPv6 и др.

Мы планировали отслеживать состояние BGP-сессий IPv4 и L3VPN, а также мониторить состояние EVPN-фабрики ЦОДа, которая у нас полностью построена на BGP. Поэтому мониторинг должен поддерживать IPv4, L3VPN и EVPN.

Мы хотели без задержек получать изменения состояния сессий MP-BGP в интересующих адресных пространствах. Т.к. разрыв BGP-сессии может привести к полной потере связности, а нестабильность BGP-сессий — к значительной деградации сервиса.

Кроме того, важно было знать, сколько анонсируется маршрутов каждому соседу BGP, а сколько принимается. Что помогло бы увидеть аномальные всплески, а также вовремя отследить приближение к настроенному лимиту разрешённых маршрутов.

Для отслеживания нетипичного поведения в сети, хотелось бы видеть общую статистику — сколько маршрутов было отозвано, сколько установлено в Local RIB, сколько маршрутов не прошли по причинам, не связанным с настройками политик маршрутизации: AS Path, Cluster List, Nexthop и т. д.

Ну и, конечно, получать с минимальной задержкой изменения всех входящих и исходящих маршрутов, не только тех, которые выбраны лучшими с точки зрения протокола BGP, но и маршрутов, полученных от BGP-соседа, но не прошедших политику маршрутизации, или прошедших политику, но не установленных в Local RIB.

Для чего история изменения маршрутов BGP может быть полезна?

• История изменения маршрутов по разным адресным пространствам позволит вернуться в период времени, в котором наблюдались проблемы в сети, и провести корреляцию событий;

• Поможет наглядно оценить, как изменения в политиках повлияли на маршруты, а также отследить ошибки конфигурации;

• История изменения EVPN-маршрутов поможет отследить события перемещения виртуальных машин, нестабильность в сети и её утилизацию.

Существующие решения для мониторинга BGP

Для организации мониторинга BGP уже давно существуют общепринятые подходы: SNMP, SNMP Trap, Logging, BGP-коллектор. Почему мы ищем новые инструменты? Чего не хватает в существующих?

SNMP

Мониторинг по протоколу SNMP — это самый часто используемый подход.

Мониторинг SNMP работает следующим образом: сервер с некоторой периодичностью отправляет SNMP-запросы на сетевое устройство по определённому идентификатору — OID. OID может иметь числовое или текстовое представление.

Простыми словами, OID — это идентификатор конкретной метрики, которую мы запрашиваем. К примеру, это может быть загрузка ЦПУ, количество переданных пакетов на определённом интерфейсе и т. д.

Сетевое устройство на запрос отправляет ответ с информацией, которую сервер интерпретирует при помощи специальных файлов — MIB. К примеру, мы отправили запрос о статусе BGP-сессии и получили в ответ единицу, а, заглянув в MIB, поняли, что единица соответствует статусу «Idle».

Одна из самых известных Open Source-систем мониторинга SNMP — Zabbix — позволяет отслеживать состояние BGP-сессий практически из коробки для популярных вендоров.

Но если сеть построена на разных вендорах, задача усложняется — каждый вендор использует разные OID, их необходимо сначала найти, при этом OID может меняться не только в зависимости от вендора и модели, но и от версии ПО. Поддержка того или иного OID может быть прекращена при обновлении устройства.

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

По SNMP можно получить статус сессии, общую статистику, но не полный список маршрутов, особенно если мы принимаем Full View или отслеживаем все маршруты внутри фабрики.

SNMP Trap

Протокол SNMP поддерживает особый вид пакетов Trap, который отправляется с устройства сразу при возникновении события.

Список поддерживаемых Trap сильно зависит от вендора и модели устройства, но Trap отчасти решают проблему задержки получения информации. Если нет задачи хранения истории изменения префиксов и получения более детальной информации, то мониторинг, основанный на SNMP и SNMP Trap, — это хорошее решение.

Logging

Если вендор не поддерживает отправку SNMP Trap для событий протокола BGP, можно попытаться отслеживать статус BGP-сессий в логах устройства. Но если выбирать между двумя подходами SNMP Trap и Logging, лучше использовать первое, т.к. задержка получения событий будет гораздо меньше.

BGP-сессия с коллектором

Хорошо зарекомендовало себя решение, основанное на получении копии BGP-маршрутов. Много коммерческих и Open Source-решений используют данный подход: сервер устанавливает BGP-сессию с сетевым устройством, получает все BGP-маршруты, разбирает полученные сообщения на поля и сохраняет их в базу данных.

Такое решение хорошо дополняет SNMP-мониторинг.

Но от BGP-мониторинга мы хотели большего — отслеживать не только лучшие маршруты, но и маршруты на разных этапах обработки: до и после применения политик маршрутизации.

И единственным решением, которое полностью удовлетворяло всем нашим требованиям и позволяло отслеживать маршруты на разных этапах обработки, стал протокол BMP (BGP Monitoring Protocol).

Первый стандарт протокола BMP вышел ещё в 2016 году, но назвать протокол популярным и повсеместно используемым пока нельзя.

Что такое BMP?

BGP Monitoring Protocol (BMP) — протокол, позволяющий:

• отслеживать состояние BGP-сессий на сетевых устройствах;

• получать все изменения (анонс, удаление, изменение атрибутов) BGP-маршрутов на всех этапах: до применения политики, после применения политики и после установки маршрутов в Local RIB;

• получать статистическую информацию по маршрутам.

Протокол BMP (BGP Monitoring Protocol) предназначен для мониторинга BGP-сессий и предоставляет удобный интерфейс для получения информации о маршрутах. Основной целью создания протокола была разработка удобного, простого в имплементации и не влияющего на сервисы компании протокола для мониторинга BGP.

BMP работает поверх TCP и в рамках одной сессии передаёт всю информацию на сервер (коллектор): статистику, все обновления, статусы сессий по всем BGP-соседям и по всем адресным пространствам, для которых включён мониторинг BMP.

Сессия BMP устанавливается исключительно с сетевого устройства до BMP-коллектора, коллектор никогда ничего не отправляет на сетевое устройство.

По протоколу BMP на коллектор передаются сообщения, очень похожие на BGP Update, но инкапсулированные и обогащённые дополнительной информацией. Кроме информации о маршрутах, по протоколу передаётся статистическая информация: сколько сообщений было анонсировано каждому соседу, сколько маршрутов прошли политики, сколько были отброшены по тем или иным причинам.

Как известно, протокол BGP использует разные таблицы для хранения маршрутной информации на разных этапах её обработки:

• Adj-RIB-In используется для хранения необработанной информации, полученной от BGP-соседей, т.е. до применения политик маршрутизации;

• Local-RIB — для хранения лучших маршрутов с точки зрения протокола BGP;

• Adj-RIB-Out — для хранения информации, отправляемой BGP-соседям с локального маршрутизатора, после обработки (применения политик).

Протокол BMP может отслеживать информацию не только по перечисленным выше таблицам BGP, но и на других этапах (назовём их отдельными таблицами BMP):

1. при получении обновления от соседа, до применения input policy — таблица Adj-RIB-In pre-policy;

2. при получении обновления от соседа, после применения input policy — таблица Adj-RIB-In post-policy;

3. после установки маршрута в Local RIB — таблица Local-RIB;

4. при отправке обновления к соседу, до применения output policy — таблица Adj-RIB-Out pre-policy;

5. при отправке обновления к соседу, после применения output policy — таблица Adj-RIB-Out post-policy.

   

Настройка мониторинга BMP обычно у разных вендоров простая и в то же время очень гибкая. На мониторинг можно добавить всех соседей в определённом адресном пространстве или указать отдельных BGP-соседей, по которым будет отправляться BMP-информация.

Задачей коллектора BMP является разбор приходящих сообщений, хранение и отображение аналитической информации. И благодаря стандарту, задача мониторинга BGP существенно упростилась, т.к. формат всех сообщений описан. Мы заранее знаем, что придёт и в каком виде.

Стандарты

1. RFC 7854 — первый стандарт, описывающий работу протокола BMP, вышел в июне 2016 года. Изначально BMP был предназначен для мониторинга маршрутов, приходящих от соседей BGP до применения политик маршрутизации (Adj-RIB-In pre-policy) и после применения политик маршрутизации (Adj-RIB-In post-policy). В RFC 7854 перечислены все типы сообщений, их формат и описана работа протокола.

2. Позже, в ноябре 2019 года, вышел RFC 8671, в котором было добавлено описание работы с таблицами Adj-RIB-Out и добавлены флаги, по которым можно определить, из какой таблицы получена информация Adj-RIB-In или Adj-RIB-Out, что позволило следить за маршрутами, не только получаемыми от соседей, но и за всеми отправляемыми обновлениями, а также проводить аудит исходящих политик маршрутизации.

3. В феврале 2022 появился дополнительный RFC 9069, в котором подробно описана процедура мониторинга Local RIB. Это позволило отслеживать изменения в таблице Local RIB т.к. входящие изменения маршрутов не всегда влекут за собой изменение таблицы Local RIB.

Формат сообщений

Протокол BMP использует всего 7 типов сообщений, два из которых относятся непосредственно к управлению сессией BMP: Initiation — установка BMP-сессии и Termination — завершение сессии.

Ниже приведено краткое описание каждого типа сообщений:

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

Первый пакет при установке BMP-сессии — Initiation. В нём содержится краткая информация о сетевом устройстве, с которого устанавливается BMP-сессия.

После установки сессии сетевое устройство отправляет сообщения Peer Up для всех BGP-соседей, которые добавлены на мониторинг и которые в настоящий момент активны.

Далее в сообщениях типа Route Monitoring отправляется полный дамп всех маршрутов по всем таблицам, для которых настроен мониторинг.

После этого отправляются только обновления по изменениям маршрутов (сообщения Route Monitoring) или по изменениям статусов BGP-соседей (сообщения типов Peer Up или Peer Down). С заранее настроенной периодичностью с сетевого устройства отправляются отчёты (Stats Report).

Для завершения сессии BMP используется сообщение типа Termination.

Ниже для всех, кто любит разбираться в деталях работы протоколов, описаны все подробности: форматы, заголовки пакетов и примеры дампов.

Общий заголовок

Все сообщения BMP имеют общий заголовок (Common Header), в котором указана версия протокола, длина сообщения и тип сообщения.

Per-Peer-заголовок

После общего заголовка у всех сообщений, кроме тех сообщений, которые предназначены для управления BMP-сессией, — Initiation и Termination, следует Per-Peer-заголовок, который несёт информацию о том, по какому BGP-соседу и по какой BGP-таблице пришла информация.

Ниже представлен формат заголовка. Таблица, по которой пришло сообщение BMP, определяется по флагам Peer Flags и по полю Peer Type, а BGP-соседа можно идентифицировать по оставшимся полям.

Для чего же еще используются флаги в заголовках Per-Peer?

В стандартах RFC по BMP описаны всего 4 флага. Флаги указывают тип таблицы, тип маршрутов, формат AS (2 или 4 байта).

Flag	Название	Значение
V/F	IPv6	Изначально флаг указывал на использование IPv6-адреса у BGP-соседа. C выходом RFC 9069 флагу дали ещё одно название — F и, если информация относится к мониторингу Local RIB (т.е. для Peer Type = 3), то данный флаг должен быть выставлен в единицу.
L	Post-Policy	Флаг, указывающий на то, что информация в сообщении относится к одной из таблиц post-policy. До выхода RFC 8671 флаг однозначно определял таблицу Adj-RIB-In post-policy.
A	AS Path	В сообщении используется 2-байтовый формат AS path.
O	Adj-RIB-Out	Флаг появился только в RFC 8671, с его помощью отмечаются все сообщения по таблицам Adj-RIB-Out.

Таким образом, по сочетанию флагов в заголовке Per-Peer можно определить однозначно таблицу, по которой пришло сообщение. Например, если L и O равны единице, то сообщение относится к Adj-RIB-Out post-policy.

А для идентификации сообщений по Local RIB используется Peer Type, равный 3, который был добавлен в RFC 7854.

Кроме Peer Type, равного 3, поле Peer Type может принимать следующие значения:

• 0 — BGP-соседство в глобальной таблице;

• 1 — BGP-сессия в VRF;

• 2 — локальная сессия;

• 3 — Local RIB.

Ниже приведен пример общего заголовка и Per-Peer-заголовка. В примере установлен только флаг post-policy, из этого следует, что получена информация по таблице Adj-RIB-In post-policy.

BGP Monitoring Protocol, Type Route Monitoring     Version: 3     Length: 96     Type: Route Monitoring (0)     Per Peer Header         Type: Global Instance Peer (0)         0100 0000 = Flags: 0x40, Post-policy             0... .... = IPv6: Not set             .1.. .... = Post-policy: Set             ..0. .... = AS PATH: Not set             ...0 .... = Adj-RIB-Out: Not set             .... 0000 = Reserved: Not set         Peer Distinguisher: 0:0         Unused: 000000000000000000000000         Address: 10.0.0.44         ASN: 42009140         BGP ID: 10.0.0.31         Timestamp (sec): 1726844377         Timestamp (msec): 324904     Border Gateway Protocol - UPDATE Message         .......

После заголовков следует сообщение указанного типа. Рассмотрим каждый тип подробней.

Initiation

Сессию BMP всегда инициирует сетевое устройство. По одной BMP-сессии передаётся информация обо всех BGP-соседях, добавленных на мониторинг.

Самым первым сообщением после установки TCP-сессии отправляется Initiation, оно содержит минимум информации и не содержит заголовок Per-Peer, т.к. информация относится к самой BMP-сессии, а не мониторингу BGP. Сообщение представляет собой набор TLV:

Ниже приведён пример сообщения Initiation, обычно сообщение включает два TLV: с описанием и с Hostname устройства.

Первые три строки — это ранее представленный общий заголовок, далее само сообщение Initiation, которое содержит набор TLV, на данный момент в RFC описаны только два типа TLV, и оба представлены в примере ниже.

BGP Monitoring Protocol, Type Initiation Message     Version: 3     Length: 215     Type: Initiation Message (4)     Information Types, Type sysDescr, Type sysName         Type: sysDescr (1)             Length: 181             Information: Routing Platform Software VRP (R) software, Version 87.2 (9006) Copyright (C) 2012-2022 Network Technologies Co.            Type: sysName (2)             Length: 20             Information: spine12.d911.stg 

Особенно важным для нас является TLV sysName, который содержит имя устройства (Hostname), инициировавшего BMP-сессию. Информация об устройстве, с которого была инициирована BMP-сессия, присутствует только в сообщениях типа Initiation.

Peer Up Notification

Для каждого BGP-соседа, который добавлен на мониторинг и находится в состоянии Established, после сообщения Initiation отправляются сообщения Peer Up, содержащие общий заголовок, Per-Peer-заголовок и информацию о BGP-сессии.

Если мониторинг настроен для Local RIB, то в качестве адреса BGP-соседа используется адрес 0.0.0.0.

Сообщения Peer Up Notification содержат копию отправленного и полученного BGP OPEN-сообщении при установлении BGP-соседства.

Последнее поле Information содержит дополнительную информацию о BGP-сессии, оно имеет формат TLV и является опциональным.

Ниже приведён пример сообщения Peer Up с общим и Per-Peer-заголовками и, как видно из примера, оно содержит полную копию BGP OPEN двух BGP-соседей, которые устанавливают сессию.

BGP Monitoring Protocol, Type Peer Up Notification     Version: 3     Length: 166     Type: Peer Up Notification (3)     Per Peer Header         Type: Global Instance Peer (0)         0000 0000 = Flags: 0x00             0... .... = IPv6: Not set             .0.. .... = Post-policy: Not set             ..0. .... = AS PATH: Not set             ...0 .... = Adj-RIB-Out: Not set             .... 0000 = Reserved: Not set         Peer Distinguisher: 0:0         Unused: 000000000000000000000000         Address: 10.0.0.44         ASN: 42009140         BGP ID: 10.0.0.31         Timestamp (sec): 1726844341         Timestamp (msec): 784000     Unused: 000000000000000000000000     Local Address: 10.0.0.45     Local Port: 179     Remote Port: 34020     Border Gateway Protocol - OPEN Message         Marker: ffffffffffffffffffffffffffffffff         Length: 45         Type: OPEN Message (1)         Version: 4         My AS: 23456 (AS_TRANS)         Hold Time: 180         BGP Identifier: 10.0.0.14         Optional Parameters Length: 16         Optional Parameters             Optional Parameter: Capability                 Parameter Type: Capability (2)                 Parameter Length: 14                 Capability: Multiprotocol extensions capability                     Type: Multiprotocol extensions capability (1)                     Length: 4                     AFI: IPv4 (1)                     Reserved: 00                     SAFI: Unicast (1)                 Capability: Route refresh capability                     Type: Route refresh capability (2)                     Length: 0                 Capability: Support for 4-octet AS number capability                     Type: Support for 4-octet AS number capability (65)                     Length: 4                     AS Number: 42009120     Border Gateway Protocol - OPEN Message         Marker: ffffffffffffffffffffffffffffffff         Length: 53         Type: OPEN Message (1)         Version: 4         My AS: 23456 (AS_TRANS)         Hold Time: 90         BGP Identifier: 10.0.0.31         Optional Parameters Length: 24         Optional Parameters             Optional Parameter: Capability                 Parameter Type: Capability (2)                 Parameter Length: 6                 Capability: Multiprotocol extensions capability                     Type: Multiprotocol extensions capability (1)                     Length: 4                     AFI: IPv4 (1)                     Reserved: 00                     SAFI: Unicast (1)             Optional Parameter: Capability                 Parameter Type: Capability (2)                 Parameter Length: 2                 Capability: Route refresh capability (Cisco)                     Type: Route refresh capability (Cisco) (128)                     Length: 0             Optional Parameter: Capability                 Parameter Type: Capability (2)                 Parameter Length: 2                 Capability: Route refresh capability                     Type: Route refresh capability (2)                     Length: 0             Optional Parameter: Capability                 Parameter Type: Capability (2)                 Parameter Length: 6                 Capability: Support for 4-octet AS number capability                     Type: Support for 4-octet AS number capability (65)                     Length: 4                     AS Number: 42009140

Peer Down Notification

Сообщение Peer Down отправляется при разрыве BGP-сессии. Сообщения этого типа содержат общий заголовок, Per-Peer-заголовок и информацию о причине завершения сессии BGP.

Если сессия BGP завершилась с отправкой Notification, то причина будет указана из Notification. Если Notification не было отправлено, то в качестве причины завершения BGP-сессии будет указано состояние FSM, которое вызвало окончание сессии.

Формат сообщения представлен ниже на схеме:

Далее пример сообщения Peer Down. Поле Reason равно 1, следовательно, в сообщении присутствуют дополнительные данные, уточняющие причину. В нашем случае это Administrative Reset.

BGP Monitoring Protocol, Type Peer Down Notification     Version: 3     Length: 70     Type: Peer Down Notification (2)     Per Peer Header         Type: Global Instance Peer (0)         0000 0000 = Flags: 0x00             0... .... = IPv6: Not set             .0.. .... = Post-policy: Not set             ..0. .... = AS PATH: Not set             ...0 .... = Adj-RIB-Out: Not set             .... 0000 = Reserved: Not set         Peer Distinguisher: 0:0         Unused: 000000000000000000000000         Address: 10.0.0.44         ASN: 42005140         BGP ID: 10.0.0.31         Timestamp (sec): 1727967772         Timestamp (msec): 455000     Reason: Local System, Notification (1)     Border Gateway Protocol - NOTIFICATION Message         Marker: ffffffffffffffffffffffffffffffff         Length: 21         Type: NOTIFICATION Message (3)         Major error Code: Cease (6)         Minor error Code (Cease): Administratively Reset (4)

Наличие причины в сообщениях типа Peer Down позволяет настроить уведомления разных уровней важности.

BGP Monitoring Protocol, Type Route Monitoring     Version: 3     Length: 96     Type: Route Monitoring (0)     Per Peer Header     Border Gateway Protocol - UPDATE Message         Marker: ffffffffffffffffffffffffffffffff         Length: 48         Type: UPDATE Message (2)         Withdrawn Routes Length: 0         Total Path Attribute Length: 20         Path attributes             Path Attribute - ORIGIN: INCOMPLETE                 Flags: 0x40, Transitive, Well-known, Complete                 Type Code: ORIGIN (1)                 Length: 1                 Origin: INCOMPLETE (2)             Path Attribute - AS_PATH: 42009140                  Flags: 0x40, Transitive, Well-known, Complete                     0... .... = Optional: Not set                     .1.. .... = Transitive: Set                     ..0. .... = Partial: Not set                     ...0 .... = Extended-Length: Not set                     .... 0000 = Unused: 0x0                 Type Code: AS_PATH (2)                 Length: 6                 AS Path segment: 42009140                     Segment type: AS_SEQUENCE (2)                     Segment length (number of ASN): 1                     AS4: 42009140             Path Attribute - NEXT_HOP: 10.0.0.44                  Flags: 0x40, Transitive, Well-known, Complete                     0... .... = Optional: Not set                     .1.. .... = Transitive: Set                     ..0. .... = Partial: Not set                     ...0 .... = Extended-Length: Not set                     .... 0000 = Unused: 0x0                 Type Code: NEXT_HOP (3)                 Length: 4                 Next hop: 10.248.254.44         Network Layer Reachability Information (NLRI)             10.0.1.31/32                 NLRI prefix length: 32                 NLRI prefix: 10.0.1.31

Stats Reports

На сетевых устройствах можно настроить отправку отчётов со статистической информацией, а также периодичность её отправки. При этом отчёты будут приходить по тем BGP-соседям, для которых настроен BMP-мониторинг.

Отчёты позволяют получить общую информацию о сессиях, которая будет очень полезна для отображения на графиках для оценки состояния сессий, а также для настройки алертов, если поведение начинает отличаться от среднестатистического. Из отчётов можно получить следующие счётчики по каждой BGP-сессии:

• Rejected Prefixes

• Duplicated Prefixes

• Duplicated Withdraws

• Invalid CLUSTER_LIST Loop

• Invalid AS_PATH Loop

• Invalid ORIGINATOR_ID

• Invalid AS_CONFED Loop

• Routes in Adj-RIB-In

• Routes in Loc-RIB

• Updates subjected to treat-as-withdraw treatment

• Routes in post-policy Adj-RIB-Out

И счётчики по разным адресным пространствам AFI/SAFI:

• Routes Adj-RIB-In

• Routes Loc-RIB

• Routes Adj-RIB-Out

Аналогично другим типам сообщений Stats Report начинается с общего заголовка и Per-Peer-заголовка.

Далее указано количество TLV в поле Stats Count:

Затем идёт набор TLV:

Ниже приведён пример сообщения Stats Report.

BGP Monitoring Protocol, Type Statistics Report     Version: 3     Length: 407     Type: Statistics Report (1)     Per Peer Header         Type: Global Instance Peer (0)         0000 0000 = Flags: 0x00         Peer Distinguisher: 0:0         Unused: 000000000000000000000000         Address: 10.0.0.44         ASN: 42009140         BGP ID: 10.0.0.31         Timestamp (sec): 1727967304         Timestamp (msec): 53918     Stats Count: 28     Type: Rejected Prefixes (0)     Type: Duplicate Prefixes (1)     Type: Duplicate Withdraws (2)     Type: Invalid CLUSTER_LIST Loop (3)     Type: Invalid AS_PATH Loop (4)     Type: Invalid ORIGINATOR_ID (5)     Type: Invalid AS_CONFED Loop (6)     Type: Routes in Adj-RIB-In (7)     Type: Routes in Loc-RIB (8)         Length: 8         Data: 0000000000000005         Number of routes in Loc-RIB: 5     Type: Updates subjected to treat-as-withdraw treatment (11)     Type: Routes in post-policy Adj-RIB-Out (15)     Type: Routes in per-AFI/SAF Adj-RIB-In (9)     Type: Routes in per-AFI/SAF Adj-RIB-In (9)     Type: Routes in per-AFI/SAF Adj-RIB-In (9)     Type: Routes in per-AFI/SAF Adj-RIB-In (9)     Type: Routes in per-AFI/SAF Adj-RIB-In (9)     Type: Routes in per-AFI/SAFLoc-RIB (10)     Type: Routes in per-AFI/SAFLoc-RIB (10)     Type: Routes in per-AFI/SAFLoc-RIB (10)     Type: Routes in per-AFI/SAFLoc-RIB (10)     Type: Routes in per-AFI/SAFLoc-RIB (10)     Type: Routes in per-AFI/SAFLoc-RIB (10)     Type: Routes in per-AFI/SAFLoc-RIB (10)     Type: Routes in per-AFI/SAFI post-policy Adj RIB-Out (17)     Type: Routes in per-AFI/SAFI post-policy Adj RIB-Out (17)     Type: Routes in per-AFI/SAFI post-policy Adj RIB-Out (17)     Type: Routes in per-AFI/SAFI post-policy Adj RIB-Out (17)     Type: Routes in per-AFI/SAFI post-policy Adj RIB-Out (17)

Информацию из статистических отчётов можно использовать на графиках для оценки состояния сессии во времени.

Termination

BMP-сессия завершается отправкой сообщения Termination, в котором указана причина разрыва сессии. Данный тип сообщений, как и Initiation, не включает Per-Peer-заголовок, т.к. сообщение относится не к BGP-соседу, а к состоянию сессии BMP. Формат сообщения полностью аналогичен Initiation и представляет собой набор TLV:

В RFC описаны два типа TLV, но на практике всегда приходит первый тип с причиной завершения BMP-сессии. Ниже приведён пример сообщения Termination:

BGP Monitoring Protocol, Type Termination Message     Version: 3     Length: 12     Type: Termination Message (5)     Termination Types, Type Reason         Type: Reason (1)         Length: 2         Reason: Session administratively closed (0)

Преимущества протокола BMP

Протокол BMP обладает существенным списком достоинств:

1. формат всех сообщений стандартизован;

2. минимальное влияние на сетевые устройства;

3. получение максимально подробной информации, которую невозможно получить оперативно доступными средствами;

4. периодическое получение сводной информации;

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

Проблемы нового протокола BMP

К сожалению, без недостатков не обошлось. Но все они временные и связаны с тем, что протокол пока не распространён повсеместно.

Поддержка вендорами IPv4-мониторинга

Если у вендора заявлена поддержка протокола BMP, то, вероятнее всего, это IPv4. Нами был протестирован протокол BMP на устройствах только двух вендоров, но многие другие известные вендоры также поддерживают мониторинг BMP IPv4.

Поддержка вендорами EVPN-мониторинга

На текущий момент одним из главных недостатков протокола BMP является его слабая поддержка у вендоров сетевого оборудования. К сожалению, пока нет поддержки мониторинга BGP EVPN у вендоров, оборудование которых мы используем. Для мониторинга EVPN-фабрики приходится использовать промежуточный сервис FRR, который имеет поддержку BMP EVPN.

Отсутствие готовых решений

Мы столкнулись с нехваткой готовых решений, которые поддерживают EVPN-мониторинг. Именно поэтому наш BMP-коллектор — это кастомизированный Open Source-проект.

Разночтения стандартов BMP

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

Основное отличие было в сообщениях типа Peer Up, Peer Down и Stats Reports. На сетевом устройстве был настроен мониторинг BMP одной сессии BGP, но для двух таблиц — Adj-RIB-In pre-policy и Adj-RIB-In post-policy.

Ожидаемое поведение было следующим:

• установка TCP-сессии с сетевого устройства до коллектора BMP;

• получение одного пакета Initiation о том, что BMP-сессия установлена;

• получение одного пакета Peer Up, т.к. настроен мониторинг одной BGP-сессии;

• получение Route Monitoring-сообщений для всех маршрутов по двум таблицам Adj-RIB-In Pre Policy и Adj-RIB-In Post Policy;

• периодическое получение одного Stats Report для наблюдаемой сессии.

Но у второго вендора поведение отличалось. Вместо одного сообщения Peer Up и одного Stats Report, мы стали получать их 2: для каждой из таблиц отдельно. В сообщениях отличались флаги, которые говорили, что сообщения относятся к разным таблицам.

При этом данные в Stats Report были разными. Счётчик Routes Loc-RIB для таблицы Adj-RIB-In pre-policy совпадал с числом маршрутов, которые пришли от соседа. И этот же счётчик для таблицы Adj-RIB-In post-policy уже показывал другое число, и оно действительно было равно количеству маршрутов, установленных в Local RIB.

Мы добавили на мониторинг третью таблицу Adj-RIB-Out pre-policy, и сообщений каждого типа стало приходить три. Но после добавления на мониторинг четвёртой таблицы Adj-RIB-Out post-policy, количество сообщений осталось равно трём.

Был открыт кейс у вендора, отправлены конфигурационные файлы, дампы трафика, схема, и проведены несколько очных сессий. После чего, пообщавшись с автором RFC, вендор сообщил, что есть некоторые разногласия в стандартах, описывающих протокол BMP, и в дальнейших версиях это будет сглаживаться.

В стандарте нет чёткого описания, сколько следует отправлять сообщений Stats Report и Peer Up/Down для каждого соседа, если настроен мониторинг нескольких таблиц. Возможно, со временем, когда протокол наберёт большую популярность, появится бОльшая согласованность в реализациях. Ну, а пока данную проблему удалось обойти — где-то за счёт базы данных, где-то за счёт отображения данных на доске и исключения лишней информации.

В стандарте также не регламентировано поведение протокола при разрыве BGP-сессии: должен ли маршрутизатор уведомить BMP-коллектор о неявных withdraw? Это отдаётся на откуп вендорам сетевого оборудования: “A Peer Down message implicitly withdraws all routes that were associated with the peer in question.  A BMP implementation MAY omit sending explicit withdraws for such routes.”

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

1. для таблиц Adj-RIB-In pre/post-policy и Adj-RIB-Out pre/post-policy неявный отзыв не происходит;

2. для таблицы Local RIB неявный отзыв маршрутов происходит.

И это вызывает сложности — необходимо закладывать в код дополнительную логику.

Итоговое решение

Несмотря на все трудности, с которыми мы столкнулись в ходе реализации проекта, нам удалось запустить в продакшн мониторинг EVPN-фабрики и IPv4, L3VPN BGP-сессий.

На схеме ниже представлено решение, которое сейчас мониторит всю EVPN-фабрику и внешние BGP-подключения в компании Ozon.

О том, как мы к этому пришли и почему выбрали в качестве базы данных Clickhouse, будет подробно рассказано во второй части статьи.

Итого, как выглядит наша система мониторинга.

1.      Наш кастомизированный BMP-коллектор, который получил имя bmp-collector, развёрнут в Kubernetes на трёх подах. Подключение к нему осуществляется по общему виртуальному адресу Kubernetes Cluster IP.

• Если ставим на мониторинг те NLRI, которые поддерживаются сетевым устройством, сессия BMP устанавливается с сетевого устройства до коллектора BMP;

• если хотим мониторить EVPN, настраиваем промежуточный сервер FRR, с которого получаем все обновления по протоколу BMP.

2.      Основная задача bmp-collector — принять пакет, разобрать на поля, сформировать сообщение в формате JSON и отправить в шину данных Kafka, которая сглаживает всплески сообщений.

3.      Нам понадобился дополнительный сервис bmp-inserter, который читает из топиков Kafka сообщения и отправляет их в Clickhouse. В нашем случае этот сервис помогает ещё и обогатить данные. Он написан нами на Go, но его можно заменить дополнительной таблицей Clickhouse с движком Kafka, если у вас нет ограничения на его использование.

4.      Данные попадают сначала в основные таблицы базы данных Clickhouse, в которых хранится полная информация, т.е. вся история изменения состояния BGP-сессий и префиксов:

• таблица «peer» содержит информацию о всех событиях Peer Up/Down,

• таблица «prefix_v4» — информацию по префиксам IPv4, получаемую из BMP-сообщений типа Route Monitoring,

• таблица «evpn» хранит историю изменения EVPN-префиксов,

• таблица «statistics» — всю информацию, получаемую из BMP-сообщений типа Stats Report.

Всё это исторические данные. После этого через материализованное представление данные попадают в таблицы с текущим состоянием BGP-соседей и таблиц: peer_current, prefix_v4_current, evpn_current.

5.      Весь алертинг и отображение графиков в Grafana осуществляются через запросы в Clickhouse, но в ближайших планах написать API для сервиса.

Практическое использование BMP

BMP позволяет собирать огромный объём информации. Рассмотрим несколько наиболее интересных кейсов применения. Для удобства они разделены на две части — кейсы применения BMP в мониторинге EVPN-фабрики и  кейсы мониторинга IPv4, L3VPN.

Мониторинг EVPN

Утилизация сетей

При помощи сбора статистики BMP у нас появилась возможность отслеживать, насколько утилизированы те или иные сети, как давно был в сети определённый MAC- или IP-адрес, сколько и когда было анонсировано и отозвано адресов, входящих в определённый префикс.

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

История изменения префиксов

На доске с историей изменения префиксов доступны различные фильтры для удобства поиска, все префиксы и MAC-адреса имеют ссылку, которая устанавливает выбранный префикс или MAC-адрес в качестве фильтра, что позволяет увидеть полную историю его изменения.

MAC mobility и флаппинг адресов

Мы видим, как часто в фабрике анонсируются и отзываются адреса, видим счетчики MAC Mobility, к которым обычно обращаются в последнюю очередь, когда уже возникла проблема и все другие причины проверены.

Ниже приведен пример диаграмм, которые отображают топ-10 нестабильных адресов:

Дальше приведены графики, показывающие, сколько было анонсировано и отозвано маршрутов за 5 минут по каждому из VLAN и по каждому коммутатору. По графикам можно отслеживать аномальное поведение в сети:

Multicast MAC-адреса

BMP позволяет следить, не появились ли в сети Multicast MAC-адреса. Обычно эта доска пустая:

Type 2 внутри Type 5-маршрутов

С мониторингом появилась возможность вовремя обнаружить анонс Type 2 EVPN-маршрута, который входит в сеть, анонсированную как Type 5 EVPN.

Мониторинг IPv4 и L3VPN Состояние и статистика BGP-сессий

Все изменения состояния BGP-сессий приходят на BMP-коллектор сразу после их возникновения, это позволяет оперативно отреагировать на события. Мы можем посмотреть, сколько и каких маршрутов было анонсировано и отозвано в любой момент времени, найти часто изменяющиеся маршруты, проверить их историю изменения.

Дополнительную информацию о стабильности сети мы получаем из статистических отчётов — BMP-сообщений типа Stats Report, которые показывают, сколько было анонсировано, отозвано, установлено или не установлено по какой-либо причине маршрутов.

Всю информацию о статусе сессий BGP мы собрали в отдельную доску. На ней отображается: топ-10 нестабильных префиксов, у которых либо часто меняются атрибуты, либо они отзываются и повторно анонсируются, общая статистика по BGP-сессии и история изменения состояния BGP-соседа.

История изменения маршрутов

Отдельная доска с различными фильтрами используется для просмотра истории изменения BGP-префиксов, как и на аналогичной доске для EVPN, доступны быстрые фильтры по клику на любой префикс.

Результат применения политик маршрутизации

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

Мониторинг и алертинг

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

Дальнейшие планы

API сервиса

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

API позволит использовать получаемые данные по протоколу BMP как источник обогащения в других системах. В то же время повысится безопасность сервиса и за счёт межсервисной авторизации, и за счёт того, что прямой доступ в базу данных будет закрыт.

Использование BMP в проекте Network as Code

Во время централизованной настройки нескольких сотен устройств такими инструментами, как Network as Code, очень важным становится тестирование применяемой конфигурации и одним из инструментов, позволяющим оперативно отреагировать на изменения, является сервис мониторинга BMP. При любых изменениях политик BGP BMP-мониторинг поможет оценить их корректность.  

Мониторинг и алертинг

В планах подготовка описания текущей модели сети, её штатного состояния, правил реагирования при отклонении и самовосстановлению при наличии такой возможности.

Сервисы для пользователей

Уже сейчас работает внутренний сервис Looking Glass, который позволяет оперативно проверить историю изменений префикса и провести корреляцию между проблемой и произошедшими изменениями в сети.

Но в планах есть и создание других досок, которые будут показывать стабильность префикса, визуализировать путь прохождения трафика между точками А и Б и др.

Заключение

Статья была написана, чтобы собрать воедино всю информацию о протоколе BMP, чтобы как можно больше людей узнали о нём, задумались об использовании протокола BMP в своей инфраструктуре, а, возможно, и реализовали похожий проект, но уже с меньшими временными затратами. BMP — это действительно удобный и полезный инструмент, который добавляет большие возможности для мониторинга, автоматизации и аналитики.

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

По кусочкам мы собирали систему, тестировали её, переделывали, снова тестировали, вносили изменения, работали над кейсами применения.

Сейчас, выведя систему в продакшн, с уверенностью можем сказать, что система полностью оправдала наши ожидания. С BMP мы получили очень гибкий и мощный инструмент, который пока не используем на все 100%, но с каждым днём появляются новые задачи, которые мы успешно решаем при помощи BMP.

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