Администрирование_в_информационных_системах_Беленькая_М_Н_

Рис. 12.3. Часть дерева имен ISO, включающая группы объектов MIB-I

—Set-Request — команда используется менеджером для изменения значения какого-либо объекта; с помощью команды Set происходит собственно управление устройством — отключение порта, приписывание порта определенной VLAN и т. п.;

—Trap(s) — сообщения (ловушки), которые используются агентом (управляемое устройство) для сообщения менеджеру о возникновении особой ситуации;

—Inform-Request — используется менеджером, чтобы отослать сигнал другому менеджеру и запросить ответ.

Версия SNMP v2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько значений переменных за один запрос.

Четыре из пяти SNMP-сообщений реализуются простой последовательностью запрос-ответ (менеджер отправляет запрос, а агент возвращает ответ). Сообщения SNMP используют протокол UDP [9]. Это означает, что запрос от менеджера может не дойти до агента, а ответ от агента может не дойти до менеджера. В этом случае менеджер может подождать и осуществить повторную передачу.

На рисунке 12.4 менеджер отправляет три запроса на порт UDP 161. Агент отправляет сообщения (Trap) на порт UDP 162. Так как используются два разных порта, одна система может выступать в роли менеджера и агента одновременно.

Сообщения SNMP в отличие от сообщений многих других коммуникационных протоколов не имеют заголовков с фик-

Рис. 12.4. Типы сообщений протокола SNMP

сированными полями. В соответствии с нотацией ASN.1 сообщение SNMP состоит из произвольного числа полей, и каждое поле предваряется описанием его типа и размера.

Любое сообщение SNMP состоит из трех основных частей: версия протокола (version), сообщество (community), область данных.

Сообщество (community) — это строка символов, в которой содержится пароль в открытом виде. Пароль используется при общении между менеджером и агентом. Обычное значение — строка public.

Область данных — это часть сообщения SNMP, в которой содержатся команды протокола, имена объектов и их значения. Область данных делится на блоки данных протокола (Protocol Data Unit, PDU).

Общий формат сообщения SNMP в нотации ASN.1 выглядит следующим образом:

SNMP-Message ::= SEQUENCE {

version INTEGER { version-1 (0)

}, community

OCTET STRING, SNMP-PDUs

ANY

}

Область данных может содержать пять различных типов пакетов PDU, соответствующих пяти командам протокола SNMP:

SNMP-PDUs ::= CHOICE {

get-request GetRequest-PDU,

get-next-request GetNextRequest-PDU,

get-response GetResponse-PDU,

set-request SetRequest-PDU,

trap

Trap-PDU,

}

Для каждого типа PDU имеется определение его формата. Например, формат блока GetRequest-PDU описан следующим образом:

GetRequest-PDU ::= IMPLICIT SEQUENCE {

request-id Request ID,

error-status ErrorStatus,

error-index ErrorIndex,

variable-bindings VarBindList

}

Поле request-id содержит целое число и используется для установления соответствия между ответами и запросами. Поле error-status содержит целое число, которое возвращается агентам и указывает на ошибку. В табл. 12.1 показаны значения, имена и описания ошибок. Индекс ошибки (error index) представляет собой целое число (смещение), указывающее на то, в какой переменной произошла ошибка. VarBindList — это список числовых имен объектов, значениями которых интересуется менеджер. В нотации ASN.1 этот список состоит из пар «имя — значение».

Для сообщения Trap формат SNMP-сообщения другой и описан следующим образом:

Trap-PDU ::=

IMPLICIT SEQUENCE { enterprise

OBJECT IDENTIFIER, agent-addr

NetworkAddress, generic-trap

INTEGER { coldStart(0), warmStart(1), linkDown(2), linkUp(3),

authenticationFailure(4),

egpNeighborLoss(5), enterpriseSpecific(6)

}, specific-trap

INTEGER, time-stamp

TimeTicks, variable-bindings VarBindList

}

Поле enterprise — идентификатор производителя оборудования; agent-addr — адрес агента, от которого пришло сообщение; generic-trap — тип ловушки (таблица 12.2).

12.1.3. Протокол RMON

Протокол RMON (Remote Monitoring — удаленное наблюдение) — это расширение протокола SNMP [62]. Обычно в сети одновременно используются несколько сетевых протоколов. В этом случае при возникновении некоторой проблемы администратор системы использует специальные средства — протокольные анализаторы. Это портативные аппаратные средства, которые администратор системы перемещает по сети, используя для регистрации трафика, записи истории событий, составления графиков и диаграмм сетевой загрузки каналов и устройств. Уже указывалось, что такие устройства называют «пробами» (probes) и используют для решения проблем коммуникационного программного обеспечения. Так как в настоящее время все сетевые коммуникационные устройства

являются управляемыми, то целесообразно возложить на них обработку информации о сетевом трафике или утилизации устройств. В связи с этим появляется спецификация удаленного мониторинга, т. е. протокол RMON. Он определяет стандартные функции мониторинга и интерфейсы взаимодействия между SNMP-управляемыми менеджерами, удаленными средствами диагностики — пробами или удаленными агентами управления, осуществляющими эти функции в составе сетевых продуктов. В протоколах RMON и SNMP используются БД MIB. Но RMON обеспечивает поддержку расширенного набора объектов и атрибутов, позволяющих собирать больше информации, чем SNMP.

Спецификация RMON обеспечивает удаленное взаимодействие с базой MIB. База RMON MIB содержит агрегированную информацию об устройстве, не требующую передачи по сети больших объемов информации. Объекты RMON MIB включают дополнительные счетчики ошибок в пакетах, более гибкие средства анализа и статистики, более мощные средства фильтрации для захвата и анализа отдельных пакетов, а также более сложные условия установления сигналов предупреждения. Агенты RMON MIB более интеллектуальны по сравнению с агентами MIB-I или MIB-II и выполняют значительную часть работы по обработке информации об устройстве, которую раньше выполняли менеджеры. Эти агенты в виде специальных адаптеров могут располагаться внутри различных коммуникационных устройств, а также быть выполнены в виде отдельных программных модулей, работающих под управлением ОС персональных компьютеров и ноутбуков. Согласно протоколу RMON каждый пакет в сети рассматривается и запоминается (перехватывается), а информация об его характеристиках классифицируется и учитывается по

10категориям.

Объекту RMON присвоен номер 16 в наборе объектов MIB, а

сам объект RMON объединяет 10 групп следующих объектов:

—Statistics — текущие накопленные статистические данные о характеристиках пакетов, количестве коллизий и т. п.;

—History — статистические данные, сохраняемые через определенные промежутки времени для последующего анализа тенденций их изменений;

—Alarms — пороговые значения статистических показателей, при превышении которых агент RMON посылает сообщение менеджеру;

—Hosts — данные о хостах сети, в том числе и об их МАСадресах;

—HostTopN — таблица наиболее загруженных хостов в сети;

—Traffic Matrix — статистика интенсивности трафика между каждой парой хостов сети, упорядоченная в виде матрицы;

—Filter — условия фильтрации пакетов;

—Packet Capture — условия захвата пакетов;

—Event — условия регистрации и генерации событий. Данные группы пронумерованы в указанном порядке. На-

пример, группа Hosts имеет числовое имя 1.3.6.1.2.1.16.4. Десятую группу составляют специальные объекты протокола Token Ring. Всего стандарт RMON MIB определяет около 200 объектов в 10 группах, которые зафиксированы в двух документах — RFC 1271 для сетей Ethernet и RFC 1513 для сетей Token Ring.

Так как RMON используется в гетерогенных средах, то он не зависит от протокола сетевого уровня (в отличие от стандартов MIB-I и MIB-II, ориентированных на протоколы TCP/IP).

Рассмотрим для примера более подробно группу Statistics, которая определяет, какую информацию о пакетах Ethernet может предоставить агент RMON. Приведем пример ряда объектов группы Statistics:

—etherStatsDropEvents — общее число событий, при которых пакеты были проигнорированы агентом из-за недостатка его ресурсов (сами пакеты не обязательно были потеряны интерфейсом);

—etherStatsOctets — общее число принятых октетов (байт), включая ошибочные пакеты (исключая преамбулу кадров);

—etherStatsPkts — общее число полученных пакетов (с учетом ошибочных пакетов);

—etherStatsBroadcastPkts — общее число безошибочных пакетов, которые были посланы по широковещательному адресу (broadcast);

—etherStatsMulticastPkts — общее число полученных безошибочных многоадресных пакетов (multicast);

—etherStatsCRCAlignErrors — общее число полученных пакетов, которые имели длину (исключая преамбулу) между 64 и 1518 Байт, не содержали целое число байт (alignment error) или имели неверную контрольную сумму (FCS error);

—etherStatsUndersizePkts — общее число полученных пакетов, которые имели длину меньше 64 байт, но были правильно сформированы;

—etherStatsOversizePkts — общее число полученных пакетов, которые имели длину больше 1518 байт, но были правильно сформированы;

—etherStatsFragments — общее число полученных пакетов, которые не состояли из целого числа байт, имели неверную контрольную сумму и имели к тому же длину меньше 64 байт;

—etherStatsJabbers — общее число полученных пакетов, которые не состояли из целого числа байт, имели неверную контрольную сумму и имели к тому же длину больше 1518 байт;

—etherStatsCollisions — оценка числа коллизий на данном сегменте Ethernet;

—etherStatsPkts64Octets — общее число полученных пакетов, включая ошибочные пакеты, размером 64 байт;

—etherStatsPkts65to127Octets — общее количество полученных пакетов, включая ошибочные пакеты, размером от 65 до 127 байт;

—etherStatsPkts128to255Octets — общее число полученных пакетов, включая ошибочные пакеты, размером от 128 до 255 байт;

—etherStatsPkts256to511Octets — общее число полученных пакетов, включая ошибочные пакеты, размером от 256 до 511 байт;

—etherStatsPkts512to1023Octets — общее число полученных пакетов, включая ошибочные пакеты, размером от 512 до 1023 байт;

—etherStatsPkts1024to1518Octets — общее число полученных пакетов, включая ошибочные пакеты, размером от 1024 до 1518 байт.

Таким образом, с помощью агента RMON, встроенного в коммуникационное устройство, можно провести детальный

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

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

вгруппе Filter. После этого можно провести более детальный анализ, изучив захваченные кадры из объектов группы Packet Capture.

12.1.4. Протокол NetFlow

Изначально протокол NetFlow был создан и претворен в жизнь компанией Cisco Systems. Сейчас он является протоколом IETF и имеет еще одно название — IPFIX (Internet Protocol Flow Information eXport-экспорт информации потока интернетпротокола). Основанный на реализации NetFlow версии 9 (RFC3954 — Cisco Systems NetFlow Services Export — Version 9), IPFIX должен стать промышленным стандартом в ближайшем будущем (RFC 3917. Requirements for IP Flow Information Expor (IPFIX)). Поставщики коммуникационных средств, такие как Nortel Networks, Juniper Networks и другие, уже реализуют поддержку IPFIX в своем оборудовании.

Протокол оперирует понятием «поток». Поток определяется как последовательность пакетов между источником и пунктом назначения, которые идентифицируются набором атрибутов.

Поток идентифицируется следующими семью атрибутами:

—IP-адрес источника;

—IP-адрес получателя;

—порт источника;

—порт получателя;

—тип протокола 3-го уровня;

—байт ToS;

—входящий логический интерфейс.

Данные семи полей определяют уникальный поток. Информация передается в базу данных NetFlow, называемую кэш NetFlow.

Этот поток информации является чрезвычайно полезным для анализа состояния сети. Он хранит следующую информацию:

—адрес источника, который позволяет понять, кто является источником трафика;

—адрес назначения, который позволяет определить, кто является получателем данного потока трафика;

—порты, определяют применение трафика;

—класс обслуживания, указывающий на приоритет трафика;

—объем трафика.

Дополнительная информация, содержащаяся в потоке:

—временные данные потока, позволяющие проводить расчеты числа пакетов (байт) в секунду;

—следующий хоп, включая IP-адреса протокола маршрутизации автономных систем BGP;

—маска подсети источника и назначения для вычисления префиксов;

—флаги протокола TCP.

NetFlow позволяет устройствам передавать данные о трафике, проходящем через них, на любой хост в сети, где эти данные могут накапливаться, сохраняться в определенном виде и соответственно отображаться. Таким образом, имеется три типа программных продуктов, устанавливаемых на оборудовании под управлением ОС: сенсор, коллектор, визуализатор (рис. 12.5).

Сенсоры устанавливаются на всех маршрутизаторах (routers), через которые проходит исследуемый трафик сети, в виде специального резидентного программного обеспечения. Но они могут быть и встроены в операционную систему, что является предпочтительным. Сенсоры собирают информацию о потоках трафика (flows) и отправляют ее по протоколам UDP или TCP на централизованное место сбора — коллектор. Коллектор может быть установлен как на обычную рабочую станцию, так и на специально выделенный сервер под управлением операционных систем семейства Windows и Unix подобных ОС. Коллектор сохраняет данные в базе в специальном netflow-формате. Далее эти данные могут быть прочитаны и представлены в читаемом виде специальными утилитами — обработчиками-визуализаторами, сохранены в реляционной базе данных, визуализированы в виде графиков и отчетов на WEB-странице и т. п.