Привет! Меня зовут Борис Хасанов — ведущий сетевой архитектор в MWS. Работаю с сетями уже много лет, а последнее время занимаюсь сетевой телеметрией. Она помогет мониторить состояние сети облака в моменте.

Это первая статья из цикла о трендах в развитии сетевой телеметрии и её имплементации в облаке MWS. Идея цикла появилась из моего несостоявшегося доклада на сетевой конференции «Яндекс nexthop 2024». Хочу поблагодарить Антона Корнелюка, Евгения Зобницева, коллег из MWS, а ещё коллег из IETF за идеи для этого цикла статей.

Сегодня расскажу о фреймворке ОАМ, его механизмах и протоколах и как он помогает следить за сетью. Итак — начинаем.

Как мы жили раньше, или что такое ОАМ

Предлагаю сразу определиться с терминами, что же мы понимаем под телеметрией.

Телеметрия (от др.-греч. τῆλε «далеко» + μέτρεω — «измеряю») — область науки и техники, занимающаяся вопросами разработки, эксплуатации, приёма, обработки и регистрации измерительной информации о различных событиях с целью контроля на расстоянии различных объектов и процессов

Вдумчивый читатель тут может усмехнуться и сказать про себя — мы и так это знаем, что же тут нового?

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

В 2000-х годах телеком-индустрия стала использовать механизм (framework) OAM: Operation, Administration and Maintenance для мониторинга состояния сети.

Рассмотрим ОАМ подробнее, так как, чтобы понять векторы развития телеметрии, нам нужно ознакомиться с теми инструментами, которые были до неё и продолжают использоваться.

Я нарисовал следующую схему, описывающую базовую архитектуру и основные компоненты сетевого OAM, на которых остановлюсь подробнее:

Начнём с двух главных компонентов ОАМ: модуля оценки (управления) производительностью и модуля оценки сбоев. Они, как видно из названия, информируют о производительности сети и сбоях. Эти два основных модуля делятся на подмодули. В состав модуля оценки производительности входят следующие подмодули:

— измерения задержки (DM);

— измерения потерь (LM);

— измерения пропускной способности (TM).

Если посмотреть на левый нижний угол схемы, то можно увидеть важный момент, что оценка производительности классифицируется по способу реализации:

— Активная оценка: модуль ОАМ посылает специальные пакеты с узла источника, а на узле назначения подсчитывает их количество и другие характеристики.

— Пассивная оценка: используются «обычные» пакеты, которые передаются во какую-либо внешнюю систему для оценки.

— Гибридная: сочетание обоих способов. Подробнее об этих способах я расскажу ниже.

В состав модуля оценки сбоев входят два подмодуля:

— проверки связности (CC);

— верификации связности (CV).

Средства и протоколы в ОАМ

Механизмы и протоколы, которые используются для оценки сбоев (FM)

Для проверки связности мы используем утилиту ping, кстати, она появилась ещё в 1983 году. Ping использует Internet Control Message Protocol (ICMP-сообщения ICMP Echo Request/Reply) и позволяет проверить IP-связность до заданного IP-адреса, а ещё измерить двустороннюю задержку (Round Trip Time — RTT). Кроме того, при использовании в сетях с Multiprotocol Label Switching (MPLS) и, в частности, в сетях MPLS-TE в утилиту ping добавили возможность проверять достижимость заданного IP-адреса не через использование маршрутизации на основе IP, а через использование Label Switch Path (LSP). Для любителей истории рекомендую почитать про возникновение утилиты ping.

Для верификации пути до заданного IP-адреса мы традиционно используем утилиты tracert (использует протокол ICMP) или traceroute (использует UDP). Принцип работы обеих утилит хорошо известен, поэтому напомню его очень коротко: в tracert узел источник посылает серию пакетов с увеличивающимся полем Time to Live (TTL), начиная с TTL=1, каждый маршрутизатор на пути, получив такой пакет, уменьшает TTL (который становится равным 0) и посылает в обратную сторону ICMP-сообщение Time Exceeded. Таким образом, узел источник получает эти сообщения от каждого узла на пути и узнаёт IP-адреса этих маршрутизаторов. Последним же будет узел назначения, который, увидев свой адрес в поле DA заголовка IP-пакета, пошлёт в ответ сообщение ICMP Echo Reply.

В traceroute, использующей UDP, посылается фрагмент, как правило, на destination port из диапазона > 30 000 (например, 33 434) и затем также каждый узел на пути уменьшает TTL и возвращает сообщения Time Exceeded. Когда фрагмент достигнет узла назначения, то он, опознав свой адрес в поле DA, отправит фрагмент для обработки и вернёт в ответ сообщение ICMP Port Unreachable (ICMP Type 3 Code 3). Утилита traceroute также была расширена для использования в MPLS/Segment Routing сетях.

Отдельный механизм, широко используемый в сетях для проверки связности (СС), — это Bidirectional Forwarding Detection (BFD). BFD может использоваться в самых различных сценариях: начиная от проверки связности через линк и заканчивая проверкой отношений соседства в протоколах маршрутизации (IGP: ISIS, OSPF и BGP) и сетях с MPLS и MPLS-TE, SR-MPLS, SRv6.

В рамках OAM и модуля оценки сбоев (FM) нас в первую очередь интересует работа BFD для проверки физического линка или туннеля (single hop), этот алгоритм работы описан в [RFC 5881]. Прелесть BFD также заключается в том, что мы можем использовать и multihop BFD [RFC 5883] для диагностирования сбоев между удалёнными друг от друга узлами.

Причина такого широкого использования BFD: он позволяет обнаружить проблемы со связностью гораздо быстрее протоколов, которые используют механизм Hello-пакетов, например, некоторые имплементации поддерживают достаточно «агрессивные» значения таймера (minimum interval) по отправке BFD-пакетов, например в 3,3 мс. Использование таких таймеров требует аппаратной обработки BFD-пакетов на линейной карте маршрутизатора — BFD hardware offloading или distributed BFD.

Существует огромное количество имплементаций BFD, как на вендорских платформах (маршрутизаторы, коммутаторы), так и Open Source (FRR, Bird).

Хочу также кратко напомнить, что, несмотря на кажущуюся простоту BFD, этот протокол имеет достаточно сложную машинерию с переходом различных состояний:

Поэтому вполне обоснованно желание её упростить и как результат — ускорить, что и было сделано при создании упрощённого варианта BFD: S-BFD (Seamless BFD).

RFC 7881 делает некоторые важные уточнения в части S-BFD, в частности определяет UDP-порт 7784. Объективно говоря, поддержка S-BFD присутствует на меньшем количестве имплементаций сегодня, но это тонкая материя, поэтому для уточнения поддержки S-BFD — спрашивайте у вашего вендора.

Механизмы и протоколы, используемые для оценки задержек и потерь (DM, LM)

Первый и самый очевидный механизм — ping, про который мы говорили выше. Однако у него есть несколько известных ограничений:

— необходимость периодического запуска (вручную или средствами автоматизации);

— измерение только RTT (невозможность отследить асимметрию задержки);

— сбор результатов либо через screen scraping, либо по SNMP.

Поэтому в индустрии появились дополнительные механизмы, в виде специальных протоколов, например: Two-Way Active Measurement Protocol (TWAMP).

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

Протокол TWAMP

TWAMP — протокол, который используется для Performance Management (PM) в целом и для DM, LM в частности. Он появился как дальнейшая эволюция протокола OWAMP (One-Way Active Measurement Protocol) в 2008 году. TWAMP — обеспечивает активное измерение (путём посылки специальных тестовых UDP-пакетов) двусторонней задержки (RTT) и потерь пакетов (packet loss).

TWAMP состоит из четырёх логических компонентов: Session-Sender, Session-Reflector, Control-Client, Server. В свою очередь эти логические компоненты делятся на control plane (Control-Client, Server), которая отвечает за инициализацию тестовой сессии, её запуск и остановку, а ещё на data plane (Session-Sender, Session-Reflector), где Session-Sender отправляет тестовые пакеты, а Session-Reflector отвечает на них.

Control plane использует TCP, а data plane — UDP (поддерживается аутентификация и шифрация). Логически взаимодействие компонентов выглядит более понятным на этой схеме:

Как видно из схемы, управляющий центр в TWAMP — Control-Client.

Надеюсь, что вдумчивый читатель также оценил сложность (complexity), заложенную в TWAMP изначально, что, конечно, не помешало появиться большому количеству имплементаций, но и не упростило им жизнь, равно как и его практическое использование.

Неудивительно, что в индустрии сразу же возникло, ещё при разработке TWAMP, желание его упростить и в IETF (www.ietf.org — Инженерный совет Интернета), в стандарте RFC 5357, описывающем TWAMP, появилось отдельное приложение, которое упоминает его «облегчённую» версию TWAMP-Light, что, вообще-то, не частый случай, когда в одном и том же стандарте предлагается как основной вариант, так и упрощённый.

В чём же отличие TWAMP-Light от TWAMP? Нагляднее всего это будет видно на схеме:

Во-первых, три основных компонента (Server, Control-Client, Session-Sender) объединяются в одну логическую сущность — controller (контроллер), а Session-Reflector — в responder (ответчик). И тут мы получаем первое, очень значимое, преимущество TWAMP-Light — отсутствие необходимости согласовывать параметры тестовой сессии между controller и responder через control plane, то есть мы используем только data plane. Но Responder только принимает тестовые пакеты от контроллера и отвечает на них. Как же TWAMP-Light поможет нам измерить различные варианты задержки? Посмотрим на схему ниже.

Задержка от R1 до R2 = T2 − T1
Задержка от R2 до R1 = T4 − T3
RTT = (T2 − T1) + (T4 − T3)

Таким образом, TWAMP-Light, как и TWAMP, позволяет мерить все варианты задержек (в отличие от ping), что очень важно с учётом асимметрии задержек в сети.

С учётом сказанного, на практике имеет смысл при выборе между TWAMP и TWAMP-Light использовать именно последний, конечно, если ваше оборудование поддерживает его.

Практически у всех наиболее известных сетевых вендоров имеются имплементации TWAMP/TWAMP-Light для разного оборудования, ещё есть и Open Source. Я тестировал межвендорское взаимодействие (interoperability) TWAMP-Light между оборудованием трёх таких вендоров, «нюансы» были только у одного из них.

Для конфигурации TWAMP/TWAMP-Light-сессий на оборудовании мы можем воспользоваться такими вариантами, как традиционный CLI и/или Netconf со специализированной Yang-моделью. Таким же образом мы можем получать собранные TWAMP-Light результаты измерений задержки и потерь пакетов (DM, LM, TM) для OAM.

Протокол STAMP (Simple Two-Way Active Measurement Protocol)

С момента появления TWAMP-Light прошло уже более 10 лет, и за это время наша отрасль накопила большой опыт его эксплуатации. Теперь мы можем подвести некоторые итоги. Они показали, что сложность архитектуры, изначально заложенная в TWAMP, усложняет его эксплуатацию, а недостаточно чётко прописанные в стандарте рекомендации по эксплуатации TWAMP-Light, а также его совместное использование с другими приложениями затрудняют его эксплуатацию, особенно в мультивендорных вариантах. Например, в процессе собственного тестирования TWAMP-Light на оборудовании трёх очень известных вендоров у меня не заработал сценарий, когда один из вендоров был в роли TWAMP-Light контроллера, а два других были ответчиками (responder).

Поэтому, чтобы преодолеть эти противоречия, коллеги задумались над созданием ещё более простого и детерминированного протокола для активного мониторинга производительности (РМ) в ОАМ. Так в рабочей группе IP Performance Monitoring IETF и появился STAMP. Рассмотрим его сходства и отличия от TWAMP подробнее.

Мы видим существенно упрощённую в отличие от TWAMP архитектуру. Здесь нет контроллера, как и control plane в целом, сервера, распределённости этих логических модулей. Есть только отправитель тестовых пакетов (Session-Sender) и их отражатель (Session-Reflector). Конфигурация и управление сессиями осуществляются с внешнего модуля конфигурации и управления — это может быть CLI, управляющий хост с «питонячьим» скриптом с ncclient, OSS/BSS, SDN-контроллер с Netconf/Yang и так далее.

STAMP Session-Reflector может работать в двух режимах: Stateless и Stateful. В Stateless-режиме, как видно из его названия, отражатель не хранит никакого состояния, соответственно, Sequence number на входящем и исходящем будет одним и тем же. И мы сможем измерить только двустороннюю (общую) потерю пакетов (round trip packet loss). Очевидно, что это наиболее простой и наименее нагрузочный режим работы.

В Stateful-режиме отражатель поддерживает состояние сессий и поэтому отправитель (Session-Sender) при помощи комбинации полей Session Sender Sequence Number и Sequence Number может определить любой тип задержки и потерь.

Стандарт чётко задаёт, что по умолчанию для приёма STAMP-пакетов обязан использоваться UDP-порт 862 с возможностью его последующего изменения. Также заданы разные типы пакетов, отправляемых Session-Sender и Session-Reflector. Поддерживаются аутентифицированный и не аутентифицированный режимы.

Важно, что STAMP изначально проектировался совместимым с протоколом TWAMP-Light, причём в обоих вариантах:

— STAMP Session-Sender > TWAMP Light Session-Reflector.

— TWAMP Light Session-Sender > STAMP Session-Reflector.

Для того чтобы STAMP мог использоваться с разными протоколами, предложили механизм (framework) его расширения при помощи TLV — это существенное преимущество. Также стандарт даёт список используемых TLV.

Как одно из прикладных направлений использования, STAMP также имеет расширения для работы в сетях с Segment Routing (SR-MPLS, SRv6), и это ещё одно принципиальное отличие от TWAMP/TWAMP-Light.

Расширения STAMP для SR, в частности Return Path TLV, позволяют запрашивать у Session-Reflector отправку тестового пакета через определённый обратный путь (Segment List в терминах SR), соответственно, рефлектору нет необходимости хранить состояние.

Сам Segment List кодируется при помощи SR-MPLS/ SRv6 Label Stack Sub-TLV в Return Path Sub-TLV.

Более подробно процедуры использования STAMP для мониторинга производительности (РМ) в сетях с SR описаны протоколе для измерения производительности в сетях с сегментной маршрутизацией, в частности, там дана целевая архитектура использования STAMP, на которую стоит обратить внимание:

Контроллер передаёт на Session-Sender основные параметры тестовой сессии:

режим измерения, в данном случае — двухсторонний, номер порта назначения (по умолчанию UDP/862), формат таймстампа (NTP или 1588v2), тип метрики:

• общая задержка (RTT);

• односторонняя задержка;

• задержка на ближнем и дальнем конце;

• общие потери;

• односторонние потери;

• потери на ближнем и дальнем конце.

Для конфигурации контроллер может использовать специализированную Yang-модель и по ней же получать состояние тестовых сессий, используя телеметрию, про которую мы поговорим дальше. Надо отметить, что в дизайне STAMP изначально заложена возможность корректной работы через LAG при помощи Micro-Session ID TLV для корректной идентификации конкретного линка в LAG.

Мы кратко прошлись по возможностям использования STAMP в сетях с SR, чтобы подчеркнуть его возможности и отличия от более привычного нам TWAMP/TWAMP-Light. Но мой обзор этих протоколов не будет полным, если я не затрону вопрос использования STAMP для мониторинга Traffic Engineering в SR, в частности SR Policy, про которую я подробно рассказывал в своей статье на Хабре.

Посмотрим ещё раз, как кодируется тестовый STAMP-пакет от Session-Sender в случае SR.

Непосредственно перед пакетом STAMP есть некий PSID, что же это такое? Это Path Segment Identifier — недавно стандартизованный новый тип SID в SR, идентифицирующий определённый путь (Segment List), он необходим исходящему узлу (egress node, tail-end) для понимания того, каким путём шёл пакет, т. к. идентификаторы сегментов (метки, SID) удаляются либо меняются (pop, swap) в процессе транзитными узлами. В случае SR Policy PSID может идентифицировать либо Segment List, либо Candidate Path.

Полагаю, что вы уже догадались, как будет выглядеть тестовый STAMP-пакет, если мы делаем измерения для сервиса, например L3VPN.

Посмотрев рисунок выше, уже можно сделать некоторые выводы по сравнению TWAMP/STAMP, но мы вернёмся к этому вопросу чуть позже.

Теперь то же самое для SRv6, тут мы увидим вариативность в зависимости от того, какой тип IPv6/SRH инкапсуляции будет использоваться, — H.Insert/H.Encaps.

Для краткости я не буду приводить схему для передачи пакета STAMP L3VPN-сервиса поверх SRv6, потому что её отличие от двух последних схем будет только в том, что в заголовке SRH в поле будет Segment List[0] = End.DT6/End.DT46 SID.

Для обратных пакетов от Session-Reflector по умолчанию используется IP-инкапсуляция (IP-UDP-STAMP Payload). Как я говорил выше, по запросу Session-Sender, Session-Reflector будет использоваться тот же путь, что и первичный пакет.

Хочу отметить, что в случае TE c SR Policy, когда в активном Candidate Path будет несколько активных Segment List (например, для ECMP/w-ECMP), в случае использования STAMP с расширениями для SR будет несколько (по количеству Segment List) STAMP-сессий.  

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

Результаты сравнения этих протоколов я свёл в таблицу.

Альтернативная маркировка — ещё один механизм РМ

Концепция альтернативной маркировки может использоваться для любого типа трафика (unicast, multicast, MPLS и т. д.). Её суть в следующем: трафик определённого flow делится на блоки, которые «раскрашиваются» определённым цветом, так чтобы идущие подряд блоки имели одинаковый цвет. Можно как использовать фиксированное количество блоков на цвет, так и передавать блоки одного цвета в течение заданного времени.

Пример такой раскраски:

Входящий и исходящий маршрутизаторы на основе счётчика на интерфейсе подсчитывают пакеты определённого цвета, простым вычитанием мы можем узнать количество потерянных пакетов. Аналогичным образом, записывая timestamp первого пакета в блоке при смене цвета, можно измерять одно- и двухстороннюю задержки, однако для этого нам необходимо синхронизировать маршрутизаторы по NTP или 1588v2.

Большое преимущество использования альтернативной маркировки по сравнению с другими протоколами (TWAMP, STAMP) — мы не делаем измерения при помощи дополнительных тестовых ОАМ-пакетов, посылаемых в сеть в надежде, что они последуют путём нужного нам flow, а маркируем (раскрашиваем) непосредственно сами нужные flow трафика.

Классификация ОАМ Performance management по типу измерений

На самой первой схеме показана важная часть общей архитектуры ОАМ, связанная с вариантами организации измерений или тестов, их может быть три:

— Активный РМ: устройство посылает в сеть тестовые ОАМ-пакеты, примеры этого TWAMP, TWAMP-Light, STAMP.

— Пассивный РМ: устройство только анализирует трафик и экспортирует его для анализа в какое-то внешнее устройство, например при помощи IPFIX.

— Гибридный РМ: сочетание первых двух вариантов (альтернативная маркировка относится именно к гибридному РМ).

Более подробно почитать про различные варианты измерений можно тут.

Заключение

Итак, мы ознакомились с архитектурой ОАМ и теми механизмами и протоколами, которые лежат в её основе. На первый взгляд, может показаться, что, внедрив в сети ОАМ, мы уже закроем большинство имеющихся проблем с её мониторингом. Конечно, ОАМ закрывает многие потребности, но тем не менее в нём не хватает одной очень существенной части: получения информации о состоянии сетевых устройств в квазиреальном времени без использования традиционных poll-технологий (переход к post-SNMP-картине). Именно эту задачу призвана закрыть сетевая телеметрия, к описанию которой я и перейду в следующей части статьи.