Теоретические основы и архитектура

Проверка LSP и BFD отвечают на вопрос "жив ли путь", но договор на услугу обещает числа: задержку, джиттер и потери. Их измеряют активно: на сети периодически отправляют синтетические пробные пакеты и считают метрики по ответам. Урок разбирает три семейства инструментов. IP SLA, NQA и RPM - проприетарные зонды на маршрутизаторе (ICMP, UDP jitter) с порогами и реакциями. TWAMP (RFC 5357) - стандартный протокол двустороннего измерения с управляющим каналом TCP 862 и тестовым потоком UDP, который понимают разные производители. Ethernet CFM (IEEE 802.1ag) и Y.1731 работают на уровне 2: домены обслуживания, MEP и MIP, Continuity Check, loopback и linktrace, а Y.1731 добавляет измерение задержки и потерь. Отдельно разбирается, как привязать измерения к сервисам L2VPN и как выставить пороги и аварии, чтобы не получить ложных тревог. Предполагаются знания OAM для LSP, BFD и L2VPN из предыдущих уроков.

Активное и пассивное измерение

Пассивные данные (счётчики интерфейсов, IPFIX) показывают, что видит сеть, но не дают гарантированной картины для конкретного пути: нет трафика - нет данных. Активное измерение отправляет синтетические пакеты с известным размером, интервалом и маркировкой DSCP и считает по ответам задержку, джиттер и потери выбранного пути и класса. Это основа проверки SLA и приёмки (см. урок про приёмку сети). Зонд занимает полосу и ЦП, поэтому частота подбирается так, чтобы дать статистику без перегрузки: 100 пакетов раз в 60 секунд даёт всего около 1,7 пакета в секунду на зонд. Результат всегда зависит от пути: зонд идёт тем же маршрутом, что и клиентский трафик, только если совпадают класс QoS и ECMP-хеш (меняйте порты источника), иначе измеряется другой путь.

IP SLA, NQA и RPM

Cisco IP SLA, Huawei NQA и Juniper RPM - зонды на самом маршрутизаторе. Типовые операции: ICMP echo (RTT и потери), UDP echo, UDP jitter. UDP jitter на Cisco использует респондер на удалённой стороне (ip sla responder): при отправке и приёме респондер фиксирует четыре временные метки, по ним считаются задержка в каждом направлении, джиттер и потери в обе стороны; одностороннюю задержку можно доверять только при синхронных часах. Параметры: число пакетов, интервал между ними (20 мс имитирует голос), частота запуска, таймаут и порог. Реакции (reaction) превращают нарушение порога в SNMP trap или syslog, а объект track связывает зонд со статическим маршрутом или резервированием: маршрут снимается, когда зонд до next-hop перестаёт отвечать. Ограничения: большинство платформ обрабатывает зонды ЦП, отметки времени ставятся программно, поэтому на загруженном устройстве измерение содержит собственный шум и не годится для миллисекундной точности; отдельные платформы имеют аппаратные таймеры.

TWAMP (RFC 5357)

Two-Way Active Measurement Protocol стандартизует двусторонний тест между производителями. Роли: control-client и server (управление) и session-sender и session-reflector (тест). Управляющий протокол работает по TCP, порт 862: сервер отправляет Server Greeting с поддерживаемыми режимами (unauthenticated, authenticated, encrypted) и challenge, клиент отвечает Set-Up-Response, сервер - Server-Start; затем клиент отправляет Request-TW-Session с портами, размером и таймаутом, сервер отвечает Accept-Session, и Start-Sessions запускает тест; Stop-Sessions завершает его. Тестовый протокол - UDP: пакет отправителя несёт номер, 64-битную метку времени в формате NTP, оценку ошибки (бит S показывает синхронизацию часов и множитель) и заполнитель до нужного размера; отражатель добавляет метку приёма, метку отправки, свой номер и копию данных отправителя. TWAMP-Light (приложение к RFC 5357) обходится без управляющего протокола: оба конца настраиваются вручную, а отражатель просто возвращает пакеты, из-за чего её поддерживают чаще. Развитие - STAMP (RFC 8762), упрощённый протокол с тем же форматом пакетов в духе TWAMP-Light. Метрики определены в RFC 2679 (однонаправленная задержка), RFC 2680 (потери), RFC 3393 (вариация задержки, IPDV) и RFC 5481 (сравнение способов). Для статистики берите перцентили (p95, p99), а не только среднее: среднее скрывает всплески.

Ethernet CFM (IEEE 802.1ag)

CFM (Connectivity Fault Management) - OAM второго уровня для сервиса Ethernet. Сервис описывается иерархией: Maintenance Domain (MD) с уровнем 0-7, внутри него Maintenance Association (MA), идентифицируемая именем домена и короткой строкой (MAID); Maintenance End Point (MEP, идентификатор 1-8191) стоит на границе MA и генерирует или принимает OAM-кадры, Maintenance Intermediate Point (MIP) отвечает на loopback и linktrace, но сам CCM не отправляет. Уровни разделяют ответственность: обычно 5-7 - клиент, 3-4 - провайдер (end-to-end между UNI), 0-2 - оператор или участки сети. Кадр OAM маркируется EtherType 0x8902, адрес назначения групповой, зависит от уровня; OAM кадры уровня выше своего MEP пропускаются прозрачно, ниже - отбрасываются, поэтому уровни не пересекаются. MEP бывают Up (смотрят в сторону моста, внутрь устройства) и Down (смотрят на порт, в сторону линии).

Continuity Check Message (CCM, opcode 1) - периодический multicast-кадр: интервалы кодируются числом 1-7 (3,33 мс, 10 мс, 100 мс, 1 с, 10 с, 1 мин, 10 мин). MEP считает удалённый MEP потерянным, если CCM нет в течение 3,5 интервала; дефекты: Remote CCM (нет CCM от соседа), Error CCM (чужой MEP ID, неверный интервал или уровень), Xcon CCM (чужая MA в нашем MD: ошибка склейки сервисов), RDI (бит в CCM, сообщающий, что на удалённой стороне нет приёма). Loopback (LBM opcode 3 / LBR opcode 2) - аналог ping на втором уровне, адресуется unicast на MAC MEP/MIP. Linktrace (LTM 5 / LTR 4) отправляется с TTL на групповой адрес и показывает путь: каждый MIP возвращает LTR и пересылает LTM дальше, что находит место разрыва в пути моста.