Организация доступа MIB-переменных

⇐ ПредыдущаяСтр 2 из 2

Чтобы показать доступность различных переменных, мы используем как пример udp-группы. Имеются четыре простых переменных в группах и одна последовательность записей (таблица). Рисунок 15.13. показывает переменные и таблицу.

Рис. 15.13. udp-группа

Мы покажем, как иметь доступ к каждому объекту.

Простая переменная

Чтобы организовать доступ любой простой переменной, мы используем групповой id ( 1.3.6.1.2.1.7 ), сопровождаемый id переменной. Ниже показано, как организовать доступ к каждой переменной:

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

Таблицы

Чтобы идентифицировать таблицу, мы сначала используем id. Группа udp имеет только одну таблицу (с id 5), как это показано на рисунке 15.14.

Рис. 15.14. udp-переменные и таблицы

Для организации таблицы мы должны использовать следующие адреса:

Однако таблица в этом дереве не на уровне листа. Мы не можем иметь доступ к таблице, пока не определим вход (последовательность) в таблице (с id 1), как это показано ниже:

Этот вход также не имеет листов, и нам он недоступен. Нам нужно определить каждый объект входа. Это две переменные в листе дерева. Хотя мы можем обратиться к их образцам, мы должны определить, какой именно образец нам нужен. В любой момент таблица может иметь несколько значений для каждой пары местный адрес / местный порт. Чтобы обратиться к определенному образцу (строке) таблицы, мы должны добавить индекс к вышеупомянутым id. В MIB индексы массивов — не целые числа (подобно большинству языков программирования). Индексы базируются на значении одной или более областей во входах. В нашем примере udpTable определяется местным адресом и номером местного порта. Например, рисунок 15.15. показывает таблицу с четырьмя строками и значениями для каждого поля. Индекс каждой строки — комбинация двух значений.

Рис. 15.15. Индексы для udpTable

Чтобы обратиться к образцу местного адреса для первой строки, мы используем идентификатор, увеличенный на индекс образца:

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

Лексикографическое упорядочение

Одна интересная точка зрения о MIB-переменных — то, что идентификаторы объекта (включая идентификаторы образца) находятся в лексикографическом порядке. Таблицы упорядочиваются в соответствии правилам строки-столбца, и это означает, что нужно идти от столбца к столбцу, а в каждом столбце нужно идти от вершины до основания, как показано на рисунке 15.16.

Рис. 15.16. Лексикографическое упорядочение

Лексикографическое упорядочение делается менеджером для того, чтобы организовать доступы к набору переменных один за другим, задавая первую переменную, как будет показано в дальнейшем в команде Get Next Request в следующих разделах.

SNMP

SNMP использует и SMI, и MIB в управлении сетью Интернет. Он – прикладная программа, которая позволяет быть:

менеджером, чтобы управлять извлечением значения объекта, заданного агентом;
менеджером, чтобы накапливать значения объекта, заданного агентом;
агентом, чтобы посылать аварийное сообщение о ненормальной ситуации к менеджеру.

PDU

SNMPv3 определяет восемь типов пакетов (или PDUs): GetRequest, GetNextRequest, GetBulkRequest, SetRequest, Response, Trap, InformRequest и Report ( Рис. 15.17.).

Рис. 15.17. SNMP PDUs

GetRequest

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

GetNextRequest

GetNextRequest PDU посылают от менеджера к агенту, чтобы извлечь значение переменной. Найденное значение – это значение объекта, следующего после определенного в таблице Objectid в PDU. Этот запрос главным образом используется, чтобы извлечь значения входов в таблице. Если менеджер не знает индексов входов, он не может извлечь значения. Однако он может применить GetNextRequest и определить Objectid таблицы. Поскольку первый вход имеет Objectid непосредственно после Objectid таблицы, значение первого входа возвращается менеджеру. Менеджер может использовать этот Objectid, чтобы получить значение следующего, и так далее.

GetBulkRequest

GetBulkRequest PDU посылают от менеджера к агенту, чтобы извлечь большое количество данных. Он может применяться вместо кратного числа GetRequest и GetNextRequest PDUs.

SetRequest

SetRequest PDU посылают от менеджера к агенту, чтобы установить (сохранить) значение в переменной.

Ответ (Response)

Ответ PDU посылают от агента к менеджеру в ответ на GetRequest или GetNextRequest. Он содержит значение(я) переменной(ых), которую запрашивает менеджер.

Ловушка (Trap)

Ловушку (также ее называют ловушкой SNMPv2, чтобы отличить от ловушки SNMPvl) PDU посылают от агента к менеджеру, чтобы сообщить о событии. Например, если агент перезагружен, он информирует менеджера и сообщает время перезагрузки.

InformRequest

Inform Request PDU посылают от одного менеджера другому удаленному менеджеру, чтобы получить значение некоторых переменных от агентов, которые управляются удаленным менеджером. Удаленный менеджер отвечает Ответом PDU.

PDU-рапорт (Report)

PDU-рапорт разработан, чтобы сообщить о некоторых типах ошибок между менеджерами.

Формат

Формат для восьми SNMP PDUs показан на рисунке 15.18. GetBulkRequest PDU отличается от других PDU двумя областями, как показано на рисунке.

Рис. 15.18. Формат SNMP PDU

Поля перечислены ниже.

PDU-тип (PDU type). Это поле определяет тип PDU (см. таблицу 15.4).
Запрос ID (Request ID). Это поле — порядковый номер, используется менеджером в запросе PDU и повторяется агентом в ответе. Он нужен, чтобы сравнить запрос и ответ.
Состояние ошибки (Error Status). Это целое число, которое используется только в ответе PDUs, чтобы показать типы ошибок, о которых сообщает агент. Его значение — 0 в запросе PDUs. Таблица 15.3. содержит список типов ошибок, которые могут произойти.

Таблица 15.3. Типы ошибок
Состояние	Название	Значение
0	noError	Нет ошибки
1	TooBig	Слишком большой ответ для размещения в одном сообщении
2	NoSuchName	Переменная не существует
3	BadValue	Значение, которое должно быть сохранено, недопустимо
4	readOnly	Значение не может быть изменено
5	genErr	Другие ошибки

Не ретранслируемая (Non-repeaters). Это поле используется только в GetBulkRequest и удаляет ошибку поля состояния, которая является пустой в запросе PDUs.
Индекс ошибки (Error index). Индекс ошибки — смещение, которое говорит менеджеру, какая переменная вызвала ошибку.
Максимальное повторение (Max-repetition). Это поле также используется только в GetBulkRequest и заменяет поле индекса ошибки, которое является пустым в PDUs-запросе.
VarBindList. Это набор переменных с соответствующими значениями, которые менеджер хочет извлечь или установить. Значения являются нулевыми в GetRequest и GetNextRequest. В PDU-ловушке он показывает переменные и значения, связанные с определенным PDU.

Сообщения

SNMP не посылает отдельные PDU, он включает PDU в сообщение. Сообщение в SNMPv3 состоит из четырех элементов: версия, заголовок, параметры защиты и данные (которые включает кодируемый PDU), как показано в рисунке 15.19.

Рис. 15.19. SNMP-сообщение

Поскольку длина этих элементов отличается от сообщения к сообщению, SNMP применяет основные правила кодирования — BER, чтобы кодировать каждый элемент. (Напомним, что BER использует метку и длину для определения значения.) Версия определяет текущую версию (3). Заголовок содержит значения для идентификации сообщения, максимальный размер сообщения (максимальный размер ответа), флажок сообщения (один октет типа данных OCTET STRING, где каждый бит определяет тип защиты, тип секретности или идентификации либо другую информацию) и модели обеспечения безопасности (определение протокола защиты). Параметр защиты сообщения используется для создания дайджеста сообщения. Данные содержат PDU. Если данные зашифрованы, есть информация об источнике шифровки (программе-менеджере, которая зашифровала сообщение) и контекст шифровки (тип кодирования), сопровождаемый зашифрованным PDU. Если данные не зашифрованы, то они состоят только из PDU.

Чтобы определять тип PDU, SNMP использует метку. Класс контекстно-зависим (10), формат структурирован (1), и числа — 0, 1, 2, 3, 5, 6, 7, 8 ( табл. 15.4.).

Обратите внимание, что SNMPv 1 определяет A4 для "ловушки", которая на сегодняшний день является устаревшей.

Таблица 15.4. Коды для SNMP-сообщений
Данные	Класс		Номер	Полный тег (двоичный)	Полный тег (шестнадцатеричный)
GetRequest	10	1	00000	10100000	A0
GetNextRequest	10	1	00001	10100001	A1
Response	10	1	00010	10100010	A2
SetRequest	10	1	00011	10100011	A3
GetBulkRequest	10	1	00101	10100101	A5
InformRequest	10	1	00110	10100110	A6
Trap (SNMPv2)	10		00111	10100111	A7
Report	10	1	01000	10101000	A8

Пример 1

В этом примере менеджер станции (SNMP-клиент) использует сообщение GetRequest, чтобы извлечь номер UDP-дейтаграммы, которую получил маршрутизатор.

Есть только один объект VarBind (переменная – связка). Соответствующий MIB соотносит эту информацию, содержащуюся в udpInDatagram, с идентификатором объекта 1.3.6.1.2.1.7.1.0. Менеджер хочет извлечь значение. Рис.15.20. показывает в общем виде пакет с иерархической структурой. На рисунке используются белые и цветные участки для последовательностей и серые для PDU. OCTET STRING.

Рис. 15.20. Пример 1

Список VarBind (см. рис.15.20.) имеет длину 0F (15) и состоит только из одной последовательности VarBind, длиной OD (13). В начале списка переменная указывает тип 06 и длину списка 09. Длина дальнейшего сообщения 00.). Сообщение GetRequest PDU имеет длину ID (29).

Имеются три октета последовательностей: параметры безопасности, модель безопасности и флаги. Затем следуют два целых числа, которые определяют максимальный размер (1024) и ID сообщения (64). Есть заголовок длинной 12, который не показан (для простоты). Имеется одно целое число — версия (версия 3). Полностью сообщение составляет 52 байта.

Рисунок 15.21. показывает реальное сообщение, посылаемое менеджером станции (клиентом) к агенту (серверу).

Рис. 15.21. GetRequest сообщение

UDP-порты

SNMP использует услуги UDP на двух заданных портах, 161 и 162. Заданный порт 161 задействован сервером (агентом), и заданный порт 162 отведен клиенту (менеджеру).

Агент (сервер) производит пассивное открытие порта 161. Затем он ждет подключения от менеджера (клиента). Менеджер (клиент) производит активное открытие, используя кратковременный порт. Сообщение запроса посылается от клиента серверу, задействуя кратковременный порт как исходный порт и заданный порт 161 как порт пункта назначения. Сообщение ответа посылают от сервера к клиенту, использующему заданный порт 161 как исходный порт и кратковременный порт как порт пункта назначения.

Менеджер (клиент) производит пассивное открытие порта 162. Затем он ждет подключения от агента (сервера). Агент (сервер) производит активное открытие, используя кратковременный порт, всякий раз, когда посылает сообщение-ловушку (Trap). Это подключение является только односторонним, от сервера к клиенту ( Рис.15.22.).

Рис. 15.22. Номер портов для SMNP

Механизм клиент-сервер в SNMP отличается от других протоколов. Здесь и клиент, и сервер используют заданные порты. Кроме того, и клиент, и сервер должны функционировать бесконечно. Причина в том, что сообщения запроса инициируются менеджером (клиентом), но сообщения-ловушки (Trap) инициируются агентом (сервером).

Краткие итоги

Простой протокол управления сетью (SNMP) — структура для управления устройствами Интернета с использованием набора протоколов TCP/IP.
Менеджер, обычно хост, управляет и контролирует набор агентов, обычно маршрутизаторов.
Менеджер — хост, который выполняет SNMP-программу клиента.
Агент — маршрутизатор или главный компьютер, который выполняет SNMP-программу сервера.
SNMP освобождает задачи управления и от физических характеристик управляемых устройств, и от основной технологии организации сети.
SNMP использует услуги двух других протоколов: структура информации управления (SMI) и основы информации управления (MIB).
SMI определяет тип данных объектов имен, которые могут быть сохранены в объекте, и кодирует данные.
SMI-объекты называются согласно иерархической структуре дерева.
SMI типы данных определены согласно нотации абстрактного синтаксиса 1 (ASN.l).
SMI использует основные правила кодирования (BER), чтобы кодировать данные.
MIB — совокупность групп объектов, которые могут управляться SNMP.

Дата добавления: 2020-11-27; просмотров: 111; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 12

Мы поможем в написании ваших работ!