Четыре мифа о Netflow

Flow-данные (NetFlow/IPFIX и т. д.) широко известны в ИT-сообществе на протяжении многих лет и используются, например, в таких случаях, как биллинг, планирование мощностей и защита от DDoS-атак, в основном в сегменте Telco. ИT-менеджеры и ИT-директора предприятий и организаций только недавно начали изучать их огромный потенциал. Тем не менее в сетевом сообществе все еще сохраняются мифы, препятствующие более быстрому внедрению flow-технологий. Павел Минарик, CTO Flowmon Networks, рассмотрит четыре основных.

Миф 1. Flow-данные – выборочные и неточные

Это утверждение действительно верно для стандартов sFlow или NetFlow Lite, поддерживаемых на устаревших устройствах и используемых клиентами малого и среднего бизнеса. Все крупные поставщики сетевого оборудования для предприятий предоставляют маршрутизаторы и коммутаторы, способные экспортировать высокоточную статистику трафика. В последнее время общая доступность flow-данных резко возросла. Все крупные поставщики брандмауэров поддерживают экспорт flow-потоков, а платформы виртуализации обеспечивают их видимость. Даже экономичные устройства, такие как маршрутизаторы Mikrotik, могут предоставить точную статистику.

Миф 2. Прозрачность Flow ограничена видимостью L3/L4

Это исходный дизайн. Flow-данные представляют собой единый поток пакетов в сети с идентичным 5-ступенчатым идентификатором, состоящим из IP-адреса источника, IP-адреса назначения, порта источника, порта назначения и протокола. На основании этого пакеты объединяются в записи потока, которые накапливают объем передаваемых данных, количество пакетов и другую информацию из сетевого и транспортного уровня. Однако более пяти лет назад появилась концепция потоковых данных, расширенная информацией из прикладного уровня. Эта концепция в последнее время широко применяется многими поставщиками. Таким образом, подробное представление о протоколах приложений, таких как HTTP, DNS и DHCP, не является проблемой в наши дни. Фактически это переводит варианты устранения неполадок на совершенно другой уровень.

Миф 3. Flow-данные не используют показатели сетевой эффективности

До этого мы говорили о поиске неисправностей. Другая часть головоломки – это мониторинг производительности сети. Мониторинг сети не обеспечивается исключительно за счет захвата пакетов. Показатели производительности сети могут быть легко извлечены из пакетных данных и экспортированы как часть статистики потока. Индикаторы производительности, такие как RTT, SRT, jitter или количество повторных передач, прозрачно доступны для всего сетевого трафика, независимо от протокола приложения. Учитывая его преимущества, такой подход был принят рядом крупных вендоров, которые предоставляют эти показатели как часть своего расширения AVC (видимость и контроль приложений) ART (время отклика приложений). Это означает, что вы можете измерить производительность всех приложений, работающих в локальной среде, в частном облаке, а также в общедоступной облачной среде.

Миф 4. Flow не является комплексным инструментом для мониторинга и диагностики эффективности сети

Согласно Gartner, основной целью инструментов NPDM является предоставление показателей производительности путем использования полных пакетных данных и возможности исследовать проблемы сети методом анализа полных трассировок пакетов. Но действительно ли нам нужно решение для захвата пакетов? Нет. Расширенные flow-данные обеспечивают точную статистику трафика, видимость в L7 (протоколы приложений) и метрики производительности сети, что позволяет полностью использовать сценарии использования NPMD.

На самом деле с ростом зашифрованного трафика, разнородных сред и с увеличением скорости сети неизбежно, что flow станет преобладающим подходом в области NPMD. Увеличение пропускной способности бросает значимый вызов устаревшим пакетным решениям. Давайте посмотрим на простой пример. Магистраль сети емкостью 10G потребует до 108 Тбайт хранилища данных для отслеживания всего сетевого трафика в течение 24 часов. Это огромный объем данных, которые необходимо собирать, хранить и анализировать, что делает весь процесс чрезвычайно дорогим.

В действительности вам понадобится только часть их. Для потоковых данных в той же ситуации потребуется около 250 Гбайт емкости, что позволяет хранить 30-дневную историю на коллекторе, оснащенном 8 Тбайт памяти.

Представим, что вам нужно устранить очень специфическую проблему с неподдерживаемым протоколом приложения, когда в flow-данных отсутствует видимость. В таком случае нужен инструмент на основе захвата пакетов, верно? На самом деле, не совсем. Наличие зонда означает, что у вас есть доступ к полному пакету данных в любом случае. Таким образом, вместо того, чтобы просто извлекать все метаданные из пакетов, вы задаете Probe задачу запустить захват пакетов. Эта задача будет ограничена во времени и строго сфокусирована на записи пакетов, имеющих отношение к вашему исследованию. Таким образом, выборочный захват пакетов по требованию легко обрабатывается даже в 10G-среде без необходимости в большой емкости хранилища.

Flow-данные в динамике будущего

Flow-данные – больше не игрушка, доступная только в нескольких случаях ограниченного использования. Технология расширенных flow-данных настолько созрела, что стала современным инструментом, обеспечивающим достаточную степень детализации для решения сетевых инцидентов, проблем конфигурации, планирования емкости и многого другого. По сравнению с инструментами непрерывного захвата пакетов она дополнительно обладает непревзойденной масштабируемостью, гибкостью и простотой использования. В результате flow-данные экономят время, снижают MTTR и общую стоимость сетевых операций. Flow-данные не ограничиваются работой сети, мониторингом производительности и устранением неполадок. Это основа для анализа поведения сети, способная обнаруживать и сообщать о показателях компрометации, удаленном движении, APT, сетевых атаках и т.д.

Flow-данные проникают в корпоративную среду, и с непрерывным внедрением облачных технологий, IoT, SDN и повсеместным ростом пропускной способности эта тенденция будет только продолжаться.