Структура управляющей информации

Структура управляющей информации (Structure of Management Information, SMI) определяет допустимые в базе управляющей информации типы данных и способы их представления. Кроме того, она определяет иерархическую структуру имен, чтобы управляемые объекты имели уникальные однозначные имена. SMI представляет своего рода надподмножество ASN.1 — она использует часть типов данных этого стандарта и вводит несколько своих типов данных. АSN — абстрактное описание синтаксиса — представляет собой стандартный язык описания объектов, принятый в OSI. Как и многие другие протоколы OSI, он сложен, громоздок и неэффективен.

Рисунок 1.2 - структура базы управляющей информации. Как и многие другие иерархические пространства имен, MIB начинается с безымянного корневого узла. В этом дереве узел MIB-2 уникальным образом идентифицируется с помощью идентификатора объекта 1.3.6.1.2.1.

 

Для того чтобы агенты и менеджеры могли управлять объектами в сети со множеством устройств и протоколов разных поставщиков, объекты должны быть описаны, а также стандартным образом закодированы для передачи по сети. Термин "объекты" относится к переменным, описывающим состояние устройства. Он несколько сбивает с толку, так как это далеко не те же объекты, что и в объектно-ориентированных системах, в частности они имеют состояния, но не имеют методов (помимо чтения и записи значений объектов). Однако этот термин используется в официальных стандартах.

Объекты базы управляющей информации обычно имеют шесть атрибутов. Как правило, это имя, например ifInErrors или tcpAttemptFails; идентификатор объекта в точечно-десятичной нотации вида 1.3.6.1.2.1.2.2.1.1.4; поле синтаксиса для выбора одного из нескольких возможных типов данных — Integer, IPAddress или Counter; поле метода доступа — "недоступен", "только чтение", "чтение—запись" и "только запись"; поле статуса — "обязательный", "необязательный" или "вышедший из употребления", а также текстовое описание объекта.

SMI задает правила описания объектов. Все эти абстрактные правила и зарезервированные слова позволяют получить машиночитаемые спецификации, понятные человеку. Объекты MIB имеют статичную природу. Они компилируются из текстов файлов с описанием в двоичную форму, которую агенты и управляющие процессы и загружают. Используя SMI, производитель может написать собственное определение объекта управления (например, PacketsContainingWordSpam), пропустить текст через стандартный компилятор MIB и создать таким образом исполнимый код. Этот код можно затем установить на агенты с надлежащим аппаратным и программным обеспечением для подсчета количества содержащих слово spam пакетов.

 

База управляющей информации

Множество объектов, которыми управляет SNMP, составляет базу управляющей информации (Management Information Base, MIB). Для удобства эти объекты объединены в десять групп, каждая из которых представляет собой дочерний для mib-2 узел в дереве имен объектов (см. Рисунок 1). Изначально база управляющей информации содержала восемь групп. Спецификация MIB-2 добавила еще две группы и исключила одну прежнюю. Производители могут определять собственные объекты. Информация по всем десяти группам сведена в Таблицу 1.

Группа	Количество объектов	Описание
System	7	Имя, местонахождение и описание оборудования
Interfaces	23	Сетевые интерфейсы и трафик через них
AT	3	Трансляция адресов (вышла из употребления)
IP	42	Статистика по IP-пакетам
ICMP	26	Статистика по полученным сообщениям ICMP
TCP	19	Алгоритмы, параметры и статистика TCP
UDP	6	Статистика трафика UDP
EGP	20	Статистика трафика для Exterior Gateway Protocol
Transmission	0	Зарезервирована для специфических MIB
SNMP	29	Статистика о трафике SNMP

Таблица 1- Группы объектов в Internet MIB-2

 

· Группа System позволяет определить, как называется устройство, кем оно произведено, какое программное и аппаратное обеспечение оно содержит, где находится и какие функции выполняет. Кроме того, она предоставляет информацию о том, когда последний раз производилась загрузка и каковы имя и координаты ответственного лица. Зная эту информацию, администратор из центрального офиса может, например, без труда установить конфигурацию устройства в удаленном офисе.

· Группа Interface служит для сбора статистики о работе сетевых адаптеров, в том числе о количестве переданных и полученных пакетов и байтов, о числе широковещательных пакетов и текущем размере выходной очереди.

· Присутствовавшая в MIB-1 группа АТ предоставляла данные о соответствии адресов (например, MAC- и IP-адресов). В SNMPv2 эта информация была перемещена в базы управляющей информации для конкретных протоколов.

· Группа IP описывает трафик через узел. Она изобилует счетчиками для подсчета числа отброшенных по каждой из причин кадров (например, кадр был отброшен, потому что его адресат неизвестен). Кроме того, она позволяет получить данные о фрагментации и сборке дейтаграмм. Как нетрудно понять, эта группа особенно полезна для получения статистики о работе маршрутизатора.

· Группа ICMP собирает данные о сообщениях об ошибках в IP. Она имеет счетчики для подсчета количества зафиксированных сообщений каждого возможного типа.

· Группа TCP служит для учета числа открытых соединений, количества переданных и полученных сегментов и различного рода ошибок.

· Группа UDP позволяет фиксировать число переданных и полученных дейтаграмм, а также количество дейтаграмм, потерянных из-за того, что порт неизвестен, или по другим причинам.

 

· Группа EGP используется маршрутизаторами, поддерживающими Exterior Gate-way Protocol. Она позволяет подсчитывать число полученных из внешней сети кадров, а также сколько из них было передано правильно, а сколько отброшено и т. п.

· Группа Transmission служит родительским узлом для специфичных баз управляющей информации. Например, сюда может быть помещена группа для сбора статистики об Ethernet. Цель включения пустой группы в MIB-2 состоит исключительно в резервировании идентификатора для подобных целей.

· Последняя группа — группа SNMP — предназначена для сбора статистики о функционировании самого протокола SNMP: сколько сообщений было послано, что это за сообщения и т.п.

 

Протокол SNMP

Собственно SNMP представляет собой протокол по типу запрос—ответ, которыми сетевые станции управления и агенты обмениваются между собой. Первая версия протокола SNMP предусматривает всего пять различных сообщений. Три из них может посылать менеджер агенту, а два других — агент менеджеру.

Если в сети ничего необычного не происходит, то SNMP используется менеджером для отправки агенту запроса с просьбой передать запрошенную информацию или с приказом изменить свое состояние указанным образом. Агент посылает в ответ требуемую информацию или подтверждает изменение своего состояния. Однако агент может передать сообщение об ошибке, например "нет такой переменной". В чрезвычайных же обстоятельствах, в частности при превышении заданного порога, агент отправляет менеджеру прерывание. Данные передаются с использованием синтаксиса ASN.1.

Менеджер агенту может послать следующие три сообщения: GetRequest, GetNextRequest и SetRequest. Первые два служат для запроса у агента значений конкретных переменных. Первое из них содержит имя переменной в явном виде. Второе запрашивает значение следующей переменной в алфавитном порядке. Третье позволяет менеджеру изменять значения переменных, если определение объекта это позволяет.

Агент может отправлять два различных сообщения: одно из них — GetResponse — служит для ответа (и подтверждения) на запрос от менеджера, а второе — Trap — посылается при обнаружении агентом предопределенного чрезвычайного события.

Протоколом SNMPv2 вводится еще два типа сообщений. GetBulkRequest позволяет запросить целый массив переменных, например таблицу, а InformRequest — одному менеджеру сообщить другому, какими переменными он управляет.

Все типы сообщений сведены в Таблице 2.

Сообщение	Описание
GetRequest	Запрос для получения значения одной или более переменных
GetNextRequest	Запрос следующей переменной
GetBulkRequest	Запрос большой таблицы
SetRequest	Изменение значения одной или более переменных
InformRequest	Сообщение менеджером другому менеджеру описания своей локальной MIB
Snmpv2Trap	Сообщение о прерывании от агента

Таблица 2 – типы запросов SNMPv2

 

Структура PDU

Рисунок 1.3 – структура PDU

· версия - содержит версию SNMP

· пароль (community) - содержит последовательность символов, описывающую принадлежность к группе (об этом ниже)

· тип PDU имеет цифровой идентификатор запроса (Get,GetNext,Set,Responde,Trap…)

· идентификатор запроса – это тот самый набор символов, который связывает в единое целое запрос\ответ.

· Статус ошибки– это число, характеризующее характер ошибки:

o Для запросов (Get,Set,GetNExt и др.) - 0

o Для ответов:

§ 0 (NoError) – Нет ошибок,

§ 1 (TooBig) - Объект не вмещается в одно Response сообщение,

§ 2 (NoSuchName) – не существующая переменная,

§ 3 (BadValue) – при попытке установить значение задано недопустимое значение или совершена синтаксическая ошибка,

§ 4 (ReadOnly) – при Set запросе была попытка изменить read-only переменную,

§ 5 (GenErr) – другие ошибки.

· Индекс ошибки – не нашел внятного описания (но смысл в том, что содержит некий индекс переменной, к которой относится ошибка

· Поле связанные переменные может содержать одну или более переменную (для запросов Get – это только имя переменных, для Set – имя и устанавливаемое значение, для Response – имя и запрошенное значение).

При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):

· Фирма – характеризующее производителя хоста

· Тип trapуведомления, может быть следующим:

o 0 (Coldstart) и 1 (Warmstart) – объект возвращен в начальное состояние (между ними имеется некая разница, но какая?..),

o 2 (Linkdown) – интерфейс опущен, при этом, поле переменной содержит интерфейс о котором идет речь,

o 3 (Linkup) – интерфейс поднялся, при этом, поле переменной содержит интерфейс о котором идет речь,

o 4 (Authenticationfailure) – менеджер прислал мессадж с неверной строкой community,

o 5 (EGPneighborloss) – затрудняюсь что либо сказать),

o 6 (Entrprisespecific) – данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.

· Специализированный тип Trap – описан выше

· Метка времени – содержит метку времени с момента события (непонятно, относительно чего эта метка…).

В новых версиях SNMP содержимое Trap PDU может незначительно меняться, но в целом, смысл тот же.