Comments 32
3D-версия Cisco Packet Tracer'а просто шикарна!
спасибо большое, как раз дали на работе задание разобраться с задвоением трафика приходящего с NetFlow…
Кстати, у других вендорово тоже бывает своя реализация этого функционала. Например, у Huawei это Netstream. Принцип работы очень похож.
А где вы таких шикарных уточек купили? Я тоже такие хочу.
Насколько я знаю, с Netflow может быть две довольно больших проблемы:
1. При большом потоке данных под Netflow может тратиться довольно большое количество системных ресурсов на экспорт.
2. (Наверное, частично следствие первого пункта) Опять же при большом потоке данных могут быть потери Netflow. Flowtools даже говорят, сколько потеряно.
Вроде, специально для решения этих проблем придумали sampled netflow
1. При большом потоке данных под Netflow может тратиться довольно большое количество системных ресурсов на экспорт.
2. (Наверное, частично следствие первого пункта) Опять же при большом потоке данных могут быть потери Netflow. Flowtools даже говорят, сколько потеряно.
Вроде, специально для решения этих проблем придумали sampled netflow
По первому пункту — все верно, при большом объеме трафика сенсор должен разобрать много пакетов, нагрузка возрастает.
По второму — не сталкивался никогда. Есть проблема с неидентифицированным трафиком, но про потери — нигде не встречал.
По второму — не сталкивался никогда. Есть проблема с неидентифицированным трафиком, но про потери — нигде не встречал.
1. Проблема не в большой нагрузке, а в слишком большой
2. Я бы не назвал неидентифицированный трафик проблемой. А по поводу lost'ов — тут, честно говоря, информация из вторых рук. Товарищ, который тестировал BRAS'ы, рассказывал, что железке при очень большом количестве юзеров и, соответственно, очень большом трафике просто не хватает буферов под Netflow. Касалось это только каких-то новых железок. Возможно, это были детские болезни.
2. Я бы не назвал неидентифицированный трафик проблемой. А по поводу lost'ов — тут, честно говоря, информация из вторых рук. Товарищ, который тестировал BRAS'ы, рассказывал, что железке при очень большом количестве юзеров и, соответственно, очень большом трафике просто не хватает буферов под Netflow. Касалось это только каких-то новых железок. Возможно, это были детские болезни.
Ну, когда не идентифицируется 95% трафика — это проблема. Досконально я описывал свою головную боль здесь. Железки и старые, и новые, все отчеты шлет. Я думаю, просто наш manageengine косячит.
Закономерно. Хардварные платформы, поддерживающие netflow, поддерживают его в железе и без штрафов производительности, но есть ограничения на размер flow table. Чудес не бывает
Торгану-ка своим топиком про то, как считывать NetFlow с ASA под FreeBSD/Linux.
Что еще можно добавить?
1) «ip route-cache flow» делать не стоит. Это — отдельный механизм форвардинга, CEF его на данном этапе полностью заменяет. Да, в современных IOSах есть защита от дурака, ничего не сломается, но все равно лучше сказать «ip flow ingress/egress».
2) Коммутируете по меткам? Забудьте про сбор netflow для тегированных пакетов. Но: Sup2T для cat6500 уже поддерживает MPLS-aware netflow. Приятно, черт побери.
3) Есть flexible netflow. Возможностей по докручиванию куда больше. Особенно в связке с NBAR. Но… Осторожнее.
1) «ip route-cache flow» делать не стоит. Это — отдельный механизм форвардинга, CEF его на данном этапе полностью заменяет. Да, в современных IOSах есть защита от дурака, ничего не сломается, но все равно лучше сказать «ip flow ingress/egress».
2) Коммутируете по меткам? Забудьте про сбор netflow для тегированных пакетов. Но: Sup2T для cat6500 уже поддерживает MPLS-aware netflow. Приятно, черт побери.
3) Есть flexible netflow. Возможностей по докручиванию куда больше. Особенно в связке с NBAR. Но… Осторожнее.
А можно как-нибудь на пальцах объяснить разницу между разными версиями протокола netflow? Чтобы понять, в каком случае какую версию лучше использовать — просто я в интернете в основном встречал про сбор трафика с 5-ой версии netflow, правда это было лет 5-7 назад, когда решал задачу сбора трафика. Может быть придется озадачиться и переписать то решение под 9-ю версию, что работает сейчас с 5-й.
Английскую википедию по этому вопросу почитал, но интересует мнение тех, кто с этим работает.
Английскую википедию по этому вопросу почитал, но интересует мнение тех, кто с этим работает.
Потоком считается набор пакетов, проходящих в одном направлении. Когда сенсор определяет, что поток закончился (по изменению параметров пакетов, либо по сбросу TCP — сессии), он отправляет информацию в коллектор. В зависимости от настроек он также может периодически отправлять в коллектор информацию о все еще идущих потоках [2].
Осмелюсь переписать этот абзац, потому как многие фразы звучат очень неоднозначно: «в одном направлении», «по сбросу TCP-сесии». Также надеюсь, что после моего комментария выполнение некоторых команд в CLI станет немного понятнее.
Все пакеты у которых совпадают source/destination IP адреса, source/destination порты, номер протокола, интерфейс и класс сервиса — группируются в поток (flow) и затем эти пакеты и байты начинают подсчитываться, а информация о них записываться в NetFlow database, называемой NetFlow cache.
Процесс в маршрутизаторе, коммутаторе, etc., ответственный за NetFlow осуществляет поиск по записям кэша, с целью найти такие потоки:
— были бы затерменированы
— время жизни которых истекло(простаивает в течении заданного времени — inactive flow timer)
— долгоживущие(продолжающиеся дольше заданного порога — active flow timer).
Затерминированными считаются те потоки, семантика транспортного протокола которых свидетельствует о завершении сессии, например для TCP сесии был получен пакет с TCP флагами FIN или RST. После того как поток по заданным выше условиям был найден, данные о нем экспортируется на коллектор.
В случае с долгоживущими потоками, информация о них может разбиваться на несколько записей, которые объединяются уже коллектором в общий поток трафика.
Т.к. в коментариях встретил обсуждения вопроса влияния на производительность, скину полезную ссылку на первоисточник: NetFlow Performance Analysis
«ip route-cache flow» может использоваться только для основного интерфейса, а «ip flow ingress» — это расширение для использования для сабинтерфесов.
ip route-cache flow — устаревшая команда, которая осталась для совместимости. Была заменена на ip flow ingress
Хорошо бы обсудить вопрос анализа трафика и выдачи отчётов по нему. Пока что более-менее приемлемым решением является ManageEngine NetFlow Analyzer, но он несколько «тугой» в плане веб-морды и юзабилити, да ещё и нехватает некоторых элементарных возможностей.
Кто-нибудь знает приемлимые альтернативы NetFlow Analyzer? Чтоб с настройкой через веб, с генерацией отчётов и т.д.?
Кто-нибудь знает приемлимые альтернативы NetFlow Analyzer? Чтоб с настройкой через веб, с генерацией отчётов и т.д.?
Вот это либо нужно убрать
либо дописать раздел про возможность установки отдельного коллектора/преобразователя в сеть (можно зарубить бабла на рекламе -.- ), который будет получать зеркалированный трафик, и генерировать на его основании netflow потоки.
А то, простите, не пришей козе баян получается. Хошь думай что SPAN и Netflow это теже технологии, хошь гадай.
. Во многих источниках упоминается возможность «зеркалирования» порта коммутатора, почти все современные коммутаторы поддерживают эту возможность.
либо дописать раздел про возможность установки отдельного коллектора/преобразователя в сеть (можно зарубить бабла на рекламе -.- ), который будет получать зеркалированный трафик, и генерировать на его основании netflow потоки.
А то, простите, не пришей козе баян получается. Хошь думай что SPAN и Netflow это теже технологии, хошь гадай.
А к чему тут кусок настройки SNMP сервера и трапов?
Для экспрота netflow — snmp настраивать не нужно.
Для экспрота netflow — snmp настраивать не нужно.
Потоком считается набор пакетов, проходящих в одном направлении. Когда сенсор определяет, что поток закончился (по изменению параметров пакетов, либо по сбросу TCP — сессии), он отправляет информацию в коллектор. В зависимости от настроек он также может периодически отправлять в коллектор информацию о все еще идущих потоках [2].
Это очень важный момент — при настройке сенсора мы сами решаем, по каким параметрам отосланная на коллектор информация будет объединена в отчетах.
Это действительно очень важный момент, но в википедии не расшифровано, что это означает. Поясню следующее, что циска может отправлять 4 типа NetFlow данных: DENIED, CREATED, UPDATED, DELETED (Torn Down). Если вы будете считать данные по всем таким данным, то вы получите удвоенный трафик! Так вот, чтобы такого не было, нужно считать трафик либо CREATED + UPDATED, либо только DELETED (Torn Down). Не удивлюсь, что у большинства админов, в настройках циски указан тип ALL, после чего не понимают откуда у них идет удвоение трафика. Все эти моменты с учетом трафика по NetFlow я изложил в своей статье http://habrahabr.ru/post/220431/
Sign up to leave a comment.
NetFlow, Cisco и мониторинг трафика