Экспортер NetFlow - это маршрутизатор, коммутатор или специализированное ПО, которые собирают трафик, проходящий через сеть/интерфейс и экспортируют его в другой компьютер/устройство, т.е. в собственно коллектор для сохранения и анализа.

Экспортер NetFlow проверяет каждый пакет трафика, проходящий через него. Затем категоризует его согласно определенным критериям и обновляет внутренний кэш, который содержит данные, которые соответствуют каждому потоку. Время от времени экспортер отправляет (экспортирует) текущий набор записей потоков в коллектор NetFlow и очищает кэш.

Краткий ответ гласит: немного. Коммутатор или маршрутизатор суммирует информацию о потоках и, как правило, отсылает данные о потоках каждые 60 или 120 секунд (это настраивается).
Более подробнее, вы можете узнать на сайте компании Lancope, где есть NetFlow Bandwidth Calculator.

Специалисты Сisco постоянно занимаются разработкой методик, позволяющих улучшить планирование емкости сети. При этом используются технологии NetFlow и некоторые внешние решения (например, Lancope StealthWatch), позволяющие собирать и анализировать сетевой трафик. Это дает следующие преимущества:

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

Более подробно см. Case Study на сайте Cisco.

Для этой цели может использоваться LInEX (Lightweight Information Export), pmacct,работающий как с NetFlow так и с IPFIX, и libipfix.
Есть еще YAF(yet another Flowmeter), который уже имеет отзывы по своему внедрению. См. tools.netsa.cert.org/yaf.

Когда таблица заполнена, никакой статистики потоков получить не удастся. Если заполнение таблицы NetFlow превышает рекомендованные значения, увеличивается возможность, что не будет достаточно места для сохранения статистики. Ниже приведены эти рекомендованные значения.

PFC	Рекомендованное значение заполнения таблицы NetFlow	Полная емкость таблицы NetFlow
PFC3BXL	235,520 (230 K) entries	262,144 (256 K) entries
PFC3B	117,760 (115 K) entries	131,072 (128 K) entries
PFC3A	65,536 (64 K) entries	131,072 (128 K) entries
PFC2	32,768 (32 K) entries	131,072 (128 K) entries

Для того, чтобы контролировать использование таблицы в процессоре коммутатора и DFC, используйте команду mls netflow usage notify. Если такой контроль включен и заполнение таблицы превысит рекомендованное значение, появится предупреждающее сообщение. Вот форма команды:

mls netflow usage notify {threshold interval}

где threshold - пороговое значение в процентах, по превышении которого появляется предупреждающее сообщение, значения могут быть в диапазоне от 20 до 100%; а interval определяет частоту, с которой будет проверяться использование таблицы NetFlow, значения могут быть в диапазоне от 120 до 1000000 секунд.

Традиционный NetFlow передает информацию IP Next Hop, которая может использоваться для обеспечения полной прозрачности путей прохождения потоков данных. Функция NetFlow BGP Next Hop (NetFlow Border Gateway Protocol Next Hop) добавляет информацию BGP Next Hop в экспортируемые данные. Функция позволяет сервис-провайдерам отслеживать чей (какого провайдера) трафик проходит по  определеному пути, что полезно, если существуют договоренности между различными сервис-провайдерами о доставке трафика без потерь и задержек. Это позволяет провайдерам также оценивать трафик попакетно в случаях, когда доставка трафика осуществялется по дорогостоящему маршруту, например при использовании трансатлантических линий.
При использовании этой функции в каждую запись потока добавляется 16 байтов информации. Это, соответственно, увеличивает требования к используемой памяти.
При этом, поскольку эта информация считывается единожды для потока, влияние включения этой функции на производительность является минимальной.

MRTG и другие аналогичные инструменты используют информацию, которая в основном ограничена статистикой SNMP. NetFlow же предоставляет значительно больше деталей на уровне приложений, таких как хосты, протоколы, конверсации, которые являются неотъемлемой частью IP-трафика.

Чтобы получить точную информацию, каким образом влияет включение NetFlow на производительность вашего роутера или коммутатора Cisco, посмотрите следующий документ - NetFlow Performance Analysis или обратитесь к NetFlow Bandwidth Calculator на сайте Lancope.

Менее 5 минут. Только убедитесь, что вы правильно сконфигурировали ваш маршрутизатор или коммутатор.

Вопрос, что лучше, NetFlow или sFlow, обсуждался уже много раз и пришло время закончить дебаты. Вот, что мы думаем:
Люди, которые утверждают, что sFlow лучше, чем NetFlow, это те, кто не использовал и то и другое и не видит разницы.
И это мнение не какого-то определенного производителя, а скорее понимание, сформированное годами работы на этом поприще. Многие заказчики, хотят, чтобы "sFlow вел себя так же, как NetFlow". Действительно, многие клиенты, которые сталкиваются с необходимостью иметь дело с выборками данных, предпочитают внедрить генераторы NetFlow (иногда называемые "зондами (пробами) потоков"), такие как nBox или Cisco NGA, для создания NetFlow на SPAN-портах, чем иметь дело с трудностями, которые доставляет sFlow.
Не поймите нас превратно, NetFlow и IPFIX также доставляют проблемы. Механизм кэширования и экспорта NetFlow очень сложен для корректного внедрения, требует много ресурсов для своей работы, примеров внедрения с различным результатом очень много. NetFlow стал жертвой своей популярности. Каждый производитель хочет добавить поддержку NetFlow в свои роутеры, коммутаторы, файерволы, балансировщики нагрузки и оптимизаторы WAN, но они очень часто не обращаются к профессионалам и стараются сделать все сами, добиваясь того, что экспорт не всегда работает корректно. sFlow не имеет проблем со стандартизацией в первую очередь потому, что только несколько производителей его внедрили.
Но преимущества NetFlow существенно перевешивают его недостатки.

Нужна вся история
Хотя выборка и может использоваться с NetFlow, но она не является обязательным требованием. Люди вообще-то не любят выборки данных. Особенно люди из департамента безопасности. Действительно, если у вас есть достаточное количество пакетов за долгий период времени, вы, в принципе, можете работать на нужном уровне, но когда вы пытаетесь поймать проникновение, которое произошло за одну двухминутную HTTP SQL транзакцию, то вам необходимо иметь "всю историю".
Технология на базе выборок просто не может это обеспечить. Оно может читать только каждое 128 слово в "книге". И к концу чтения вы будете знать сюжетную линию, что делали действующие лица, но не более того. Аналитикам безопасности не хочется иметь дело с каждым 128 пакетом, они хотели бы иметь их все.

Лучшая поддержка коллекторов
Примерно 95% заказчиков потоковых коллекторов обращаются за поддержкой на тему NetFlow/IPFIX. Почти все оборудование поддерживает эти технологии и почти вся поддержка имеет отношение к этому. Конечно, заказчикам нужна поддержка и sFlow, но таких обращений мало. Поскольку все подобные технологии продвигаются вперед именно за счет потребностей заказчиков, то неудивительно, что производители больше развивают NetFlow.

Лучшая поддержка производителей
Кроме того, большая часть производителей внедряет поддержку NetFlow во всех своих новых продуктовых линейках. Например, продукты компании Cisco Cat6k w/Sup2T или Catalyst 4500E w/Sup7E. Даже другие компании занимаются инновациями на фронте NetFlow. Enterasys добавил мощную аппаратную поддержку NetFlow в свои коммутаторы серии r S Series и K Series . Аппаратная поддержка NetFlow исключает одну из основных проблем NetFlow - ее влияние на загрузку процессора.

Больше полей, больше инноваций
Необходимо также учесть, что за последние годы Cisco приложило много усилий для развития NetFlow. Flexible NetFlow, NBAR, MediaNet, ASA NAT export, PfR - можно долго продолжать список расширений. sFlow ничего подобного не имеет и я не уверен, что кто-либо работает над тем, чтобы сделать его лучше.

Файерволы адаптируют NetFlow
Тенденция развития файерволов - это размещение в местах, где более всего нужна видимость сети: в точках агрегирования и ключевых местах контроля доступа. NetFlow отлично подходит для измерения и мониторинга ключевых точек в сети. Производители файерволов наконец это поняли и сейчас фаерволы повсеместно включают в себя поддержку NetFlow/IPFIX. За исключением Fortinet, все производители фаерволов выбрали поддержку NetFlow или IPFIX. А именно: PaloAlto, CheckPoint, SonicWall и, естественно, Cisco ASA. Почему файерволы предпочитают NetFlow? Именно потому, что заказчикам нужна история целиком, а не выборка из нее.

NetFlow/IPFIX хорошо работает со всеми типами событий, не только с TCP/IP
sFlow фундаментально ориентирован на фреймы Ethernet. В своей сути sFlow создан для выборки пакетов. Не более того, и не менее. IPFIX и NetFlow v9 очень гибкие. NetFlow/IPFIX могут использоваться для экспорта любого типа структурированных данных. Действительно, поля переменной длины IPFIX могут даже использоваться для экспорта полуструктурированных данных, таких как URL, особенные для каждого вендора строки, или имена хостов. Для одновременного экспорта нескольких различных наборов данных могут использоваться различные шаблоны. sFlow не является достаточно гибкой технологией, удовлетворяющей современные сети. Несмотря на работу людей из sFlow.org, sFlow все-таки не так развивается, как IPFIX.

NetFlow хорошо работает поверх WAN, sFlow - нет
Маленький "грязный секрет" об sFlow, который предпочитают умалчивать, заключается в том, что количество sFlow, покидающего роутер прямо пропорционально скорости - количеству пакетов в секунду. Т.е. чем выше уровень bps на удаленном сайте, тем выше уровень записей sFlow, покидающих сайт. NetFlow, в свою очередь, базируется на количестве активных соединений, а не на скорости пакетов. Если я передаю файл в 500 Мб из А в В, то sFlow создаст несколько тысяч пакетных выборок, тогда как NetFlow создаст только два 46-байтных записи. Это именно тот пункт, где для большинства заказчиков решается вопрос смены технологии. Вполне возможно переполнить соединение WAN выборками sFlow. И, поскольку sFlow передается через двунаправленный UDP, нет никакой возможности сказать экспортеру замедлить передачу.

Дебаты о том, что лучше, ведутся уже давно. Попытаемся разобрать, в чем эти технологии схожи, и где их следует применять (где одна из них лучше другой).

Что такое поток (flow)?
Как указано в IETF, поток - это последовательность пакетов, посылаемых одним приложением в другое. Технология sFlow использует выборки, для получения масштабируемости. Архитектура системы sFlow состоит из множества устройств, обеспечивающих два типа выборок: случайные выборки пакетов и операций на уровне приложений и выборка с определенным  интервалом времени по счетчику. Выбранные данные о пакетах/операциях и счетчике отсылаются как датаграммы sFlow в центральный сервер с приложением, которое анализирует трафик и создает соответствующие отчеты - коллектор sFlow.Множество выборок sFlow могут отсылаться одной датаграммой.
sFlow может использоваться оборудованием или программным обеспечением и, хотя название sFlow означает, что речь идет именно о потоковой технологии, исходя из указанной выше информации, это вообще не потоковая технология. Этот термин (sFlow) имеет отношение больше к маркетингу. Подобные выборки пакетов не обеспечивают 100% точности, но дают результат с вычисляемой точностью.

Что такое NetFlow?
NetFlow - это действительно потоковая технология, в которой кэшируемые в оборудовании (например, роутере или коммутаторе) потоки агрегируют пакеты на основе определенных данных, чаще всего это набор семи ключевых полей:
    1. Интерфейс источника
    2. Тип сервиса
    3. IP-адрес источника
    4. IP-адрес приемника
    5. Порт (Layer 4) источника
    6. Порт (Layer 4) приемника
    7. IP-протокол
Когда потоки экспортируются, к этим данным добавляется значение объема (байтов) агрегированных или всех данных и данные счетчика пакетов, а также несколько других полей.  Пакеты, которые не соответствуют данным ключевых полей потоков в кэше,  создают уже новый набор потоков. В одной датаграмме могут отсылаться сразу много подобных наборов потоков. NetFlow обеспечивает 100% точность IP-трафика, хотя NetFlow поддерживает и пакетную выборку и потоковую выборку.

Что такое Flexible NetFlow?
Это в реальности никакой не новый формат экспорта. Скорее он базируется на архитектуре формата экспорта NetFlow v9 и делает несколько больше на этой основе. FnF является одним из лучших, хотя и наиболее сложных методов создания экспорта потоков на сегодняшний день. FnF позволяет пользователям экспортировать почти все, что проходит через роутер, включая целые пакеты и делает это в реальном времени, практически как sFlow.

Что такое IPFIX?
IPFIX - это предлагаемый стандарт для структурированной потоковой информации и он базируется на последней версии NetFlow (v9). Вследствие этого его иногда не совсем корректно называют NetFlow v10.

Что является стандартом - NetFlow или sFlow?
Ответ - ни то, ни другое. Если обратиться к сайту IETF, то можно найти RFC 3176, где обсуждается протокол sFlow, и RFC 3954, где речь идет о NetFlow v9. Эти технологии не являются стандартом. RFC означает "запрос на комментарии" (Request For Comment ), т.е. это не стандарт. IPFIX, который определяется в RFC 5101 - это предлагаемый стандарт. Не надо обращать внимание на документы, подобные выпущенному компанией Brocade, где говорится: "IPFIX страдает плохим принятием основных производителей и все еще имеет большинство недостатков NetFlow". Это просто неправда. Сейчас большинство вендоров уже внедрило или собирается внедрить поддержку IPFIX.

Что лучше масштабируется, sFlow или NetFlow?
Выборка может быть осуществлена с помощью и sFlow, и NetFlow, но она не может масштабироваться так, как этого хотелось бы большинству пользователей. Например, существенный рост объема трафика (как при DoS-атаках) может заставить sFlow делать выборку чаще, чем это нужно для сохранения параметра выборки 1:N. В случае NetFlow массивный объем пакетов, зависящий от атаки, даст нам просто несколько потоков с высоким объемом пакетов. Для NetFlow количество дополнительной работы минимально, особенно если мы сравним, как говорят, два апельсина от двух технологий, на одном оборудовании. В свое время была статья, где сравнивалась точность обоих технологий. В реальности случаются всяческие проблемы, и NetFlow предоставляет для анализа 100% всего трафика, а sFlow часто теряет трафик, который необходимо просмотреть, что делает sFlow практически непригодной технологией для обнаружения сетевых атак или анализа поведения.
Если sFlow не может обеспечить достаточную выборку для полезных измерений, или если NetFlow просто переполняет ваш коллектор потоков, то вам надо рассмотреть возможность перехода на Flexible NetFlow, где можно отконфигурировать экспорт так, чтобы посылать меньше деталей, но все равно сохранять 100%-точность. Например, можно рассмотреть такое сокращение, когда отсылается 5 полей, а не 7:
    1. Интерфейс источника
    2. Тип сервиса
    3. IP-адрес источника
    4. IP-адрес приемника
    5. IP-протокол
Когда из набора убирается информация о портах, то вы можете заметить, что объем экспортируемых потоков уменьшился на 75%! Если вам действительно надо видеть детали приложений, то организуйте экспорт NBAR, который также существенно уменьшает объем экспорта.

Если я должен использовать выборку, что я должен выбрать: выборку потоков или выборку пакетов?
Лучшим выбором является выборка потоков. Делая выборку 1 пакет из тысячи или даже уменьшая скорость выборки до 1 :100000 пакетов, вы усугубляете проблему неправильной репрезентативности. При выборке потоков, потоки с 10 пакетами выбираются также, как потоки со 100 000 пакетов. В результате, если вы хотите получить представление о приложениях в сети, то выборка потоков дает большую точность. Пакетная выборка, вероятнее всего, покажет наиболее основные приложения с большим количеством пакетов и полностью потеряет приложения с несколькими пакетами.  Отметим, что и sFlow и NetFlow поддерживают пакетную выборку в реальном времени, в зависимости от платформы.

Если NetFlow лучше, чем sFlow, почему кто-то еще использует sFlow?
Многие коммутаторы сегодня поддерживают только sFlow. Дело в том, что существует очень недорогой в реализации метод пакетной выборки с sFlow. В результате большинство производителей поддерживают эту технологию, в том числе и Cisco. Сейчас многие потребители думают, что они имеют единственный выбор для коммутаторов - sFlow. Однако уже есть несколько производителей, включая Cisco, которые поддерживают NetFlow и/или IPFIX на коммутаторах (например, Cisco 3750X с модулем 3KX или 3850).

Вывод
Из-за того, что большое сообщество поддерживает IPFIX (Astaro, Barracuda, Cisco, Citrix, Dell, Enterasys, Lancope, Plixer и др.), инновации в экспорте данных очень существенные. Это:
    • Сообщения Log
    • Сообщения об обнаруженных вирусах
    • VoIP
        ○ Джиттер и потери пакетов
        ○ Идентификатор звонящего
        ○ Кодек
        ○ SSRC
    • Задержка или Round Trip Time
    • URL
    • Перенаправленные соединения
    • Идентификаторы беспроводной сети
    • Имена логина конечных пользователей
С другой стороны, sFlow нуждается в поддержке большого сообщества пользователей и инновации, которые возникают у них, к сожалению, не могут сравниться с потоковыми технологиями типа NetFlow или IPFIX. Ну, и для завершения: если вы спросите любого пользователя, у которого в сети стоит оборудование поддерживающее и sFlow, и NetFlow, то они скажут: "Я предпочитаю собирать NetFlow, но sFlow все-таки лучше, чем ничего".

Кол-во активных элементов кэша потоков	Дополнительная загрузка процессора
10000	<  4%
45000	< 12%
65000	< 16%