Flowmon разрушает 4 мифа о Netflow

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

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

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

Профессиональный инструмент анализа, так называемый коллектор, визуализирует эти данные, чтобы показать горизонтальный трафик в вашей сети, что позволяет вам понять использование отдельных восходящих каналов в ваших локациях. Тем не менее, наиболее важным значением является использование flow для устранения неполадок в сети. Давайте рассмотрим пример. У пользователя возникают проблемы при подключении к серверу через службу SSH. Имея данные о flow-потоке, мы можем легко отследить, что от сервера не было ответа, и мы успешно исключили многие потенциальные первопричины, такие как время простоя сервера или сети, или плохая конфигурация. Диапазон причин был сокращен до того, что служба не работает или связь заблокирована брандмауэром, что значительно сокращает показатель среднего времени для устранения проблемы.

Рис. 1: Фильтр коммуникации пользователя с внешним сервисом. Хост не получает никакого ответа.

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

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

Опять же, давайте посмотрим на пример. Пользователь жалуется на отсутствие отклика. Анализируя традиционные flow-данные, мы можем увидеть схему трафика и подробности отдельных коммуникаций, установленных с компьютером пользователя. Кажется, нет ничего плохого, но мы не видим трафик, связанный с сервисом. Имея расширенную видимость, обеспеченную расширенным механизмом flow-данных Flowmon, мы можем легко определить причину. И так выясняем, что запрошенное имя неправильно настроено в службе DNS и выдает код «NXDOMAIN», что указывает на то, что запрошенное имя домена не существует и соответствующий IP-адрес не может быть предоставлен. Следовательно, сеанс не установлен.

Рис. 2: Фильтр коммуникации пользователя с внешним сервисом. Хост не получает никакого ответа.

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

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

Рис. 3: Принцип измерения показателей Мониторинга производительности сети (NPM)

Миф 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. Flow-данные проникают в корпоративную среду, и с непрерывным внедрением облачных технологий, IoT, SDN и повсеместным ростом пропускной способности эта тенденция будет только продолжаться.

 

Хотите узнать больше? Вы можете попробовать онлайн-ДЕМО Flowmon или загрузить бесплатную пробную версию.

Автор: Павел Минарик

Как главный технический директор Flowmon Networks, Павел отвечает за разработку технологической карты, дизайн и разработку продукта, а также за техническую поддержку и проекты клиентов по всему миру.

Источник ►