NetFlow на оборудовании Cisco

NetFlow — замечательные протокол от Cisco Systems, который удобно использовать для учета сетевого трафика. Суть работы проста: на определенном интерфейсе (сенсоре) собирается статистика по  трафику проходящему через этот интерфейс в определенном направлении (inbound или outbound) и отправляется на некую систему мониторинга (коллектор), которая эти данные собирает, парсит, анализирует и представляет в удобном для администратора виде, все красиво и понятно. Сбор статистики осуществляется  на основе записей. Под записью в протоколе NetFlow (v9 или v5) понимается набор данных, в котором указано количество байт, переданных/принятых в рамках одного определенного соединения в определенном направлении.

Например в ходе http сессии между клиентом с IP 10.200.0.1:1921/tcp и сервером с IP 10.200.100.4:80/tcp от сервера до клиента (именно в этом направлении, а не весь трафик в рамках соединения) было передано 1200 кБайт вебтраффика. Получим такую NetFlow запись:

=============================

1. ipv4 tos: 0
2. ipv4 protocol: tcp
3. ipv4 source address: 10.200.100.4
4. ipv4 destination address: 10.200.0.1
5. transport source-port: 80
6. transport destination-port: 1921
7. interface: gig 0/1

Количество байт: 1200000.

============================

Поля, пронумерованные от 1 до 7 называются ключевыми полями и по ним оценивается, принадлежит ли трафик тому или иному потоку/записи. Т.е. пошли через интерфейс пакеты у которых эти семь параметров совпадают — берем и начинаем их считать, пока соединение не закроется или таймаут не истечет. Если, например, тот же хост откроет другое соединение с тем же сервером, у него скорее всего src port будет уже другим, и сервер, отвечая ему будет слать данные уже не на 1921 а, скажем, на 1412. В этом случае сформируется отдельная запись. После того как запись «готова»/закрыта (т.к. закрылось соединение или истек таймаут), информация о ней отправляется на коллектор (ту самую станцию мониторинга) которая все учтет и на своем графике дорисует, например, что в эту единицу времени через интерфейс прошло 1200 кбайт вебтрафика (плюс к тому, что уже было собрано за это время). В итоге мы имеем хорошую статистическую информацию о том, какого рода трафик в нашей сети имеет место быть, какие клиенты/участники межсетевого взаимодействия наиболее активны и в какое время суток, кто из сотрудников использует торрент, скайп и когда они это делают и все что угодно. Для лучшего восприятия, вот графическая интерпритация механизма работы NetFlow:

Простой пример — нужно на граничном, смотрящем в интернет, маршрутизаторе предприятия (в данном случае Cisco 2951) собрать статистику по входящему трафику (кто, сколько, какие протоколы) через интерфейс смотрящий в сторону провайдера (пусть GigabitEthernet 0/0). Т.е. нужно как-то классифицировать трафик, прилетающий от ISP (его PE-роутера) на интерфейс Gig0/0 Cisco 2951. Что для этого делаем? Понадобится всего две синтаксических конструкции и несколько простых шагов.

1. Flow Exporter. Это такая вещь, в которой указано, где находится станция мониторинга и на какой IP+порт ей нужно слать собираемые данные. Выглядит так:

flow exporter EXPORTER_TO_MONITOR
 destination 10.200.115.133 //IP станции мониторинга
source GigabitEthernet0/0  //Интерфейс, с которого будет отправляться статистика
 transport udp 9999  //порт, на котором станция мониторинга будет слушать прилетающий трафик (Netflow записи).

2. Flow Monitor. Конструкция, которая определяет параметры мониторинга/сбора статистики. В простейшем случае, как здесь, она просто ссылается на exporter, нарисованный на предыдущем шаге.

flow monitor OUTSIDE_IN //Название говорит, что мониторим трафик, прилетающий во внешний интерфейс (OUTSIDE) во входящем направлении (IN)
description Inside traffic on outside interface
record netflow-original
exporter EXPORTER_TO_MONITOR
  cache timeout active 300
!

Здесь мы указали, что для формировании записей будут использоваться стандартные семь ключевых полей (см. выше) и добавили cache timeout active, который говорит о том, что если соединение активно больше 300 секунд, информацию о нем нужно все равно отправить на станцию мониторинга, несмотря на то, что оно (соединение) еще не закрылось (трафик после 300 секунд будет уже считаться отдельным потоком). Самое важное здесь — это ссылка на ранее созданный exporter.

Далее просто берем и вешаем этот самый монитор на заранее оговоренный интерфейс Gig0/1:

interface GigabitEthernet0/1
 description Link to ISP 1
 ip flow monitor OUTSIDE_IN input //Смотрим на трафик, входящий в интерфейс (т.е. если в рамках соединения было передано 500 кБайт а получено 4500 кБайт, то будут учтены только полученные 4500).

Все. С этого момента NetFlow на интерфейсе активирован и работает. Кроме того, статистика вовсю отправляется на некий адрес 10.200.115.133, где ее кто-то должен слушать, но пока этого не делает. Прежде чем установим настроим нечто, что будет собирать прилетающую статистику, посмотрим что видно на самом роутере:

BorderRouter#sh flow monitor OUTSIDE_IN cache format record
Cache type:                               Normal
Cache size:                                 4096
Current entries:                             878
High Watermark:                       4294967295

Flows added:                           254391855
Flows aged:                            254390917
— Active timeout      (   300 secs)  219181486
— Inactive timeout    (    15 secs)   35177601
— Event aged                                 0
— Watermark aged                         22490
— Emergency aged                          9340

IPV4 SOURCE ADDRESS:       93.153.132.236
IPV4 DESTINATION ADDRESS:  91.231.141.8
TRNS SOURCE PORT:          53455
TRNS DESTINATION PORT:     1195
INTERFACE INPUT:           Gi0/1
FLOW SAMPLER ID:           0
IP TOS:                    0x00
IP PROTOCOL:               6
ip source as:              8359
ip destination as:         0
ipv4 next hop address:     91.231.141.244
ipv4 source mask:          /0
ipv4 destination mask:     /25
tcp flags:                 0x18
interface output:          Gi0/0
counter bytes:             165070
counter packets:           1498
timestamp first:           17:18:21.637
timestamp last:            17:22:48.685

IPV4 SOURCE ADDRESS:       93.153.192.254
IPV4 DESTINATION ADDRESS:  91.231.141.244
TRNS SOURCE PORT:          55965
TRNS DESTINATION PORT:     4500
INTERFACE INPUT:           Gi0/1
FLOW SAMPLER ID:           0
IP TOS:                    0x00
IP PROTOCOL:               17
ip source as:              8359
ip destination as:         0
ipv4 next hop address:     91.231.141.244
ipv4 source mask:          /0
ipv4 destination mask:     /28
tcp flags:                 0x00
interface output:          Gi0/0
counter bytes:             32463
counter packets:           190
timestamp first:           17:18:24.098
timestamp last:            17:22:50.458

…………………………………………………

………………………………………………….

и так далее.

Т.е. тут уже видно записи, которые еще не отправлены и статистика по которым собирается в данный момент. По строке   Current entries   видно, что таких записей сейчас 878 (тут показаны первые две). Посмотрим вторую. Видно, что между хостами  93.153.192.254 и 91.231.141.244 передается IPSec-траффик (IP PROTOCOL:17 — это UDP, TRNS DESTINATION PORT: 4500 — это Nat-T). На данный момент было передано 32463 байт (counter bytes) или 190 пакетов (counter packets). Т.е. понятно что NetFlow работает и все прекрасно считается.

Убедимся еще что работает и сам Exporter, ответственный за то, чтобы статистика отсылалась наружу:

ir4#sh flow exporter EXPORTER_TO_MONITOR statistics
Flow Exporter EXPORTER_TO_MONITOR:
Packet send statistics (last cleared 19w2d ago):
Successfully sent:         11043916              (14061156222 bytes)
Adjacency failure:         10                    (8038 bytes)
No destination address:    3                     (2859 bytes)

Client send statistics:
Client: Flow Monitor OUTSIDE_IN
Records added:           254429471
— sent:                254429282
— failed to send:      177
Bytes added:             13484761963
— sent:                13484751946
— failed to send:      9381

И тут все Ок. Да, в моем случае NetFlow уже активирован достаточно давно, поэтом такаие цифры, но это не принципиально.

Теперь настроим ту самую станцию мониторинга (коллектор+анализатор). Для целей исследования возьмем триальную версию PRTG Network Monitor, которая даже после завершения триального периода позволит полноценно наблюдать за десятью сенсорами (сейчас нам достаточно одного сенсора). Устанавливаем все в режиме Next->Next->Finish, запускаем сервер, подключаемся к нему по http через любой удобный браузер. Далее нужно просто создать устройство (Devices/Add Device) и для этого устройства добавить сенсор (Sensors/Add Sensor), выбрать NetFlow v9, заполнить нужные поля. Сенсор в терминологии PRTG — это нечто, что собирает прилетающий на порт 9990 траффик. Понятно, что таких сенсоров может быть множество. Можно, например, добавить еще один сенсор, который будет слушать порт 9991 и роутер будет слать на него трафик с того же Gig0/1 интерфейса, но уже в исходящем направлении (OUTSIDE_OUT).

Итак, коллектор был настроен, прошло некоторое время. Посмотрим теперь, к примеру, что насобиралось за двухчасовой период с 15.05 по 17.05 27.02.2014. В самом общем виде имеем такую картину:

Видно, что средняя (Average) скорость входящего в Gig0/1 трафика за данный промежуток времени составила 1979 кбит/с, всего (Total) было принято 1,7 ГБайт. Львиная доля  трафика — это http (на графике розовым), было немного RDP или его аналогов, совсем чуть-чуть smtp, ftp, и т.д.

Можно также посмотреть в виде таблиц и графиков какие именно IP с какими типами трафика работают и в каком количестве, в тот или иной промежуток времени и т.д., взять один конкретный IP и понаблюдать за тем, какую часть входящей полосы пропускания он занимал в течение недели и что это был за трафик, etc. Здесь я скриншоты подобных с подобными сведениями из соображений конфиденциальности приводить не буду.

Нужно отметить, что это не реклама PRTG и что существует множество бесплатных opensource продуктов, прекрасно реализующих функции NetFlow коллекторов (например nfsen), которые могут рабоать в промышленных масштабах. PRTG здесь приводится исключительно потому, что новичок может установить и настроить его за 5 минут и получить видимый результат, поэкспериментировать.

В современных устройствах Cisco реализована технология т.н. Flexible NetFlow, основное отличие которой от классических (v5, v9) версии в том, что набор ключевых полей, на основе которых собирается статистика не фиксирован и его можно задавать самостоятельно, равно как и самостоятельно определить какие данные будут считаться (помимо просто числа байт/пакетов). Но, дабы не перегружать статью, более подробно о Flexible NetFlow в следующий раз.