Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Как видим, структура сообщения достаточно сложна. В версии 2 она была проще.

Следующие свойства SNMP версии 1 были не слишком удачны:

■ Если одна из переменных в запросе get или get-next была некорректна, то отбрасывалось все сообщение.

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

■ Сообщения trap реализовывали простые функции, но имели сложную структуру.

Все эти проблемы были решены в версии 2. Теперь агент может помещать код ошибки в поле значения переменной, которая не может быть обработана. Появился новый запрос get-bulk, требующий от агента возврата максимально возможного объема информации. Сообщения trap стали иметь такой же простой формат, как и все другие сообщения.

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

Сообщение get-bulk ведет себя подобно get-next. Агент возвратит переменные, чьи идентификаторы объектов следуют за идентификаторами объектов, указанными в запросе. Сообщение get-bulk имеет параметры, указывающие:

■ Количество начальных автономных неповторяющихся (nonrepeater) запрошенных переменных

■ Количество требуемых повторений для оставшихся повторяющихся (repeater) переменных

Например, можно запросить две неповторяющиеся автономные переменные:

sysDescr

sysUpTime

и затем еще десять строк табличных переменных: ifIndex, ifDescr, ifTyре, ifMTU и ifSpeed. В этом случае:

■ В списке будет 7 переменных

■ 2 неповторяющиеся переменные

■ Максимальное число повторений будет равно 10

В ответе будет упаковано столько затребованной информации, сколько возможно. Приложение легко сможет послать еще один запрос get-bulk за данными, не поместившимися в сообщении ответа.

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

В версии 2 сообщение trap имеет тот же самый формат, что и ответ на него. Сообщение начинается стандартной информацией заголовка, далее следует список переменных:

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

В версии 2 реализована идея информационного сообщения, подтверждающего получение trap. Такие сообщения полезны при взаимодействии диспетчеров, когда отправителю нужно точно знать о получении сообщения в принимающем диспетчере. Для подтверждения приема информационного сообщения (inform) используется обычный ответ.

Насколько точно реализация модуля должна соответствовать определению MIB от разработчика для обеспечения требований совместимости? И как разработчик может объявить о несоответствии спецификации, которое, скорее всего, было необходимо из-за некоторых ограничений в возможностях оборудования?

Решить эти вопросы в версии 2 помогают следующие средства:

■ Описание совместимости (compliance statement), определяющее фактические минимальные требования для модуля

■ Описание возможностей (capability statement), предоставляемое разработчиком для пояснения реальных возможностей агента

Эти описания позволяют клиенту при выборе узнать о продукте немного больше, чем "мы поддерживаем SNMP".

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

В следующих разделах мы обсудим некоторые концепции, знание которых будет полезно при чтении документов MIB.

До сих пор мы использовали неформальный термин "переменная MIВ". Но стандарты MIB реально определяют управляемые объекты (managed objects). Переменная имеет название и значение, а определение управляемого объекта включает:

■ Имя — идентификатор объекта

■ Набор атрибутов, в частности:

■ Тип данных

■ Описание деталей реализации

■ Информацию о статусе

■ Набор операций, которые могут быть выполнены над объектом

Рассмотрим типичное определение MIB:

sysDescr OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255))

ACCESS read-only

STATUS mandatory

DESCRIPTION

"Текстовое описание элемента, которое должно содержать полное имя и

номер версии, типа аппаратного обеспечения системы, операционной

системы и сетевых средств. Подтверждается (mandatory), что вся

информация содержит только воспроизводимые символы ASCII."

:: = { system 1 }

Определение начинается с обозначения текстовой метки объекта — sysDescr — и заканчивается { system 1 }, что означает "поместить этот узел ниже узла system и присвоить ему номер 1". Такая запись позволяет построить полный идентификатор объекта, который будет выглядеть как:

1.3.6.1.2.1.1.1

Остальная часть определения состоит из ряда конструкций (clauses) — SYNTAX (синтаксис), ACCESS (доступ), STATUS (статус) и DESCRIPTION (описание).

В данном случае SYNTAX (datatype) — это выводимая строка, т.е. ряд символов не длиннее 255 знаков.

ACCESS определяет действие(я), которое может быть выполнено. В данном случае ACCESS задан как "чтение/запись", а диспетчер может читать или изменять значения переменных.

В ранних документах MIB условие STATUS могло иметь значения: mandatory (обязательно), optional (необязательно), obsolete (устарело) или deprecated (отменено). Однако значения mandatory и optional были бесполезны. Более новые MIB не включают переменных, значение которых столь мало, что нет смысла помечать их специальным значением. STATUS теперь может указать на current (текущее значение), deprecated (отменено) или obsolete (устарело).

Определения MIB написаны на стандартном языке первой абстрактной синтаксической нотации (Abstract Syntax Notation 1 — ASN.1), разработанном в ISO. ASN.1 похож на компьютерные языки. Существуют и основные правила кодирования (Basic Encoding Rules — BER), также от ISO, определяющие формат пересылки значений, определенных с помощью ASN.1.