Экспорт информации об IP-потоке

Экспорт информации о потоке интернет-протокола (IPFIX) — это протокол IETF , а также название рабочей группы IETF, определяющей этот протокол. Он был создан на основе необходимости в общем, универсальном стандарте экспорта информации о потоках Интернет-протокола от маршрутизаторов , зондов и других устройств, которые используются посредническими системами, системами учета/биллинга и системами управления сетью для облегчения таких услуг, как измерение, учет и биллинг. Стандарт IPFIX определяет, как информация IP-потока должна форматироваться и передаваться от экспортера к сборщику. ^[1] Ранее многие операторы сетей передачи данных полагались на компании Cisco Systems собственную технологию NetFlow для экспорта информации о потоках трафика.

Требования стандартов IPFIX были изложены в исходном документе RFC 3917. Cisco NetFlow версии 9 легла в основу IPFIX. Основные спецификации IPFIX документированы в RFC 7011–RFC 7015 и RFC 5103.

Архитектура

На следующем рисунке показана типичная архитектура информационного потока в архитектуре IPFIX:

                       Exporter      IPFIX         Collector
                          O--------------------------->O
                          |
                          | Observation
                          | Domain
                          |
       Metering #1        | Metering #2
         O----------------O----------------O Metering #3
         |                |                |
         | Observation    | Observation    | Observation
         | Point #1       | Point #2       | Point #3
         v                |                |
---- IP Traffic --->      |                |
                          v                |
--------------- More IP Traffic --->       |
                                           v
---------------------------------- More IP Traffic --->

Пул Metering Processes собирает пакеты данных в одной или нескольких точках наблюдения , при необходимости фильтрует их и агрегирует информацию об этих пакетах. Затем экспортер и собирает каждую из точек наблюдения в домен наблюдения отправляет эту информацию через протокол IPFIX коллектору . Экспортеры и сборщики находятся в отношениях «многие ко многим» : один экспортер может отправлять данные многим сборщикам, а один сборщик может получать данные от многих экспортеров. ^[2]

Протокол

Подобно протоколу NetFlow, IPFIX рассматривает поток как любое количество пакетов, наблюдаемых в определенном временном интервале и имеющих ряд свойств, например « один и тот же источник, тот же пункт назначения, тот же протокол ». Используя IPFIX, такие устройства, как маршрутизаторы, могут информировать центральную станцию мониторинга о своем взгляде на потенциально более крупную сеть.

IPFIX — это push-протокол , т. е. каждый отправитель будет периодически отправлять сообщения IPFIX настроенным получателям без какого-либо взаимодействия со стороны получателя.

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

IPFIX предпочитает протокол передачи управления потоком (SCTP) в качестве протокола транспортного уровня , но также позволяет использовать протокол управления передачей (TCP) или протокол пользовательских дейтаграмм (UDP) .

Пример

Простой набор информации, отправленный через IPFIX, может выглядеть так:

Source         Destination    Packets
------------------------------------------
192.168.0.201  192.168.0.1    235
192.168.0.202  192.168.0.1    42

Этот набор информации будет отправлен в следующем сообщении IPFIX:

Биты 0..15	Биты 16..31
Версия = 0x000a	Длина сообщения = 64 байта.
Временная метка экспорта = 31 декабря 2005 г., 23:59:60.
Порядковый номер = 0
Идентификатор домена наблюдения = 12345678
Установить идентификатор = 2 (шаблон)	Установить длину = 20 байт.
Идентификатор шаблона = 256	Количество полей = 3
Тип = исходныйIPv4Адрес.	Длина поля = 4 байта
Тип = адрес назначенияIPv4	Длина поля = 4 байта
Тип = packageDeltaCount	Длина поля = 4 байта
Идентификатор набора = 256 (Набор данных используя шаблон 256)	Установить длину = 28 байт.
Запись 1, Поле 1 = 192.168.0.201
Запись 1, Поле 2 = 192.168.0.1
Запись 1, поле 3 = 235 пакетов.
Запись 2, Поле 1 = 192.168.0.202
Запись 2, Поле 2 = 192.168.0.1
Запись 2, поле 3 = 42 пакета

Как можно видеть, сообщение содержит заголовок IPFIX и два набора IPFIX: один набор шаблонов, который представляет построение используемого набора данных, а также один набор данных, который содержит фактические данные. Когда IPFIX отправляется по протоколу, который сохраняет состояние сеанса (TCP или SCTP), набор шаблонов не требуется повторно передавать, поскольку он буферизуется в коллекторах. Поскольку набор шаблонов может меняться со временем, его необходимо передать повторно, если установлено новое состояние сеанса или если IPFIX отправляется по UDP, который является протоколом без сеансов.

См. также

Ссылки

^ Хофстед, Рик; Селеда, Павел; Траммелл, Брайан; Драго, Идилио; Садре, Рамин; Сперотто, Анна; Прас, Айко (2014). «Объяснение мониторинга потока: от захвата пакетов до анализа данных с помощью NetFlow и IPFIX» . Опросы и учебные пособия IEEE по коммуникациям . 16 (4): 2037–2064. дои : 10.1109/COMST.2014.2321898 . S2CID 14042725 .
^ Журнал коммуникаций IEEE, [1] ^{[ мертвая ссылка ]}

Внешние ссылки

[Flow_Monitoring_Tutorial-1] Хофстед, Рик; Селеда, Павел; Траммелл, Брайан; Драго, Идилио; Садре, Рамин; Сперотто, Анна; Прас, Айко (2014). «Объяснение мониторинга потока: от захвата пакетов до анализа данных с помощью NetFlow и IPFIX» . Опросы и учебные пособия IEEE по коммуникациям . 16 (4): 2037–2064. дои : 10.1109/COMST.2014.2321898 . S2CID 14042725 .

[2] Журнал коммуникаций IEEE, [1] ^{[ мертвая ссылка ]}

[1]

[2]