NetFlow — это функция, которая была введена в маршрутизаторах Cisco около 1996 года, которая обеспечивает возможность сбора трафика IP-сети, когда он входит или выходит из интерфейса. Анализируя данные, предоставленные NetFlow, сетевой администратор может определить такие вещи, как исходный и конечный трафик, класс обслуживания и причины перегрузки. Типичная настройка мониторинга потока (с использованием NetFlow) состоит из трех основных компонентов: [1]
Маршрутизаторы и коммутаторы, поддерживающие NetFlow, могут собирать статистику IP- трафика на всех интерфейсах, где включен NetFlow, а затем экспортировать эту статистику в виде записей NetFlow по крайней мере одному сборщику NetFlow — обычно это сервер, который выполняет фактический анализ трафика .
Стандарт Cisco NetFlow версии 5 определяет поток как однонаправленную последовательность пакетов, которые имеют семь общих значений, определяющих уникальный ключ для потока: [2]
Обратите внимание, что выходной интерфейс, IP Nexthop или BGP Nexthops не являются частью ключа и могут быть неточными, если маршрут изменится до истечения срока действия потока или если балансировка нагрузки выполняется для каждого пакета.
Это определение потоков также используется для IPv6, и аналогичное определение используется для потоков MPLS и Ethernet .
Расширенные реализации NetFlow или IPFIX, такие как Cisco Flexible NetFlow, допускают определяемые пользователем ключи потока.
Типичный вывод инструмента командной строки NetFlow ( nfdump
в данном случае) при печати сохраненных потоков может выглядеть следующим образом:
Дата начала потока Продолжительность Proto Src IP Addr:Port Dst IP Addr:Port Пакеты Байты Потоки 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. Простое оборудование без сохранения состояния также может фильтровать или изменять адрес назначения пакетов NetFlow UDP, если это необходимо. Поскольку экспорт NetFlow почти использует только магистральные сетевые соединения, потеря пакетов часто будет незначительной. Если это произойдет, то в основном это будет на соединении между сетью и коллекторами NetFlow.
Все пакеты NetFlow начинаются с заголовка, зависящего от версии, который содержит как минимум следующие поля:
Запись NetFlow может содержать разнообразную информацию о трафике в данном потоке.
NetFlow версии 5 (одна из наиболее часто используемых версий, за ней следует версия 9) содержит следующее:
Для потоков 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 был разработан для обработки всех IP-пакетов на интерфейсе. Но в некоторых средах, например, на интернет-магистралях, это было слишком затратно из-за дополнительной обработки, необходимой для каждого пакета, и большого количества одновременных потоков.
Поэтому Cisco представила образец NetFlow на Cisco 12000 , и теперь он используется во всех маршрутизаторах высокого класса, реализующих NetFlow.
Обрабатывается только один пакет из n , где n , частота дискретизации, определяется конфигурацией маршрутизатора.
Точный процесс выбора зависит от реализации:
В некоторых реализациях используются более сложные методы выборки пакетов, например, выборка по потокам на коммутаторах Cisco Martinez Catalyst.
Частота выборки часто одинакова для всех интерфейсов, но может быть скорректирована для каждого интерфейса для некоторых маршрутизаторов. При использовании Sampled NetFlow записи NetFlow должны быть скорректированы с учетом эффекта выборки — объемы трафика, в частности, теперь являются оценкой, а не фактически измеренным объемом потока.
Частота дискретизации указывается в поле заголовка NetFlow версии 5 (одинаковая частота дискретизации для всех интерфейсов) или в записях параметров NetFlow версии 9 (частота дискретизации на интерфейс).
NetFlow изначально был реализован Cisco и описан в «информационном» документе, который не был на пути стандартов: RFC 3954 – Cisco Systems NetFlow Services Export Version 9. Сам протокол NetFlow был заменен Internet Protocol Flow Information eXport ( IPFIX ). Основанный на реализации NetFlow Version 9, IPFIX находится на пути стандартов IETF с RFC 5101 (устарел из-за RFC 7011), RFC 5102 (устарел из-за RFC 7012) и т. д., которые были опубликованы в 2008 году.
Многие поставщики, помимо Cisco, предоставляют схожую технологию мониторинга сетевого потока. NetFlow может быть распространенным названием в области мониторинга потока из-за доминирующей доли Cisco на рынке сетевых технологий. NetFlow считается торговой маркой Cisco (хотя по состоянию на март 2012 года она не была указана в списке торговых марок Cisco [3] ):
Также набор программного обеспечения flow-tools [5] позволяет обрабатывать и управлять экспортом NetFlow с маршрутизаторов Cisco и Juniper. [6]
Представленная с запуском продуктов Cisco ASA 5580, система регистрации событий безопасности NetFlow использует поля и шаблоны NetFlow v9 для эффективной доставки телеметрии безопасности в высокопроизводительных средах. Система регистрации событий безопасности NetFlow масштабируется лучше, чем syslog , при этом обеспечивая тот же уровень детализации и гранулярности в регистрируемых событиях. [ необходима цитата ]
Сбор NetFlow с использованием автономных зондов NetFlow является альтернативой сбору потоков с маршрутизаторов и коммутаторов. Такой подход позволяет преодолеть некоторые ограничения мониторинга NetFlow на основе маршрутизаторов. Зонды прозрачно подключаются к контролируемому каналу как пассивное устройство с использованием порта TAP или SPAN устройства.
Исторически сложилось так, что мониторинг NetFlow проще реализовать в выделенном зонде, чем в маршрутизаторе. Однако этот подход также имеет некоторые недостатки:
Самый простой способ устранения вышеуказанных недостатков — использовать встроенное устройство захвата пакетов перед маршрутизатором и захватывать все выходные данные 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. Затем эта запись использовалась бы для всех последующих пакетов того же потока, до истечения срока действия потока. Только первый пакет потока требовал бы исследования таблицы маршрутизации для поиска наиболее точного совпадающего маршрута. Это дорогостоящая операция в программных реализациях, особенно старых без Forwarding information base . Запись коммутации 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 .