NetFlow, Cisco и мониторинг трафика. Пора разобраться

    Всем доброго времени суток! Разбираясь с NetFlow, таким простым, удобным и часто используемым протоколом, я осознал, что он не такой уж и простой, и подводных камней при его эксплуатации хватает.
    Под катом я собрал все, что для начала необходимо знать о NetFlow и его настройках на Cisco, отдал дань eucariot, пишущему отличные статьи о сетях, и… Картинки, немного веселых картинок.

    Определимся с основными понятиями


    NetFlow — проприетарный открытый протокол, разработанный Cisco для мониторинга трафика в сети. Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP.
    Архитектура системы строится на сенсоре, коллекторе и анализаторе:
    — Сенсор собирает статистику по проходящему через него трафику. Сенсоры имеет смысл ставить в «узловых точках» сети, например, на граничных маршрутизаторах сегментов сети.
    — Коллектор осуществляет сбор информации от сенсоров. Полученные данные он сбрасывает в файл для дальнейшей обработки. Различные коллекторы сохраняют данные в различных форматах.
    — Анализатор, или система обработки, считывает эти файлы и генерирует отчеты в форме, более удобной для человека. Эта система должна быть совместима с форматом данных, предоставляемых коллектором [1]. В современных системах коллектор и анализатор часто объединены в одну систему.



    Обычно коллектор и анализатор являются частями одного программного комплекса, работающего на сервере. Разновидностей ПО коллектор/анализатор множество, платные и бесплатные, под Windows и Unix-системы.
    В статье я не буду затрагивать эту область, рассмотрю только принципы работы NetFlow и настройку сенсора на Cisco.
    Нужно сразу уяснить — коллектор и стоящий за ним анализатор являются «пассивными» элементами системы. Сенсор шлет на коллектор отчеты о трафике, коллектор принимает, анализатор анализирует, и заполняет свою базу данных на сервере. По сути, при поднятом сервере, нам не нужно вручную подключать устройства, подпадающие под мониторинг, на сервере. Пока сенсор шлет отчеты, коллектор их принимает, анализатор регистрирует. Если сенсор выключен, он «исчезает» из текущей «он-лайн» статистики.



    Описание протокола


    NetFlow использует UDP или SCTP для передачи данных о трафике коллектору. Как правило, коллектор слушает порт 2055, 9555 или 9995 (или тот, который Вы укажете при настройке коллектора и сенсора).
    Сенсор выделяет из проходящего трафика потоки, характеризуемые следующими параметрами:
    • Адрес источника;
    • Адрес назначения;
    • Порт источника для UDP и TCP;
    • Порт назначения для UDP и TCP;
    • Тип и код сообщения для ICMP;
    • Номер протокола IP;
    • Сетевой интерфейс (параметр ifindex SNMP);
    • IP Type of Service.
    Потоком считается набор пакетов, проходящих в одном направлении. Когда сенсор определяет, что поток закончился (по изменению параметров пакетов, либо по сбросу TCP — сессии), он отправляет информацию в коллектор. В зависимости от настроек он также может периодически отправлять в коллектор информацию о все еще идущих потоках [2].
    Это очень важный момент — при настройке сенсора мы сами решаем, по каким параметрам отосланная на коллектор информация будет объединена в отчетах.

    Собственно, настройка


    Разберем конфигурацию сенсора при настройке на Cisco:

    Router_NF# conf t
    Router_NF(config)# ip flow-export destination 192.168.0.1 9996
    Router_NF(config)# ip flow-export destination 10.10.0.1 9996
    Router_NF(config)# ip flow-export version 9
    В конфигурационном режиме указываем адреса коллектора и порты, куда отправлять статистику, указываем версию протокола NetFlow. В сложной сети можно иметь два интерфейса коллектора, если есть какие-то ограничения маршрутизации между сегментами
    Router_NF(config)# ip flow-cache timeout active 1
    Указываем, как часто обновлять кэш NetFlow данными о трафике еще активной сессии
    Router_NF(config)# ip flow-cache timeout inactive 15
    Указываем время, в течение которого если в существующем потоке не передаются данные, то он закрывается, и информация о нем записывается в кэш, а затем передается на коллектор
    Router_NF(config)# ip flow-export source FastEthernet 0/0
    Router_NF(config)# ip flow-export source vlan4
    Router_NF(config)# ip flow-export source Port-channel1.2
    Источники отчета о трафике, статистика будет собираться с них. На стороне анализатора будут отдельно промониторены и интерфейс, и VLAN, и Port-channel
    !
    ip access-list standard iacl-snmp
    remark ACL for SNMP access to device
    permit 192.168.0.1
    permit 10.10.0.1
    deny any log
    !
    Добавим ACL для более гармоничного фэн-шуя
    !
    snmp-server group snmp v1 access iacl-snmp
    snmp-server group snmp v2c access iacl-snmp
    snmp-server community ******** **** iacl-snmp
    snmp-server ifindex persist
    snmp-server trap-source Loopback0
    snmp-server enable traps tty
    !
    Настраиваем snmp для правильного распознавания имен интерфейсов
    Наконец дошло до интерфейса:
    Router_NF(config)# interface FastEthernet 0/0
    Router_NF(config-if)# ip flow egress
    Router_NF(config-if)# ip flow ingress
    Указываем, какой трафик будет учитываться, входящий в интерфейс или исходящий из него? Если исходящий, то ip flow egress, если входящий, то ip flow ingress
    Или
    Router_NF(config-if)# ip route-cache flow
    «ip route-cache flow» может использоваться только для основного интерфейса, а «ip flow ingress» — это расширение для использования для сабинтерфесов. Функционал NetFlow Subinterface Support позволяет включать NetFlow для каждого сабинтерфейса. В сценарии, когда ваша сеть содержит множество сабинтерфейсов, а вам необходимо собирать записи только с некоторых, вы можете тонко настроить сбор информации только с определенных сабинтерфейсов [3]

    Что можно посмотреть на сенсоре:


    Router_NF# show ip cache flow
    Информация о трафике, ожидающая отправки на коллектор
    Router_NF# show ip cache verbose flow
    Детальная информация о трафике, ожидающая отправки на коллектор
    Router_NF# show ip flow interface
    Интерфейсы, являющиеся сенсорами NetFlow
    Router_NF# show ip flow export
    source и destination отчетов NetFlow, сколько отправлено дэйтаграмм, сколько ошибок
    Router_NF# show ip flow top-talkers
    Информация о чемпионах, представлена категорийно, вплоть до самых посещаемых интернет — ресурсов
    По основной настройке все, полезные ссылки для более полного просветления [4], [5] и [6].

    Ложка дегтя


    «Другой» трафик. Как известно, за многими распространенными приложениями закреплены свои порты, рассмотрим
    часть вывода show ip cache flow

    Рисунок взят из [7].
    Однако с течением времени доля трафика, попадающего в раздел «Other», растет, в связи с ростом числа приложений, использующих динамические, случайно сгенерированные порты.
    В документе [8], обозревающем NetFlow, вскользь упоминается проблема, хорошо проиллюстрированная на рисунке


    Конечно, хотелось бы, чтобы самый разный трафик четко описывался в отчетах, например:
    Отличная таблица, взята из статьи, не смог пройти мимо
    Категория трафика Порты Протокол прикладного уровня
    Mail 25, 109, 110, 113, 143 smtp, pop2, pop3, ident, imap
    Web 80, 8080, 443 http, https
    data 20, 21, 3306, 66, 1521, 1526, 1524 ftp, MySQL, sqlnet, Oracle, Ingres
    Network management 53, 137, 138, 139, 445, 161, 123, 783, 8200 domain, netbios, snmp, ntp, spamassassin, GoToMyPC
    Interactive 22, 23, 513, 543 ssh, telnet, rlogin, klogin
    nntp 119 nntp
    Chat 194, 6891–6901, 1863, 5050, 5190 irc, msn messenger, yahoo messenger, ICQ
    streaming 554, 1755, 1220, 8000–8005, 7070, 7071, 6970 rtsp, ms-streaming, Apple quicktime, internet radio (shoutcast), Real Audio & Video
    Malware & games 1433, 1434, 666, 1999, 31337, 12345, 12346, 20034, 1024, 1025, 31338, 31339, 3127, 27015, 27016, 26000, 27001, 27960, 3724 Ms-sql-s, ms-sql-m, backdoor, Back Orifice, NetBus, netspy, myDoom, HalfLife, Quake, QuakeWorld, QuakeIII, WarCraft
    p2p 411, 412, 1214, 3531, 4111, 4661–4665, 4672, 6346, 6347, 6669,6881–6889, 23302, 32285, 59049, 41170, 57990 Direct Connect, Fasttrack, Kazaa, eDonkey, Gnutella, Napster, BitTorrent, Ares, Mp2p, Azureus
    Others - -


    Ссылка на нее [10].

    Прогресс не стоит на месте, технологии идут вперед, и шеф получит полный отчет проблему нераспознанного трафика решают разными интересными способами, например с помощью технологии NBAR.
    Во время поисков было найдено обсуждение [11] и интересная презентация [12]. Дальше в дебри не пойду, ибо юн, горяч и неопытен.

    Есть мнение, что у автора поста каша в голове, и он что-то упускает!


    P.S.
    В процессе написания статьи я, как мог, ответил на свои вопросы, и надеюсь, не поставил новых нигде не ошибся.
    Спасибо за внимание!
    Поделиться публикацией

    Комментарии 32

      0
      3D-версия Cisco Packet Tracer'а просто шикарна!
        0
        Спасибо! Её и буду впредь использовать.
        0
        спасибо большое, как раз дали на работе задание разобраться с задвоением трафика приходящего с NetFlow…
          0
          Рад, что пригодилось! На задвоение трафика много где натыкался, пока материал искал, это вроде бы связано с неверным использованием ingress egress.
            0
            а разве не с тем что на пути трафика несколько раз собирается трафик в коллектор?
              0
              Коллектор обычно работает на уровне интерфейсов. Да, место в базе это жрет нещадно. Но обычно так надо.
          0
          Кстати, у других вендорово тоже бывает своя реализация этого функционала. Например, у Huawei это Netstream. Принцип работы очень похож.
            0
            А где вы таких шикарных уточек купили? Я тоже такие хочу.
              0
              Собственно, в любом детском мире, в отделе для самых маленьких. Большой выбор цветов и размеров.
              Я много уточек набрал, но большие в кадр не влезли.
              0
              Насколько я знаю, с Netflow может быть две довольно больших проблемы:
              1. При большом потоке данных под Netflow может тратиться довольно большое количество системных ресурсов на экспорт.
              2. (Наверное, частично следствие первого пункта) Опять же при большом потоке данных могут быть потери Netflow. Flowtools даже говорят, сколько потеряно.
              Вроде, специально для решения этих проблем придумали sampled netflow
                0
                По первому пункту — все верно, при большом объеме трафика сенсор должен разобрать много пакетов, нагрузка возрастает.
                По второму — не сталкивался никогда. Есть проблема с неидентифицированным трафиком, но про потери — нигде не встречал.
                  0
                  1. Проблема не в большой нагрузке, а в слишком большой
                  2. Я бы не назвал неидентифицированный трафик проблемой. А по поводу lost'ов — тут, честно говоря, информация из вторых рук. Товарищ, который тестировал BRAS'ы, рассказывал, что железке при очень большом количестве юзеров и, соответственно, очень большом трафике просто не хватает буферов под Netflow. Касалось это только каких-то новых железок. Возможно, это были детские болезни.
                    0
                    Ну, когда не идентифицируется 95% трафика — это проблема. Досконально я описывал свою головную боль здесь. Железки и старые, и новые, все отчеты шлет. Я думаю, просто наш manageengine косячит.
                      0
                      Закономерно. Хардварные платформы, поддерживающие netflow, поддерживают его в железе и без штрафов производительности, но есть ограничения на размер flow table. Чудес не бывает
                        0
                        Спасибо за подсказку! Вот за это я и люблю Хабр — статью написал, опыт получил, люди почитали — ценными сведениями поделились.
                  +1
                  Торгану-ка своим топиком про то, как считывать NetFlow с ASA под FreeBSD/Linux.
                    0
                    Хе-хе, Ваш топик я тоже читал и частично брал из него информацию, жалко плюсануть не могу, срок давности вышел.
                      0
                      А Вы в карму попробуйте
                        0
                        Своей пока не хватает — извините.
                    0
                    Что еще можно добавить?
                    1) «ip route-cache flow» делать не стоит. Это — отдельный механизм форвардинга, CEF его на данном этапе полностью заменяет. Да, в современных IOSах есть защита от дурака, ничего не сломается, но все равно лучше сказать «ip flow ingress/egress».
                    2) Коммутируете по меткам? Забудьте про сбор netflow для тегированных пакетов. Но: Sup2T для cat6500 уже поддерживает MPLS-aware netflow. Приятно, черт побери.
                    3) Есть flexible netflow. Возможностей по докручиванию куда больше. Особенно в связке с NBAR. Но… Осторожнее.
                      0
                      А можно как-нибудь на пальцах объяснить разницу между разными версиями протокола netflow? Чтобы понять, в каком случае какую версию лучше использовать — просто я в интернете в основном встречал про сбор трафика с 5-ой версии netflow, правда это было лет 5-7 назад, когда решал задачу сбора трафика. Может быть придется озадачиться и переписать то решение под 9-ю версию, что работает сейчас с 5-й.
                      Английскую википедию по этому вопросу почитал, но интересует мнение тех, кто с этим работает.
                        0
                        В 9-й версии больше полей, она сильнее кастомизируется…
                        +1
                        Потоком считается набор пакетов, проходящих в одном направлении. Когда сенсор определяет, что поток закончился (по изменению параметров пакетов, либо по сбросу TCP — сессии), он отправляет информацию в коллектор. В зависимости от настроек он также может периодически отправлять в коллектор информацию о все еще идущих потоках [2].


                        Осмелюсь переписать этот абзац, потому как многие фразы звучат очень неоднозначно: «в одном направлении», «по сбросу TCP-сесии». Также надеюсь, что после моего комментария выполнение некоторых команд в CLI станет немного понятнее.

                        Все пакеты у которых совпадают source/destination IP адреса, source/destination порты, номер протокола, интерфейс и класс сервиса — группируются в поток (flow) и затем эти пакеты и байты начинают подсчитываться, а информация о них записываться в NetFlow database, называемой NetFlow cache.

                        image

                        Процесс в маршрутизаторе, коммутаторе, 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
                          0
                          0din, прекрасная правка! Спасибо Вам!
                          0
                          Хорошо бы обсудить вопрос анализа трафика и выдачи отчётов по нему. Пока что более-менее приемлемым решением является ManageEngine NetFlow Analyzer, но он несколько «тугой» в плане веб-морды и юзабилити, да ещё и нехватает некоторых элементарных возможностей.
                          Кто-нибудь знает приемлимые альтернативы NetFlow Analyzer? Чтоб с настройкой через веб, с генерацией отчётов и т.д.?
                            0
                            Кто-нибудь знает приемлимые альтернативы NetFlow Analyzer?

                            Solarwinds NTA например — из «дешево, сердито и удобно».
                              0
                              +1. Из коммерческих, low cost продуктов, пожалуй что Solarwinds NTA.
                            0
                            Вот это либо нужно убрать
                            . Во многих источниках упоминается возможность «зеркалирования» порта коммутатора, почти все современные коммутаторы поддерживают эту возможность.

                            либо дописать раздел про возможность установки отдельного коллектора/преобразователя в сеть (можно зарубить бабла на рекламе -.- ), который будет получать зеркалированный трафик, и генерировать на его основании netflow потоки.
                            А то, простите, не пришей козе баян получается. Хошь думай что SPAN и Netflow это теже технологии, хошь гадай.
                              0
                              Убрал. Дописывать раздел знаний не хватает. Я так понял, эта функция раньше использовалась активно, а когда стали реализовывать на железе, уже устарела.
                              0
                              А к чему тут кусок настройки SNMP сервера и трапов?
                              Для экспрота netflow — snmp настраивать не нужно.
                                +1
                                Для экспорта — не нужно. Но по фэншую — и ACL, и SNMP нужны. Чтобы имена интерфейсов видно было.
                                Настройки должны быть красивыми!
                                0
                                Потоком считается набор пакетов, проходящих в одном направлении. Когда сенсор определяет, что поток закончился (по изменению параметров пакетов, либо по сбросу TCP — сессии), он отправляет информацию в коллектор. В зависимости от настроек он также может периодически отправлять в коллектор информацию о все еще идущих потоках [2].
                                Это очень важный момент — при настройке сенсора мы сами решаем, по каким параметрам отосланная на коллектор информация будет объединена в отчетах.


                                Это действительно очень важный момент, но в википедии не расшифровано, что это означает. Поясню следующее, что циска может отправлять 4 типа NetFlow данных: DENIED, CREATED, UPDATED, DELETED (Torn Down). Если вы будете считать данные по всем таким данным, то вы получите удвоенный трафик! Так вот, чтобы такого не было, нужно считать трафик либо CREATED + UPDATED, либо только DELETED (Torn Down). Не удивлюсь, что у большинства админов, в настройках циски указан тип ALL, после чего не понимают откуда у них идет удвоение трафика. Все эти моменты с учетом трафика по NetFlow я изложил в своей статье http://habrahabr.ru/post/220431/

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое