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

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

20.9.7 Сообщение get-bulk версии 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.

20.9.8 Сообщение trap в версии 2

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

Идентификатор объекта	Значение
…	…
…	…

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

20.9.9 Сообщение inform версии 2

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

20.9.10 Другие усовершенствования в версии 2

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

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

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

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

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

20.10 Документы MIB

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

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

20.10.1 Управляемые объекты

До сих пор мы использовали неформальный термин "переменная 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 задан как "чтение/запись", а диспетчер может читать или изменять значения переменных.