Вопрос, что лучше, 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, нет никакой возможности сказать экспортеру замедлить передачу.
Меню сайта