KnigaRead.com/
KnigaRead.com » Компьютеры и Интернет » Программное обеспечение » Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

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

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн Сидни Фейт, "TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)" бесплатно, без регистрации.
Перейти на страницу:

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

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

20.10.2 Первая абстрактная синтаксическая нотация (ASN.1)

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

Станция управления анализирует переменные MIB, компилируя определения MIB в записи ASN.1. Хорошие станции управления позволяют компилировать столько MIB, сколько нужно.

После компиляции станция управления готова посылать и получить сообщения SNMP, содержащие любую из скомпилированных переменных. Хорошие станции могут также выводить описания переменных. На рис. 20.13 показан вывод в HP Open View условия DESCRIPTION описания sysDescr.

Рис. 20.13. Вывод описаний переменных на экране диспетчера SNMP

20.10.3 Типы данных MIB

Причиной широкого распространения SNMP стало то, что проектировщики придерживались правила "Будь проще!"

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

■ Только небольшое число типов данных (например, целые числа или строки октетов) используется выражения значений всех переменных MIB.

Фактически основные типы данных — это INTEGER (целое), OCTET STRING (строка октетов) и OBJECT IDENTIFIER (идентификатор объекта).

20.10.4 Целые числа

Целые числа используются в двух случаях:

■ Для ответа на вопрос "сколько?"

■ Для перечисления списка вариантов, например 1 = включено, 2 = выключено, 3 = тестирование.

Ниже приведено определение, иллюстрирующее использование различных типов данных. Заметьте, что в первом определении формулировка SYNTAX ограничивает амплитуду значений.

tcpConnLocalPort OBJECT-TYPE

 SYNTAX INTEGER (0..65535)

 ACCESS read-only

 STATUS mandatory

 DESCRIPTION

  "Номер локального порта для данного

  соединения TCP."

 :: = { tcpConnEntry 3 }


ifAdminStatus OBJECT-TYPE

 SYNTAX INTEGER {

  up (1), - готов к пересылке пакета

  down (2),

  testing (3) - режим тестирования

 }


 ACCESS read-write

 STATUS mandatory

 DESCRIPTION

  "Требуемое состояние интерфейса. Тестирование (3) указывает

   на отмену пересылки пакетов."

 ::= { ifEntry 7 }

20.10.5 Счетчики

Счетчик — это положительное целое число, которое увеличивается до максимального значения и затем сбрасывается в ноль. Известно, что 32-разрядный счетчик может увеличиваться до 2³²-1 (4 294 967 295) и затем сбрасывается в 0. В версии 2 добавлен 64-разрядный счетчик, который может увеличиваться до 18 446 744 073 709 551 615.

Значение счетчика само по себе не используется. Регистрируется текущее значение счетчика, а затем сравнивается с его предыдущим значением. Смысл имеет разность этих значений. Пример переменной со счетчиком:

ifInOctets OBJECT-TYPE

 SYNTAX Counter

 ACCESS read-only

 STATUS mandatory

 DESCRIPTION

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*