WikiDer > Поток данных, передающихся по сети
Поток данных, передающихся по сети это функция, которая была представлена на Cisco маршрутизаторы около 1996 года, которые обеспечивают возможность сбора сетевого IP-трафика при входе в интерфейс или выходе из него. Анализируя данные, предоставленные NetFlow, сетевой администратор может определить такие вещи, как источник и место назначения трафика, класс обслуживания и причины перегрузки. Типичная установка мониторинга потока (с использованием NetFlow) состоит из трех основных компонентов:[1]
- Экспортер потока: объединяет пакеты в потоки и экспортирует записи потоков в один или несколько сборщиков потоков.
- Коллектор потока: отвечает за прием, хранение и предварительную обработку данных потока, полученных от экспортера потока.
- Приложение для анализа: анализирует полученные данные о потоках, например, в контексте обнаружения вторжений или профилирования трафика.
Описание протокола
Маршрутизаторы и коммутаторы, поддерживающие NetFlow, могут собирать IP статистика трафика на всех интерфейсах, на которых включен NetFlow, а затем экспорт этой статистики в виде записей NetFlow по крайней мере в один сборщик NetFlow - обычно сервер, который выполняет фактический анализ трафика.
Сетевые потоки
Стандарт Cisco NetFlow версии 5 определяет поток как однонаправленная последовательность пакетов, которые имеют семь значений, которые определяют уникальный ключ для потока:[2]
- Входящий интерфейс (SNMP ifIndex)
- Источник айпи адрес
- Пункт назначения айпи адрес
- Протокол IP
- Исходный порт для UDP или же TCP, 0 для других протоколов
- Порт назначения для UDP или же TCP, введите и код для ICMP, или 0 для других протоколов
- IP Тип сервиса
Обратите внимание, что интерфейс Egress, IP Nexthop или BGP Nexthops не являются частью ключа и могут быть неточными, если маршрут изменяется до истечения срока действия потока или если балансировка нагрузки выполняется для каждого пакета.
Это определение потоков также используется для IPv6, и аналогичное определение используется для MPLS и Ethernet потоки.
Расширенные реализации NetFlow или IPFIX, такие как Cisco Flexible NetFlow, позволяют определять ключи потока, определяемые пользователем.
Типичный вывод инструмента командной строки NetFlow (nfdump
в этом случае) при печати сохраненные потоки могут выглядеть следующим образом:
Дата начала потока Продолжительность Proto Src IP-адрес: Порт Dst IP-адрес: Порт Пакеты Потоки байтов 2010-09-01 00: 00: 00.459 0,000 UDP 127.0.0.1:24920 -> 192.168.0.1:22126 1 46 1 2010-09-01 00: 00: 00.363 0.000 UDP 192.168.0.1:22126 -> 127.0.0.1:24920 1 80 1
Экспорт записей
Маршрутизатор выведет запись потока, когда он определит, что поток завершен. Это достигается за счет устаревания потока: когда маршрутизатор видит новый трафик для существующего потока, он сбрасывает счетчик устаревания. Также, TCP сеанс завершение в потоке TCP заставляет маршрутизатор прекращать поток. Маршрутизаторы также можно настроить для вывода записи потока через фиксированный интервал, даже если поток все еще продолжается.
Протокол передачи пакетов
Записи NetFlow традиционно экспортируются с использованием протокола дейтаграмм пользователя (UDP) и собраны с помощью сборщика NetFlow. IP-адрес сборщика NetFlow и UDP-порт назначения должны быть настроены на отправляющем маршрутизаторе. Обычное значение - UDP-порт 2055, но также могут использоваться другие значения, например 9555 или 9995, 9025, 9026 и т. Д.
По соображениям эффективности маршрутизатор традиционно не отслеживает уже экспортированные записи потока, поэтому, если пакет NetFlow отбрасывается из-за перегрузка сети или повреждение пакета, все содержащиеся в нем записи теряются навсегда. Протокол UDP не информирует маршрутизатор о потере, поэтому он может отправить пакеты снова. Это может быть реальной проблемой, особенно с NetFlow v8 или v9, которые могут объединять множество пакетов или потоков в одну запись. Одна потеря пакета UDP может сильно повлиять на статистику некоторых потоков.
Вот почему некоторые современные реализации NetFlow используют протокол передачи управления потоком (SCTP) для экспорта пакетов, чтобы обеспечить некоторую защиту от потери пакетов, и убедитесь, что шаблоны NetFlow v9 получены перед экспортом любой связанной записи. Обратите внимание, что TCP не подходит для NetFlow, поскольку строгий порядок пакетов приведет к чрезмерной буферизации и задержкам.
Проблема с SCTP заключается в том, что он требует взаимодействия между каждым сборщиком NetFlow и каждым маршрутизатором, экспортирующим NetFlow. Могут быть ограничения производительности, если маршрутизатору приходится иметь дело со многими сборщиками NetFlow, а сборщику NetFlow приходится иметь дело со многими маршрутизаторами, особенно когда некоторые из них недоступны из-за сбоя или обслуживания.
SCTP может быть неэффективным, если NetFlow необходимо экспортировать в несколько независимых коллекторов, некоторые из которых могут быть тестовыми серверами, которые могут выйти из строя в любой момент. Протокол UDP позволяет выполнять простую репликацию пакетов NetFlow с использованием сетевых ответвлений или зеркалирования L2 или L3. Простое оборудование без отслеживания состояния может также при необходимости фильтровать или изменять адрес назначения UDP-пакетов NetFlow. Поскольку при экспорте NetFlow используются почти только магистральные каналы сети, потеря пакетов часто будет незначительной. Если это произойдет, в основном это будет связь между сетью и сборщиками NetFlow.
Заголовки пакетов
Все пакеты NetFlow начинаются с заголовка, зависящего от версии, который содержит как минимум следующие поля:
- Номер версии (v1, v5, v7, v8, v9)
- Порядковый номер для обнаружения потери и дублирования
- Отметки времени на момент экспорта в виде времени безотказной работы системы или абсолютного времени.
- Количество записей (v5 или v8) или список шаблонов и записей (v9)
Записи
Запись NetFlow может содержать широкий спектр информации о трафике в данном потоке.
NetFlow версии 5 (одна из наиболее часто используемых версий, за которой следует версия 9) содержит следующее:
- Индекс входного интерфейса, используемый SNMP (ifIndex в IF-MIB).
- Индекс выходного интерфейса или ноль, если пакет отброшен.
- Метки времени начала и окончания потока в миллисекундах с момента последней загрузки.
- Количество байтов и пакетов, наблюдаемых в потоке
- Слой 3 заголовки:
- Исходный и целевой IP-адреса
- ICMP Тип и код.
- Протокол IP
- Тип сервиса (ToS) значение
- Номера портов источника и назначения для TCP, UDP, SCTP
- Для TCP-потоков - объединение всех TCP-флагов, наблюдаемых за время существования потока.
- Слой 3 Маршрутизация Информация:
- IP-адрес ближайшего следующего перехода (не следующего перехода BGP) на пути к месту назначения
- Маски исходных и целевых IP-адресов (длина префиксов в CIDR обозначение)
За ICMP потоков, порт источника равен нулю, а поле номера порта назначения кодирует тип и код сообщения ICMP (порт = тип ICMP * 256 + код ICMP).
Источник и место назначения Автономная система Поля номера (AS) могут сообщать AS назначения (последняя AS из AS-Path) или ближайшую соседнюю AS (первая AS из AS-Path) в зависимости от конфигурации маршрутизатора. Но номер AS будет равен нулю, если функция не поддерживается, маршрут неизвестен или не объявлен BGP, или AS является локальной AS. Нет четкого способа различить эти случаи.
NetFlow версии 9 может включать все эти поля и может включать дополнительную информацию, такую как Многопротокольная коммутация по меткам (MPLS) метки и IPv6 адреса и порты,
Анализируя данные о потоках, можно составить картину потока и объема трафика в сети. Формат записи NetFlow со временем развивался, поэтому в него были включены номера версий. Cisco хранит сведения о различных номерах версий и структуре пакетов для каждой версии.
Интерфейсы
NetFlow обычно включается для каждого интерфейса, чтобы ограничить нагрузку на компоненты маршрутизатора, участвующие в NetFlow, или ограничить количество экспортируемых записей NetFlow.
NetFlow обычно захватывает все пакеты, полученные входящим IP-интерфейсом, но некоторые реализации NetFlow используют IP-фильтры, чтобы решить, может ли NetFlow наблюдать за пакетом.
Некоторые реализации NetFlow также позволяют наблюдать за пакетами на исходящем IP-интерфейсе, но это следует использовать с осторожностью: все потоки от любого входящего интерфейса с включенным NetFlow к любому интерфейсу с включенным NetFlow могут быть подсчитаны дважды.
Образец NetFlow
Стандартный NetFlow был разработан для обработки всех IP-пакетов на интерфейсе. Но в некоторых средах, например в магистралях Интернета это было слишком дорого из-за дополнительной обработки, необходимой для каждого пакета, и большого количества одновременных потоков.
Итак, Cisco представила выборку NetFlow на Cisco 12000, и это теперь используется во всех высокопроизводительных маршрутизаторах, реализующих NetFlow.
Только один пакет из п обрабатывается, где п, частота дискретизации определяется конфигурацией маршрутизатора.
Точный процесс выбора зависит от реализации:
- Один пакет каждый п пакет в Deterministic NetFlow, который используется в Cisco 12000.
- Один пакет, выбранный случайным образом в интервале п пакет в Random Sampled NetFlow, используемый на современных маршрутизаторах Cisco.
В некоторых реализациях есть более сложные методы выборки пакетов, такие как выборка для каждого потока на Cisco Martinez Catalysts.
Частота дискретизации часто одинакова для всех интерфейсов, но может быть отрегулирована для каждого интерфейса для некоторых маршрутизаторов. Когда используется Sampled NetFlow, записи NetFlow должны быть скорректированы с учетом эффекта выборки - объемы трафика, в частности, теперь являются приблизительными. чем фактический измеренный объем потока.
Частота дискретизации указывается в поле заголовка NetFlow версии 5 (одинаковая частота дискретизации для всех интерфейсов) или в записях опций NetFlow версии 9 (частота дискретизации на интерфейс)
Версии
Версия | Комментарий |
---|---|
v1 | Первая реализация, теперь устаревшая и ограниченная IPv4 (без IP-маска и Номера AS). |
v2 | Внутренняя версия Cisco, никогда не выпускалась. |
v3 | Внутренняя версия Cisco, никогда не выпускалась. |
v4 | Внутренняя версия Cisco, никогда не выпускалась. |
v5 | Наиболее распространенная версия, доступная (по состоянию на 2009 г.) на многих маршрутизаторах разных производителей, но ограниченная IPv4 потоки. |
v6 | Больше не поддерживается Cisco. Информация об инкапсуляции (?). |
v7 | Как версия 5 с полем исходного маршрутизатора. Используется (только?) На коммутаторах Cisco Catalyst. |
v8 | Несколько форм агрегирования, но только для информации, которая уже присутствует в записях версии 5 |
v9 | На основе шаблона, доступно (с 2009 г.) на некоторых недавних маршрутизаторах. В основном используется для отчетов о таких потоках, как IPv6, MPLS, или даже просто IPv4 с BGP nexthop. |
v10 | Используется для идентификации IPFIX. Хотя IPFIX в значительной степени основан на NetFlow, v10 не имеет ничего общего с NetFlow. |
NetFlow и IPFIX
NetFlow изначально был реализован Cisco и описан в «информационном» документе, который не соответствовал стандартам: RFC 3954 - Cisco Systems NetFlow Services Export Version 9. Сам протокол NetFlow был заменен протоколом Internet Protocol Flow Information eXport (IPFIX). Основанный на реализации NetFlow версии 9, IPFIX находится на треке стандартов IETF с RFC 5101 (устарело RFC 7011), RFC 5102 (устарело RFC 7012) и др., опубликованные в 2008 г.
Эквиваленты
Многие поставщики, кроме Cisco предоставить аналогичную технологию мониторинга сетевого потока. NetFlow может быть широко распространенным именем в области мониторинга потоков из-за Cisco доминирующая доля рынка в сетевой индустрии. NetFlow считается товарным знаком Cisco (хотя по состоянию на март 2012 года он не указан в товарных знаках Cisco).[3]):
- Argus - Система создания и использования записей аудита
- Jflow или cflowd для Juniper Networks
- NetStream для 3Com / HP
- NetStream для Технологии Huawei
- Cflowd для Nokia
- Rflow для Ericsson
- AppFlow Citrix
- sFlow поставщики включают: Alaxala, Alcatel Lucent, Allied Telesis, Arista Networks, Парча, Cisco, Dell, D-Link, Энтерасис, Экстремальный, F5 BIG-IP, Fortinet, Hewlett Packard, Hitachi, Huawei, IBM, Можжевельник, LG-Ericsson, Mellanox, MRV, NEC, Netgear, Проксим беспроводной, Quanta Computer, Вятта, Телесофт, ZTE и ZyXEL[4]
Также коллекция программного обеспечения flow-tools[5] позволяет обрабатывать и управлять экспортом NetFlow с маршрутизаторов Cisco и Juniper.[6]
Поддерживать
Производитель и тип | Модели | Версия NetFlow | Выполнение | Комментарии |
---|---|---|---|---|
Маршрутизаторы Cisco IOS-XR | CRS, ASR9000 Старый 12000 | v5, v8, v9 | Программное обеспечение, работающее на процессоре линейной карты | Всесторонняя поддержка IPv6 и MPLS |
Маршрутизаторы Cisco IOS | 10000, 7200, старые 7500 | v5, v8, v9 | Программное обеспечение, работающее на процессоре маршрутизации | для поддержки IPv6 или MPLS требуется последняя модель и IOS |
Cisco Катализатор переключатели | 7600, 6500, 4500 | v5, v8, v9 | Выделенный аппаратный TCAM, также используемый для ACL. | Поддержка IPv6 в моделях высокого класса RSP720 и Sup720, но не более 128 или 256 тысяч потоков на карту PCF.[7] |
Cisco Nexus переключатели | 5600, 7000, 7700 | v5, v9 | Выделенный аппаратный TCAM, также используемый для ACL. До 512К потоков. Поддержка IPv4 / IPv6 / L2. | MPLS не поддерживается |
Устаревшие маршрутизаторы Juniper | М-серия, Т-серия, MX-серия с ЦОД | v5, v8 | Программное обеспечение, работающее на Routing Engine, называется программное обеспечение jflow | IPv6 и MPLS не поддерживаются |
Устаревшие маршрутизаторы Juniper | М-серия, Т-серия, MX-серия с ЦОД | v5, v8, v9 | Программное обеспечение, работающее на сервисе PIC, называется аппаратный jflow или же отобранный | IPv6 или MPLS поддерживается в MS-DPC, MultiService-PIC, AS-PIC2 |
Можжевельник маршрутизаторы | MX-серия с MPC-3D, будущим FPC5 для T4000 | v5, IPFIX | Аппаратное обеспечение (трио чипсет), называемое встроенный jflow | IPv6 требует JUNOS 11.4R2 (целевой порт заднего вида), поддержка MPLS неизвестна, MPC3E исключен до 12.3, неправильное поле времени начала приводит к неверному результату пропускной способности данных [8] |
Alcatel-Lucent маршрутизаторы | 7750SR | v5, v8, v9, v10 IPFIX | Программное обеспечение, работающее на модуле центрального процессора | IPv6 или MPLS с использованием линейных карт IOM3 или лучше |
Huawei маршрутизаторы | NE5000E NE40E / X NE80E | v5, v9 | Программное обеспечение, работающее на сервисных картах | Поддержка IPv6 или MPLS неизвестна |
Энтерасис Переключатели | S-серия[9] и N-серия[10] | v5, v9 | Выделенное оборудование | Поддержка IPv6 неизвестна |
Flowmon Зонды | Flowmon Зонд 1000, 2000, 4000, 6000, 10000, 20000, 40000, 80000, 100000 | v5, v9, IPFIX | Программное или аппаратное ускорение | Всесторонняя поддержка IPv6 и MPLS, проводная скорость |
Nortel Переключатели | Коммутатор маршрутизации Ethernet серии 5500 (ERS5510, 5520 и 5530) и 8600 (на базе шасси) | v5, v9, IPFIX | Программное обеспечение, работающее на процессоре линейной карты | Всесторонняя поддержка IPv6 |
ПК и серверы | Linux FreeBSD NetBSD OpenBSD | v5, v9, IPFIX | Программное обеспечение, такое как fprobe,[11] ipt-netflow,[12] pflow,[13], потекла[14], Netgraph ng_netflow[15] или softflowd | Поддержка IPv6 зависит от используемого программного обеспечения |
Серверы VMware | vSphere 5.x[16] | v5, IPFIX (> 5.1)[17] | Программного обеспечения | Поддержка IPv6 неизвестна |
Mikrotik RouterOS | RouterOS 3.x, 4.x, 5.x, 6.x [18] | v1, v5, v9, IPFIX (> 6.36RC3) | Программное обеспечение и оборудование Routerboard | IPv6 поддерживается с использованием v9. В настоящее время RouterOS не включает номера BGP AS. |
Варианты
Журнал событий безопасности Cisco NetFlow
Представлено с запуском Cisco ASA 5580 товаров, Журнал событий безопасности NetFlow использует поля и шаблоны NetFlow v9 для эффективной доставки телеметрии безопасности в высокопроизводительных средах. Ведение журнала событий безопасности NetFlow масштабируется лучше, чем системный журнал предлагая тот же уровень детализации и детализации регистрируемых событий.[нужна цитата]
Мониторинг на основе автономных зондов
Эта секция возможно содержит оригинальные исследования. (Март 2009 г.) (Узнайте, как и когда удалить этот шаблон сообщения) |
Сбор NetFlow с использованием автономных зондов NetFlow является альтернативой сбору потоков от маршрутизаторов и коммутаторов. Этот подход может преодолеть некоторые ограничения мониторинга NetFlow на основе маршрутизатора. Датчики прозрачно подключаются к контролируемому каналу как пассивное устройство с помощью порта TAP или SPAN устройства.
Исторически сложилось так, что мониторинг NetFlow проще реализовать в выделенном зонде, чем в маршрутизаторе. Однако у этого подхода есть и недостатки:
- зонды должны быть развернуты на каждом канале, за которым необходимо наблюдать, что вызывает дополнительные затраты на оборудование, настройку и обслуживание.
- зонды не будут сообщать информацию об отдельных входных и выходных интерфейсах, как отчет маршрутизатора.
- у зондов могут быть проблемы с достоверным отчетом о полях NetFlow, связанных с маршрутизацией, например Номера AS или же IP-маски, потому что вряд ли можно ожидать, что они будут использовать ту же информацию маршрутизации, что и маршрутизатор.
Самый простой способ устранить указанные выше недостатки - использовать устройство захвата пакетов встроенный перед маршрутизатором и захватить весь вывод NetFlow от маршрутизатора. Этот метод позволяет хранить большой объем данных NetFlow (обычно данных за многие годы) и не требует перенастройки сети.
Сбор NetFlow с помощью выделенных зондов хорошо подходит для наблюдения за критическими ссылками, тогда как NetFlow на маршрутизаторах обеспечивает общесетевое представление трафика, которое можно использовать для планирования емкости, учета, мониторинга производительности и безопасности.
История
NetFlow изначально была технологией коммутации пакетов Cisco для маршрутизаторов Cisco, реализованной в IOS 11.x примерно в 1996 г. Первоначально это была программная реализация для Cisco 7000, 7200 и 7500,[19] где это считалось улучшением по сравнению с нынешним Cisco Fast Switching. Netflow изобрели Даррен Керр и Барри Брюин. [20]от Cisco (патент США № 6,243,667).
Идея заключалась в том, что первый пакет потока будет создавать запись переключения NetFlow. Затем эта запись будет использоваться для всех последующих пакетов того же потока до истечения срока действия потока. Только первый пакет потока потребует исследования таблицы маршрутов, чтобы найти наиболее конкретный совпадающий маршрут. Это дорогостоящая операция при реализации программного обеспечения, особенно старых без База экспедиторской информации. Запись переключения NetFlow на самом деле была своего рода записью кэша маршрута, и старые версии IOS по-прежнему ссылаются на кеш NetFlow как ip route-cache.
Эта технология была выгодна для локальных сетей. Это было особенно верно, если часть трафика нужно было фильтровать ACL поскольку ACL должен был оценить только первый пакет потока.[21]
Коммутация NetFlow вскоре оказалась неподходящей для больших маршрутизаторов, особенно для магистральных интернет-маршрутизаторов, где количество одновременных потоков было намного важнее, чем в локальных сетях, и где некоторый трафик вызывает множество кратковременных потоков, например система доменных имен запросы (чей исходный порт случайный по соображениям безопасности).
В качестве технологии коммутации NetFlow был заменен примерно в 1995 году на Cisco Express Forwarding. Впервые она появилась на маршрутизаторах Cisco 12000, а позже заменила коммутацию NetFlow на усовершенствованную IOS для Cisco 7200 и Cisco 7500.
По состоянию на 2012 год технологии, подобные коммутации NetFlow, все еще используются в большинстве межсетевых экранов и программных IP-маршрутизаторах. Например, функция conntrack в Netfilter рамки, используемые Linux.
Смотрите также
- Поток трафика (компьютерные сети)
- Экспорт информации IP-потока (IPFIX) - IETF протокол экспорта стандартного отслеживания потока, основанный на NetFlow версии 9
- sFlow - альтернатива NetFlow (обязательная выборка, без кеширования потока, без шаблонов [22])
Рекомендации
- ^ Хофстеде, Рик; Челеда, Павел; Траммелл, Брайан; Драго, Идилио; Садре, Рамин; Сперотто, Анна; Прас, Айко (2014). «Объяснение мониторинга потока: от захвата пакетов до анализа данных с помощью NetFlow и IPFIX». Обзоры и учебные пособия по коммуникациям IEEE. 16 (4): 2037–2064. Дои:10.1109 / COMST.2014.2321898.
- ^ https://pliki.ip-sa.pl/wiki/Wiki.jsp?page=NetFlow
- ^ «Торговые марки Cisco».
- ^ «Продукты sFlow: Сетевое оборудование». sFlow.org.
- ^ https://github.com/adsr/flow-tools
- ^ https://github.com/adsr/flow-tools/blob/master/README
- ^ «Характеристики Cisco RSP720 Sup720 NetFlow». cisco.com. Июль 2010 г.. Получено 2012-03-08.
- ^ "pps и bps неверны на Juniper j-flow". Август 2012 г.. Получено 2016-03-17.
- ^ "NetFlow в Enterasys S-Serie" (PDF). enterasys.com. Февраль 2012 г.. Получено 2012-03-04.
- ^ "NetFlow в Enterasys N-Serie" (PDF). enterasys.com. Февраль 2012 г.. Получено 2012-03-04.
- ^ "fprobe".
- ^ "ipt-netflow".
- ^ Хеннинг Брауэр; Йорг Гольтерманн (29 марта 2014 г.). "pflow - интерфейс ядра для экспорта данных pflow". BSD Cross Rererence. OpenBSD. Получено 2019-08-09. Сложить резюме.
- ^ "flowd-0.9.1.20140828 - коллектор NetFlow". Порты OpenBSD. 2019-07-17. Получено 2019-08-09.
- ^ Глеб Смирнов (2005). "ng_netflow - реализация Cisco NetFlow". BSD Cross Rererence. FreeBSD. Получено 2019-08-09. Сложить резюме.
- ^ http://blogs.vmware.com/networking/2011/08/vsphere-5-new-networking-features-netflow.html
- ^ http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Network-Technical-Whitepaper.pdf
- ^ http://wiki.mikrotik.com/wiki/Manual:IP/Traffic_Flow
- ^ http://www.cisco.com/en/US/docs/ios/11_2/feature/guide/netflow.html
- ^ https://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_presentation0900aecd80311f49.pdf
- ^ NetFlow, sFlow и расширяемость потока, часть 1
- ^ Phaal, Питер; Лавин, Марк (июль 2004 г.). "sFlow Версия 5". sFlow.org. Получено 2010-10-23.
внешняя ссылка
- NetFlow / FloMA: указатели и программное обеспечение, предоставляемые SWITCH. - Один из самых полных списков, включающий все исследования с открытым исходным кодом и исследования.
- FloCon - Ежегодная конференция CERT / CC, посвященная данным и анализу сетевых потоков.
- Основная информация о NetFlow на сайте Cisco
- RFC3334 - Учет на основе политик
- RFC3954 - NetFlow версии 9
- RFC3917 - Требования к экспорту информации IP-потока (IPFIX)
- RFC3955 - протоколы-кандидаты для экспорта информации IP-потока (IPFIX)
- RFC5101 - Спецификация протокола экспорта информации IP-потока (IPFIX) для обмена информацией о потоке IP-трафика (IPFIX)
- RFC5102 - информационная модель для экспорта информации IP-потока
- RFC5103 - Экспорт двунаправленного потока с использованием экспорта информации IP-потока
- RFC5153 - Руководство по внедрению IPFIX
- RFC5470 - Архитектура для экспорта информации IP-потока
- RFC5471 - Руководство по тестированию экспорта информации IP-потока (IPFIX)
- RFC5472 - Применимость экспорта информации IP-потока (IPFIX)
- RFC5473 - Уменьшение избыточности в отчетах об экспорте информации IP-потока (IPFIX) и о выборке пакетов (PSAMP)
- Описание Paessler IT - NetFlow
- Использование Netflow для хранения повторно агрегированных входящих и исходящих потоков
- Спецификации и стандарты AppFlow отслеживают обсуждение
- Понимание анимации по принципу NetFlow
- Основы NetFlow и Flow Cache
- Список анализаторов и сборщиков Netflow