`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Мониторинг трафика в сетях с коммутацией пакетов

Статья опубликована в №37 (654) от 30 сентября

0 
 

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

В недалеком прошлом мониторинг трафика был относительно простой задачей. Как правило, компьютеры объединялись в сеть на основе шинной топологии, т. е. имели разделяемую среду передачи. Это позволяло подсоединить к сети единственное устройство, с помощью которого можно было следить за всем трафиком. Однако требования к повышению пропускной способности сети и развитие технологий коммутации пакетов, вызвавшее падение цен на коммутаторы и маршрутизаторы, обусловили быстрый переход от разделяемой среды передачи к высокосегментированным топологиям. Общий трафик уже нельзя было увидеть из одной точки. Для получения полной картины требовалось выполнять мониторинг каждого порта. Использование соединений типа «точка-точка» делало неудобным подключение приборов, да и понадобилось бы слишком большое их число для прослушивания всех портов, что превращалось в чересчур дорогостоящую задачу. Вдобавок сами коммутаторы и маршрутизаторы имели сложную архитектуру, и скорость обработки и передачи пакетов становилась важным фактором, определяющим производительность сети.

Единственный реальный метод решения поставленной задачи заключался в том, чтобы осуществлять мониторинг трафика непосредственно внутри сетевых устройств.

Имеется ряд подходов к мониторингу сетевого трафика, каждый из которых обладает своими достоинствами и недостатками.

RMON

Remote network MONitoring (RMON) был разработан группой IETF для мониторинга и анализа протоколов в локальных сетях. Спецификация RMON является расширением базы управляющей информации SNMP MIB (Management Information Base). RMON-устройства декодируют и анализируют каждый пакет в сети, создают таблицы результатов измерений, которые затем могут направляться для окончательной обработки приложениям, управляющим сетью. Данные и события, мониторинг которых осуществляется, определяются набором статистик и функций, представленных в MIB.

Имеются две версии RMON. В первой (RMON1) MIB содержит 10 групп параметров для базового мониторинга сетей на уровне МАС и ниже, которые можно найти в большинстве современных сетевых устройств. Приведем в качестве примера несколько из них. Это статистика ЛВС в режиме реального времени, как то: утилизация сети, коллизии, ошибки CRC, история выбранных статистик, диагностические сообщения при превышении статистик пороговых значений, специфические статистики для хостов, в частности количество полученных и/или отправленных пакетов, N наиболее активных соединений за указанный отрезок времени и т. п.

MIB для RMON2 является расширением базы первой версии и охватывает мониторинг пакетов на уровнях выше МАС. В нее включены такие параметры, как статистика трафика для каждого из протоколов, статистика трафика на уровне 3 (сетевом) для каждого хоста (пары отправитель-получатель), статистика трафика по протоколам для каждого хоста и ряд других.

Решения RMON включают два компонента: аппаратно-программный агент (probe) и клиент, обычно станция управления. Агенты сохраняют сетевую информацию в своих RMON MIB и, как правило, представляют собой ПО, встроенное в сетевые устройства, такие как маршрутизаторы и коммутаторы, хотя они могут быть и программами, установленными на ПК. Агенты видят только тот трафик, который проходит через них, и поэтому они должны устанавливаться в каждый сегмент локальной сети или WAN-соединение, нуждающееся в мониторинге. Клиенты связываются с агентами с помощью SNMP.

NetFlow

Для сбора информации об IP-трафике Cisco создала протокол NetFlow, который, не будучи стандартом, тем не менее является открытым. Протокол работает в сетевых устройствах, на которых установлена операционная система Cisco IOS. В 2003 г. NetFlow v.9 была выбрана для предложенного IETF стандарта под названием IP Flow Information Export (IPFIX). Вкратце принцип работы протокола может быть описан следующим образом.

В каждом IP-пакете, проходящем через маршрутизатор или коммутатор, исследуется набор его атрибутов, с помощью которых определяется, уникален он или подобен другим пакетам, т. е. является или нет элементом IP-потока. В типичном случае IP-поток базируется на пяти или семи атрибутах пакета. NetFlow использует IP-адреса источника и получателя, порты источника и получателя, тип протокола уровня 3 (сетевого), класс обслуживания (CoS) и входной интерфейс маршрутизатора или коммутатора. Все пакеты с одинаковыми атрибутами группируются в поток, и затем подсчитывается количество пакетов и байтов потока. Эта информация накапливается в базе данных, называемой NetFlow Cache.

Собранные данные чрезвычайно полезны для понимания поведения сети. Так, адрес источника позволяет узнать, кто генерирует трафик, а адрес получателя – кому он предназначен; порт характеризует приложение, утилизирующее трафик; класс обслуживания указывает приоритет трафика; интерфейс говорит, как трафик используется сетевым устройством, а количество пакетов и байтов определяет его объем.

Для доступа к этим данным существует два основных метода: интерфейс командной строки (CLI) и применение инструментов отчетности. При необходимости немедленно определить, что произошло в сети, можно воспользоваться CLI. Второй выбор предусматривает экспорт базы данных в сервер отчетов, который называется NetFlow Collector. Он собирает и анализирует экспортированные потоки и предоставляет отчеты, применяемые для анализа трафика и безопасности. В отличие от опроса, который выполняется протоколом SNMP, экспорт в коллектор производится периодически. В типичном случае NetFlow Cache постоянно заполняется информацией о потоках, ПО коммутаторов или маршрутизаторов просматривает кэш и ищет потоки, передача которых завершилась или истекло время их жизни, и данные о таких потоках экспортируются в коллектор. Рассмотрим несколько подробнее, как сетевое устройство определяет, какой поток экспортировать в коллектор NetFlow.

Поток готов для экспорта, когда он неактивен некоторое время (другими словами, в него не поступают новые пакеты), или если поток долгоживущий (например, загрузка файлов по FTP), но его продолжительность больше, чем предполагает обслуживание. Поток также экспортируется, если флаг TCP указывает, что он закончился (флаги FIN, RST). Период неактивности и обслуживания устанавливается с помощью соответствующих таймеров. В типичном случае нагрузка сети для экспорта содержимого NetFlow Cache составляет 1–5% коммутируемого трафика.

Пример сети с NetFlow приведен на рис. 1.

Мониторинг трафика в сетях с коммутацией пакетов
Рис. 1. Пример реализации NetFlow в сети

 

sFlow

Если NetFlow для получения данных о потоке обрабатывает каждый пакет, сохраняет его параметры в NetFlow Cache, а затем экспортирует их в NetFlow Collector, то протокол sFlow базируется на анализе статистической выборки пакетов.

Выборка пакетов для мониторинга сетевого трафика используется уже более 15 лет. Впервые этот метод продемонстрировала HP на выставке Telecom'91. Однако широкое распространение данная технология получила только в последние годы, что было вызвано появлением высокоскоростных сетей и переходом к коммутации пакетов. Рассмотрим суть метода оценки трафика по выборке пакетов на конкретном примере.

Пусть по сети передается 1 млн пакетов. Случайная выборка 25% трафика дает 2500 пакетов. Если 1000 из них представляет определенный класс трафика v, например голосовой трафик, то уместен вопрос об оценке количества пакетов этого класса в общем трафике. Он будет содержать по меньшей мере 1000 пакетов класса v, поскольку они попали в выборку. Максимально возможное же их число – 998 500, потому что в выборке имеются 1500 неголосовых пакетов. Вообще говоря, такие значения возможны, однако крайне маловероятны. Наиболее правдоподобным будет предположение, что часть голосовых пакетов в общем трафике близка к таковой в выборке, т. е. примерно 40%. Погрешность оценки вычисляется с помощью статистических методов.

Мониторинг трафика в сетях с коммутацией пакетов
Рис. 2. Локализация агента sFlow в сетевом устройстве

Программный модуль, реализующий функции агента sFlow, работает как часть управляющего ПО, располагающегося на сетевом устройстве (рис. 2). Когда выбирается пакет, его заголовок извлекается и помещается в дейтаграмму или детализированную карту передачи пакета по сети, которая включает заголовок, адреса и порты отправителя и получателя, статистику интерфейса и другую информацию, необходимую для анализа трафика на уровнях OSI от второго до седьмого. Сформированная дейтаграмма сразу же направляется по сети в sFlow Collector. Один коллектор может обрабатывать данные более чем от 20 тыс. портов (рис. 3).

Мониторинг трафика в сетях с коммутацией пакетов
Рис. 3. Агенты sFlow и коллектор

Выборка пакетов в типичном случае выполняется с помощью коммутирующих или маршрутизирующих заказных специализированных микросхем (ASIC) со скоростью, которую позволяют физические соединения. Записывается также состояние элементов коммутационных и маршрутных таблиц, связанных с каждым пакетом выборки.

Следует отметить, что sFlow, по сравнению с вышеописанными методами, потребляет минимальное количество ресурсов процессора, памяти и полосы пропускания, что является решающим фактором при выборе технологии мониторинга трафика в высокоскоростных сетях.

0 
 

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT