Типы сообщений, используемых в протоколе SNMP

Протокол SNMP определяет всего пять типов протокольных сообщений PDU (Protocol Data Unit), которыми обмениваются менеджер и клиент (таблица 10).

Таблица 10

Команда SNMP	Тип PDU	Назначение
get_request		Получить значение указанной переменной или информацию о состоянии сетевого элемента
get_next_request		Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB)
set_request		Присвоить переменной соответствующее значения. Используется для описания действие, которое должно быть выполнено
get response		Отклик на get_request, get_next_request и set_request, Содержит также информацию о состоянии (коды ошибок и другие данные)
trap		Отклик сетевого объекта на событие или на изменение состояния

Первые три сообщения отправляются от менеджера к агенту, а последние два от агента к менеджеру. Схема запросов/откликов SNMP представлена на рисунке 10.

Рисунок 10 - Схема запросов/откликов SNMP

Так как четыре из пяти SNMP сообщений реализуются простой последовательностью запрос-отклик (менеджер отправляет запрос, а агент возвращает отклик), SNMP используют транспортный протокол UDP. это означает, что запрос от менеджера может не прибыть к агенту, а отклик от агента может не прибыть к менеджеру. в этом случае менеджер, возможно, отработает тайм-аут и осуществит повторную передачу. Менеджер отправляет эти три запроса на UDP порт 161. Агент отправляет запросы на обработку аварийных или иных событий (trap) на UDP порт 162. так как используются два разных порта, одна система может выступать в роли менеджера и агента одновременно.

Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы

Формат SNMP -сообщений, вкладываемых в UDP -дейтограммы, приведен на рисунке 11

Рисунок 11- Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы

Поле Версия содержит значение, равное номеру версии SNMP минус один. Поле Пароль (community - определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public. Для запросов get, get-next и set значение поля Идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике get, что позволяет связывать в пары запросы и отклики. Поле Фирма (enterprise) = sysObjectlD объекта. Поле Статус ошибки характеризуется целым числом, присланным объектом управления (табл. 11).

Таблица 11

Статус ошибки	Имя ошибки	Описание
	noError tooBig noSuchName	Все в порядке Объект не может уложить отклик в одно сообщение В операции указана неизвестная переменная
	badValue readOnly genErr	в команде set использована недопустимая величина или неправильный синтаксис менеджер попытался изменить константу Прочие ошибки

Пример заголовка SNMP -запроса представлен на рисунке (изображенные поля образуют единый массив):

Поле Флаг = 0х30 является признаком ASN.1 -заголовка. Коды Ln представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n — номер поля длины). Так, L1 - длина пакета-запроса от Т1 до конца пакета, a L3 — длина поля пароля. Субполя Tn — поля типа следующего за ними субполя запроса. Так, Т1 =2 означает, что поле характеризуется целым числом, а Т2 =4 указывает на то, что далее следует пароль (поле community, в приведенном примере Public). Цифры под рамками означают типовые значения субполей. Код ОхА является признаком GET -запроса, за ним следует поле кода команды PDU (=0...4). Блок субполей Идентификатора запроса служит для тех же целей, что и другие идентификаторы, — для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением Lиз. CO — статус ошибки (СО=0 - ошибки нет); ТМ — тип MIB -переменной (в приведенном примере Ох2В); ИО — индекс ошибки. Цифровой код MIB -переменной отображается последовательностью цифровых субполей, характеризующих переменную. Например, переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) соответствует последовательности кодов Ох2В 0х06 0х01 0х02 0х01 0х05 0х00.

12 Протокол общей управляющей информации CMIP

CMIP (Common Management Information Protocol –протокол общей управляющей информации).

Доступ к управляющей информации, хранящейся в управляемых объектах, обеспечивается с помощью элемента системы управления, называемого элементом услуг общей управляющей информации CMISE (Common Management Information Service Element). Служба CMISE построена в архитектуре распределённого приложения, где часть функций выполняет менеджер, а часть – агент. Взаимодействие между менеджером и агентом осуществляется по протоколу CMIP. Услуги, предоставляемые службой CMSIE, называются услугами CMIS (Common Management Information Services –общие услуги информации управления).

Протокол CMIP и услуги CMIS определены в стандартах X.710 и X.711 ITU-T.

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

CMIP основан на базе данных управления (Management Information Base, MIB), то есть на совокупности управляемых объектов. Эти объекты имеют атрибуты, обладают некоторым поведением, могут быть созданы и удалены и инициируют в прикладной программе специфические действия, которые запрашиваются менеджером.

Поведение объекта обусловлено ресурсом управления, который этот объект представляет. Например, функционирование терминального окончания соединительной линии или канала связи может зависеть от функционирования (поведения) других компонентов системы, например системы синхронизации или физической среды переноса сигнала электросвязи.

Протокол CMIP используется CMISE для сбора, обмена и изменения информации об управляемых объектах. Это позволяет осуществлять управление элементами всех уровней модели ВОС. CMIP – это протокол, у которого нет “интеллектуальных” программ-агентов, напротив, агенты CMIP на объектах управления более интеллектуальны, чем их аналоги в других стандартах сетевого управления.

CMIP формирует протокольные блоки данных (PDU) и осуществляет обмен PDU между одноуровневыми услугами CMISE, чтобы реализовать сервисы CMIS. CMIP используется для обеспечения услуг управления операциями и услуг передачи уведомлений CMISE (рисунок 12).

Услуги CMIS разделяются на две группы – услуги, инициируемые менеджером (запросы), и услуги, инициируемые агентом (уведомления).

Услуги, инициируемые менеджером, включают следующие операции:

-M-CREAT инструктирует агента о необходимости создать новый экземпляр объекта определённого класса или новый атрибут внутри экземпляра объекта;

-M-DELETE инструктирует агента о необходимости удаления некоторого экземпляра объекта определённого класса или атрибута внутри экземпляра объекта;

-M-GET инструктирует агента о возвращении значения некоторого атрибута определённого экземпляра объекта;

-M-SET инструктирует агента об изменении значения некоторого атрибута определённого экземпляра объекта;

-M-ACTION инструктирует агента о необходимости выполнения; определённого действия над одним или несколькими экземплярами объектов.

Агент инициирует только одну операцию: M-EVENT-REPORT –отправка уведомления менеджеру.

CMIP определяет функции управления сетью и предоставляет следующие виды услуг:

-управление конфигурацией – внешним очертанием, взаимным расположением компонентов сети;

-управление защитой данных;

-контроль безопасности данных;

-проведение учёта работы сети;

-управление качеством функционирования;

-ведение службы каталогов.

Рисунок 12 – Взаимосвязь протокольных блоков CMIS и CMIP

13 Язык абстрактной записи синтаксиса(Abstract Syntax Notation) ASN.1

Для управления сетями связи основным протоколом является так называемый «Простой протокол сетевого управления- Simple Network Management Protocol»- SNMP, основным стандартом кодирования информации в котором служит язык ASN.1.

ASN.1 (англ. Abstract Syntax Notation One) — в области телекоммуникаций и компьютерных сетей язык для описания абстрактного синтаксиса данных (ASN.1), используемый OSI. Стандарт записи, описывающий структуры данных для представления, кодирования, передачи и декодирования данных. Он обеспечивает набор формальных правил для описания структуры объектов, которые не зависят от конкретной машины. ASN.1 является ISO- и ITU-T-совместимым стандартом, первоначально был определён в 1984 году в рамках CCITT X.409:1984. Из-за широкого применения ASN.1 в 1988 году перешёл в свой собственный стандарт X.208. Начиная с 1995 года, существенно пересмотренный ASN.1 описывается стандартом X.680.

В России ASN.1 стандартизирован по ГОСТ Р ИСО/МЭК 8824-1-2001 и ГОСТ Р ИСО/МЭК 8825-93

Протокол сетевого управления SNMP использует следующие типы данных:

вещественный тип - REAL:

целый тип - INTEGER;

идентификатор объектов управляющей базы данных MIB - OBJECT IDENTIFIER;

все виды строк - STRING;

логический тип – BOOLEAN;

пустое множество – NULL;

упорядоченный набор из одного или более типов - SEQUENCE;

неупорядоченный набор из одного или более типов - SET.

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

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

Для возможности подобного описания содержащейся в закодированном блоке информации применяется определенная общая структура каждого блока. Каждый блок содержит минимум 3 обязательных части (в отдельных случаях остаются только первые два блока):

1. Часть идентификатора блока (до нескольких октетов);

2. Часть общей длины блока (до нескольких октетов);

3. Часть, содержащая собственно значение, которое переносит этот блок (до нескольких октетов).

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями: