Иногда задача выглядит совсем простой: заменить адрес NetFlow-коллектора на двух пограничных маршрутизаторах Juniper MX. Добавили новый flow-server, сделали commit, увидели растущие счётчики — вроде бы можно расходиться.
Но один маршрутизатор отправляет данные нормально, а второй либо не виден на коллекторе, либо экспортирует в несколько раз меньше. Причём Junos уверенно показывает Flows Exported, а Export Packet Failures остаётся равным нулю.
Именно с такой ситуацией мы столкнулись на двух MX, работавших на разных ветках Junos: один на достаточно старом 20.4R2.7, другой на ветке 23.4. В итоге разница версий оказалась не причиной неисправности, но заставила внимательно проверить ограничения платформы и способ доставки экспортных пакетов.
Все имена, IP-адреса, номера VLAN и интерфейсов ниже изменены. Для адресов используются специальные тестовые сети RFC 5737.
Коротко: что такое inline J-Flow
J-Flow — название технологии учёта потоков у Juniper. Коллектору данные обычно отправляются в формате NetFlow v9 или IPFIX.
В режиме inline-jflow потоки обрабатывает не Routing Engine, а Packet Forwarding Engine — PFE. Он выбирает пакеты согласно sampling rate, создаёт flow records, обновляет их и экспортирует на коллектор по UDP.
Это важное архитектурное различие. Команда ping, запущенная из CLI, обычно проверяет доступность от Routing Engine. Успешный ping ещё не доказывает, что PFE сможет отправить тем же путём NetFlow-пакеты.
Juniper прямо указывает, что inline collectors обычно недоступны через management-интерфейсы вроде fxp0. Поддержка экспорта через mgmt_junos появилась отдельно в Junos OS Evolved 24.2R1 и только на поддерживаемых платформах. Для классического Junos на MX нельзя считать, что это автоматически работает.
Исходная схема
Условно у нас было два маршрутизатора:
EDGE-A — Junos 20.4R2.7;EDGE-B — Junos ветки 23.4;- старый коллектор —
198.51.100.10;
- новый коллектор —
198.51.100.20, UDP/9992.
На обоих MX уже работал inline-jflow. Задача состояла в том, чтобы добавить или заменить коллектор и убедиться, что новый сервер получает потоки.
Базовая часть конфигурации выглядела примерно так:
set services flow-monitoring version9 template NF-V9 ipv4-template
set services flow-monitoring version9 template NF-V9 flow-active-timeout 60
set services flow-monitoring version9 template NF-V9 flow-inactive-timeout 15
set services flow-monitoring version9 template NF-V9 template-refresh-rate packets 1000
set services flow-monitoring version9 template NF-V9 template-refresh-rate seconds 30
set forwarding-options sampling instance NF-SAMPLE input rate 1024
set forwarding-options sampling instance NF-SAMPLE family inet output flow-server 198.51.100.20 port 9992
set forwarding-options sampling instance NF-SAMPLE family inet output flow-server 198.51.100.20 version9 template NF-V9
set forwarding-options sampling instance NF-SAMPLE family inet output inline-jflow source-address 192.0.2.40
set chassis fpc 0 sampling-instance NF-SAMPLE
На нужных логических интерфейсах включается sampling, например:
set interfaces et-0/0/2 unit 110 family inet sampling input
set interfaces et-0/0/2 unit 120 family inet sampling input
Номера портов и units здесь условные. В реальной сети sampling нужно включать осознанно: на тех направлениях и в той стороне, которые действительно должны участвовать в учёте.
Ловушка №1: маршрут есть, ping проходит, экспорта нет
На проблемном маршрутизаторе адрес источника J-Flow находился на fxp0, а маршрут к коллектору уходил в mgmt_junos:
inline-jflow в PFE → mgmt_junos → fxp0 → collector
С Routing Engine коллектор отвечал на ping. Счётчики показывали созданные и экспортированные flows. Ошибки экспорта не увеличивались. И всё же на сервере нормального потока UDP-пакетов не было.
Это один из самых неприятных сценариев диагностики: каждая отдельная проверка выглядит успешной, но проверяется не тот путь.
Для inline monitoring Juniper отдельно предупреждает: flow records и templates нельзя экспортировать через management interface, кроме специально оговорённых сочетаний Junos OS Evolved, релиза и платформы. На обычном MX с классическим Junos рассчитывать на fxp0 нельзя.
Поэтому такая проверка недостаточна:
ping 198.51.100.20 routing-instance mgmt_junos source 192.0.2.40 rapid count 5
Она подтверждает только то, что Routing Engine видит сервер через management VRF.
Надёжная конечная проверка делается на самом коллекторе:
tcpdump -ni any 'src host 192.0.2.40 and udp dst port 9992'
Если UDP-пакеты приходят, но система не показывает flows, нужно проверять уже не маршрутизацию, а обработку NetFlow v9 templates, ACL коллектора и привязку нового exporter IP.
Рабочее решение: отдельный data-plane VRF
Мы не стали переделывать основную таблицу маршрутизации и трогать BGP/OSPF. Вместо этого создали небольшой отдельный VRF только для экспорта J-Flow и вывели его через обычный порт PFE.
Схема стала такой:
inline-jflow в PFE → NF-EXPORT VRF → et-* VLAN → gateway → collector
Пример с полностью вымышленными параметрами:
set interfaces et-0/0/3 unit 3900 description NETFLOW-EXPORT
set interfaces et-0/0/3 unit 3900 vlan-id 3900
set interfaces et-0/0/3 unit 3900 family inet address 192.0.2.40/24
set routing-instances NF-EXPORT instance-type vrf
set routing-instances NF-EXPORT route-distinguisher 64512:3900
set routing-instances NF-EXPORT vrf-target target:64512:3900
set routing-instances NF-EXPORT interface et-0/0/3.3900
set routing-instances NF-EXPORT routing-options static route 198.51.100.10/32 next-hop 192.0.2.1
set routing-instances NF-EXPORT routing-options static route 198.51.100.20/32 next-hop 192.0.2.1
После этого коллектор связывается с VRF непосредственно в sampling configuration:
set forwarding-options sampling instance NF-SAMPLE family inet output flow-server 198.51.100.20 routing-instance NF-EXPORT
delete forwarding-options sampling instance NF-SAMPLE family inet output inline-jflow source-address
set forwarding-options sampling instance NF-SAMPLE family inet output inline-jflow source-address 192.0.2.40
Если одновременно используются два collectors и платформа это поддерживает:
set forwarding-options sampling instance NF-SAMPLE family inet output flow-server 198.51.100.10 routing-instance NF-EXPORT
set forwarding-options sampling instance NF-SAMPLE family inet output flow-server 198.51.100.20 routing-instance NF-EXPORT
Нужно также разрешить VLAN на промежуточном коммутаторе, обеспечить обратный маршрут к 192.0.2.40 и разрешить нужный UDP-порт на коллекторе и межсетевых экранах.
Применять такую конфигурацию безопаснее через подтверждаемый commit:
commit check
show | compare
commit confirmed 10
После проверки не забываем зафиксировать изменения:
commit
Почему именно VRF, а не virtual-router
В Junos типы routing instance vrf и virtual-router похожи внешне, но для flow monitoring это не взаимозаменяемые сущности.
В документации к flow-server ... routing-instance явно указано: routing instance должен иметь instance-type vrf. Возможность отправлять NetFlow v9 и IPFIX через WAN-порты non-default VRF в классическом Junos существует давно, но обычный virtual-router под это требование формально не подходит.
Переводить существующий большой virtual-router с полной таблицей BGP в vrf только ради NetFlow — плохая идея. Такая операция перезапустит протоколы и потребует пересоздания таблиц и меток. Отдельный маленький VRF для экспорта проще, понятнее и почти не затрагивает рабочую маршрутизацию.
Нюансы разных версий Junos
Главный вывод из практики: номер релиза сам по себе редко отвечает на вопрос «заработает ли J-Flow». Смотреть нужно сочетание:
модель устройства + тип Junos + релиз + линейная карта + формат экспорта
1. Базовая конфигурация на 20.4 и 23.4 почти одинаковая
На классическом Junos для MX основные иерархии остаются прежними:
services flow-monitoring — шаблон;forwarding-options sampling — sampling instance, collector и source address;chassis fpc ... sampling-instance — привязка к PFE;interfaces ... sampling input|output — выбор трафика.
Поэтому наличие старой и новой версии на двух одинаковых маршрутизаторах ещё не объясняет различие в объёме данных.
2. Несколько collectors — платформозависимая функция
В разных разделах документации встречаются ограничения от одного до четырёх collectors на family. Поддержка зависит от устройства и релиза. Нельзя делать вывод только по тому, что команда принимается CLI.
Правильный порядок:
- Проверить модель и релиз в Juniper Feature Explorer.
- Выполнить
commit check с нужным количеством flow-server.
- Убедиться по
tcpdump, что templates и data records приходят на каждый сервер.
- Проверить, что у всех collectors одной family используется один source IP и совместимый template.
В нашей конфигурации два collectors работали на обоих релизах, но это не следует автоматически переносить на любую серию MX, PTX, ACX или QFX.
3. mgmt_junos — не универсальное решение
Поддержка экспорта через management VRF появилась в Junos OS Evolved 24.2R1 только для поддерживаемых платформ. Это не означает, что fxp0 заработал для inline J-Flow на всех MX после обновления.
Для классического Junos на MX безопасное правило остаётся простым: collector должен быть достижим через data-plane интерфейс.
4. Поддержка полей менялась между релизами
Например, NetFlow v9 для IPv6 появился позже, чем для IPv4. Начиная с 18.4R1 изменились рекомендуемые опции для MPLS templates. В 24.2R1 для ряда платформ появилась более точная обработка нескольких BGP next hops.
Если коллектору важны MPLS, IPv6, AS path, BGP next hop или корректный outgoing interface, нужно проверять не только факт прихода packets, но и состав полей конкретного template на конкретном релизе.
5. Обновление Junos не исправляет неправильный путь
Можно обновить маршрутизатор с 20.4 до более свежей ветки и получить тот же результат, если source address по-прежнему находится на fxp0, а collector доступен только через management table.
Сначала проверяем архитектуру экспорта, затем известные проблемы релиза, и только потом рассматриваем обновление как исправление.
Проверка после настройки
Сначала убеждаемся, что интерфейс и VRF поднялись:
show interfaces terse et-0/0/3.3900
show route table NF-EXPORT.inet.0 198.51.100.20 exact
ping 198.51.100.20 routing-instance NF-EXPORT source 192.0.2.40 rapid count 5
Затем смотрим состояние inline J-Flow:
show services accounting status inline-jflow fpc-slot 0
show services accounting flow inline-jflow fpc-slot 0
show services accounting errors inline-jflow fpc-slot 0
Полезный короткий вывод:
show services accounting flow inline-jflow fpc-slot 0 | match "Flow Packets:|Flows Exported:|Flow Packets Exported:"
Что означают основные счётчики:
Flow Packets — сколько sampled packets обработано;Flows Exported — сколько flow records сформировано;Flow Packets Exported — сколько экспортных UDP-пакетов сформировано;Export Packet Failures — ошибки экспорта, видимые самому механизму J-Flow.
На коллекторе:
tcpdump -ni any 'src host 192.0.2.40 and udp dst port 9992'
Для NetFlow v9 важно увидеть не только data packets, но и templates. Без актуального template сервер может получать UDP, но не уметь разобрать flow records. После изменения exporter IP некоторые системы также создают новый источник, который нужно отдельно разрешить или привязать.
Ловушка №2: «второй MX экспортирует в пять раз меньше»
После исправления маршрутизации оба маршрутизатора начали нормально отправлять J-Flow. Но на коллекторе объём от EDGE-B всё равно был примерно в пять раз меньше, чем от EDGE-A.
Первое подозрение — потери в новом VRF. Однако сравнение счётчиков показало почти одинаковую пропорцию на всех этапах:
sampled packets → flow records → export UDP packets
Если Flow Packets, Flows Exported и Flow Packets Exported отличаются между двумя маршрутизаторами примерно в одно и то же число раз, экспорт обычно работает нормально. Просто один маршрутизатор видит меньше sampled traffic.
Вот фактическая дельта counters за один и тот же контрольный интервал:
| Счётчик |
EDGE-B, Junos 23.4 |
EDGE-A, Junos 20.4R2.7 |
Соотношение |
Flow Packets |
36 595 |
190 594 |
EDGE-A ×5,21 |
Flow Bytes |
41 005 542 |
186 773 793 |
EDGE-A ×4,55 |
Flows Exported |
29 112 |
151 742 |
EDGE-A ×5,21 |
Flow Packets Exported |
7 348 |
38 008 |
EDGE-A ×5,17 |
Картина почти идеальная: старый MX обработал примерно в 5,2 раза больше sampled packets, сформировал в 5,2 раза больше flow records и отправил в 5,17 раза больше экспортных UDP-пакетов. Если бы проблема находилась между PFE и коллектором, такая ровная пропорция на всех трёх стадиях была бы маловероятна.
То есть старый Junos здесь не только не мешал — маршрутизатор на 20.4R2.7 фактически экспортировал больше. Причиной оказалось распределение реального трафика и различный охват интерфейсов sampling.
Причины могут быть совершенно штатными:
- через один MX реально проходит больше трафика;
- sampling включён на разном количестве интерфейсов;
- на одном устройстве забыли один peer или VLAN;
- входящий трафик распределён несимметрично из-за BGP;
- внутренний исходящий трафик предпочитает один маршрутизатор по IGP metric;
- сравниваются накопительные counters с разным uptime.
Сравнивать нужно не абсолютные значения, а прирост за одинаковый интервал. Например, снять counters на обоих устройствах, через 60 секунд повторить и посчитать delta.
При sampling rate 1:1024 грубая оценка исходного packet rate выглядит так:
исходный PPS ≈ прирост Flow Packets / интервал × 1024
Но не стоит напрямую приравнивать число flows к битрейту. Один длинный поток и тысячи коротких соединений могут передать одинаковый объём данных, но сформировать совершенно разное количество flow records.
Ещё несколько нюансов, о которых легко забыть
Sampling на входе и выходе — это не одно и то же
Если включить sampling сразу в обе стороны без понимания схемы, один и тот же пользовательский трафик можно учесть дважды. Сначала нужно определить точку учёта: внешние uplinks, абонентские интерфейсы, BNG-facing links или другой однозначный срез.
На одном FPC доступен один sampling instance
Пользовательский sampling instance имеет приоритет над global instance. Не стоит создавать несколько похожих конфигураций в надежде разделить collectors — результат может оказаться не тем, который ожидается.
Flow table тоже имеет предел
При большом количестве одновременных потоков нужно проверить размер flow hash table и ошибки accounting. Менять её вслепую не стоит: доступный размер зависит от платформы и линейной карты.
sFlow и mirroring могут конфликтовать
Juniper предупреждает о непредсказуемом поведении при одновременном использовании inline active flow monitoring и sFlow на одном интерфейсе. Аналогичное предупреждение есть для egress port mirroring.
Поля next hop и outgoing interface не всегда идеальны
При ECMP, разных VRF на входе и выходе, агрегированных интерфейсах и некоторых старых релизах отдельные поля могут быть нулевыми или отражать только первый известный путь. Поэтому NetFlow — отличный инструмент учёта и аналитики, но его поля нужно интерпретировать с учётом архитектуры PFE и возможностей релиза.
Короткий чек-лист диагностики
Если J-Flow «как будто работает», а данных нет или мало:
- Проверить, на каких интерфейсах и в каком направлении включён sampling.
- Проверить привязку sampling instance к нужному FPC.
- Убедиться, что source IP существует и достижим обратно с коллектора.
- Посмотреть маршрут к collector именно в указанном routing instance.
- Не считать успешный ping через
mgmt_junos доказательством доступности от PFE.
- Проверить UDP на collector через
tcpdump.
- Убедиться, что приходят NetFlow v9/IPFIX templates.
- Проверить ACL и регистрацию нового exporter IP на collector.
- Сравнивать delta counters за одинаковый интервал.
- Сверить platform/release support в Feature Explorer, особенно для нескольких collectors и non-default VRF.
Итог
Разные версии Junos действительно добавляют нюансы, но в этой истории главным оказался не релиз.
Inline J-Flow живёт в PFE. Поэтому маршрут, работающий для Routing Engine через fxp0, может быть бесполезен для экспорта flow records. Надёжное решение для классического Junos на MX — обеспечить collector data-plane маршрутом. Если не хочется вмешиваться в основную таблицу, отдельный маленький VRF и технологический VLAN решают задачу аккуратно и предсказуемо.
А если после этого один маршрутизатор экспортирует меньше другого, сначала сравните охват interfaces, реальный traffic и прирост counters. Иногда «потерянный NetFlow» — это просто трафик, который всё это время шёл через соседний MX.
Официальная документация
#network
