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

Мониторинг современного ядра оператора переходит от периодического опроса SNMP к потоковой телеметрии (подписка на данные по моделям YANG: gNMI Subscribe или dial-out gRPC) и к анализу потоков NetFlow v9/IPFIX (RFC 7011). SNMP с интервалом опроса 1-5 минут усредняет данные и не видит микросплески трафика и субсекундные события. Потоковая телеметрия работает по модели push: маршрутизатор по подписке сам передаёт структурированные данные (счётчики интерфейсов, состояние BGP и LDP, очереди) по gRPC/HTTP/2 с периодом от нескольких секунд (режим sample) или по изменению (on_change); коллектор складывает их в базу временных рядов (Prometheus, InfluxDB), часто через брокер. Нагрузка не нулевая: частота 1 с на тысячи интерфейсов нагружает CPU маршрутизатора и коллектор, поэтому пути и период ограничивают. Протокол IPFIX (IP Flow Information Export) экспортирует записи потоков (адреса, порты, протокол, метки MPLS, DSCP, счётчики байт и пакетов), как правило на выборке 1:N: объёмы нужно умножать на N (элемент samplingInterval), поэтому картина статистическая, а не полная. Вместе они показывают, где перегрузка и кто её создаёт, по клиентским VRF и каналам.

Четыре вида данных о сети

Мониторинг MPLS-ядра опирается на четыре независимых источника. Счётчики и состояние (загрузка интерфейсов, состояние LDP, BGP, BFD) собирают опросом SNMP или потоковой телеметрией. События (падение соседства, смена состояния LSP) приходят как SNMP trap/inform и syslog. Потоки (кто с кем и сколько передал) экспортируются через NetFlow v9 и IPFIX. Активные проверки (LSP ping, BFD) измеряют доступность сами. Ни один источник не заменяет остальные: счётчики показывают, что линк загружен, потоки объясняют кем, события - когда это началось.

SNMP: опрос, trap и MIB

SNMP отвечает на запросы на UDP 161, а уведомления отправляет на UDP 162. Версия v2c защищена только строкой community, v3 добавляет аутентификацию и шифрование (usm). Trap отправляется без подтверждения, inform подтверждается получателем и повторяется при потере, поэтому для критичных событий используют inform. Опрос обычно идёт раз в 1-5 минут; это определяет разрешение графиков, и короткие всплески загрузки теряются в усреднении. Для счётчиков интерфейсов нужны 64-битные ifHCInOctets/ifHCOutOctets из ifXTable: 32-битный счётчик октетов на 10 Гбит/с переполняется примерно за 3,4 секунды, а при опросе раз в минуту результат окажется ложным.

Для MPLS стандартизованы MIB: MPLS-LSR-STD-MIB (RFC 3813, таблицы LFIB), MPLS-LDP-STD-MIB (RFC 3815, сессии и привязки), MPLS-TE-STD-MIB (RFC 3812, туннели), MPLS-L3VPN-STD-MIB (RFC 4382, таблицы VRF и уведомления о превышении числа маршрутов), BGP4-MIB (RFC 4273, bgpBackwardTransition), BFD-STD-MIB (RFC 7330, bfdSessUp/bfdSessDown) и IF-MIB (linkUp/linkDown). Реализация и охват зависят от вендора, и часть метрик доступна только в собственных MIB. После перезагрузки ifIndex может смениться, поэтому включайте его фиксацию (snmp-server ifindex persist на Cisco).

Syslog

Syslog (RFC 5424) передаёт текстовые события с уровнем от 0 (emergency) до 7 (debug) и facility; транспорт по умолчанию - UDP 514, надёжнее TCP или TLS на 6514. Для MPLS важны сообщения о соседствах: %OSPF-5-ADJCHG, %LDP-5-NBRCHG, %BGP-5-ADJCHANGE на Cisco. Практика: единый источник (loopback), синхронизация времени NTP, чтобы события разных узлов можно было сопоставить по времени, и корреляция с BFD-событиями.

NetFlow v9 и IPFIX: шаблоны и ключ потока

Поток (flow) - серия пакетов с одинаковым ключом (обычно адреса источника и назначения, порты, протокол, ToS, входной интерфейс). Маршрутизатор ведёт flow cache и экспортирует записи в коллектор, когда поток закончился (FIN/RST, inactive timeout, обычно 15 с) или достиг active timeout (на Cisco по умолчанию 30 мин, на практике ставят 60 с, иначе поток долго не виден). NetFlow v5 имеет фиксированный формат и только IPv4, поэтому для MPLS и IPv6 он не подходит. NetFlow v9 (RFC 3954) и IPFIX (RFC 7011) основаны на шаблонах: Template Set (ID 0 в v9, ID 2 в IPFIX) описывает поля, а Data Set с ID 256 и выше содержит значения. Поля берутся из реестра информационных элементов IANA: sourceIPv4Address (8), destinationIPv4Address (12), protocolIdentifier (4), ingressInterface (10), octetDeltaCount (1), packetDeltaCount (2). IPFIX работает поверх UDP, TCP или SCTP, стандартный порт 4739 (для v9 привычен 2055, но он не зарезервирован).

Для MPLS в IPFIX есть элементы mplsTopLabelStackSection и последующие (70-79: до десяти меток), mplsTopLabelType (46), mplsTopLabelIPv4Address (47); VRF передаются как ingressVRFID (234) и egressVRFID (235). Классический MPLS-aware NetFlow на P-маршрутизаторе экспортирует метки (позиции задаются отдельно, на Cisco ip flow-cache mpls label-positions), а PE видит клиентский трафик как IP внутри VRF, поэтому flow monitor вешают на интерфейсы клиентов (ingress). Без выборки каждый пакет слишком дорог, поэтому используют семплирование 1:N: полученные байты и пакеты нужно умножать на N, а в шаблон добавляют опцию samplingInterval (34), иначе коллектор занизит объём.

Потоковая телеметрия: gRPC, YANG, gNMI

Модель телеметрии: маршрутизатор публикует данные по подписке, а не по запросу. Данные описаны YANG-моделями (OpenConfig или собственными), транспорт - gRPC поверх HTTP/2 с Protobuf (GPB key-value или compact) либо JSON, обычно в TLS. В gNMI (RPC Capabilities, Get, Set, Subscribe) подписка бывает STREAM (режимы sample, on_change, target_defined), ONCE и POLL. Различают dial-in (коллектор подключается к устройству) и dial-out (устройство само устанавливает соединение; так работают Cisco MDT и Huawei Telemetry). На Cisco IOS-XE update-policy periodic задаётся в сотых долях секунды (1000 - это 10 с), у Junos Telemetry Interface reporting-rate в секундах. Преимущества перед SNMP: периодичность секунды, структурированные данные, on_change для событий и меньшая нагрузка на CPU при больших таблицах. Но "нулевой" нагрузки не бывает: сенсоры считают данные на плоскости управления, а коллектор должен выдержать объём, поэтому ограничивайте пути и частоту.