IBM Tivoli Netcool/OMNIbus, Версия 8.1

Основные понятия и структура MIB

Все модули MIB SNMP, которые определяются для использования конкретным устройством, составляют MIB для этого устройства. Термин MIB часто используется для описания определения отдельного модуля, но это технически некорректно. На самом деле MIB - это сочетание всех модулей, используемых для управления конкретным устройством, как аппаратным, так и программным. Следовательно, более точное название для каждого определенного поставщиком или в RFC модуля - модуль MIB SNMP.

Все модули MIB в конечном счете представляют собой расширения корневого модуля. Все модули MIB, выпущенные отдельными поставщиками, расширяют объект предприятия, определенный в RFC1155-SMI. Таким образом, все агенты SNMP должны поддерживать RFC1155, и все модули MIB - это расширения RFC1155.

Структура управляющей информации (SMI)

Чтобы обеспечить возможность расширения MIB (management information base, база управляющей информации) SNMP, связанные между собой элементы сгруппированы в модули MIB, образующие структурированную иерархию. Каждый модуль MIB определяется внутри следующего конструкта:

Имя_модуля DEFINITIONS ::= BEGIN END.

Теги BEGIN и END позволяют определить несколько модулей в одном текстовом файле. Компиляторы MIB должны уметь обработать любое число модулей, определенных в одном файле, не требуя сообщить им это число.

Существуют соглашения для каждого объекта, определяемого в модуле. Например, имя модуля должно начинаться с заглавной буквы и состоять только из букв, цифр, дефисов (-) или подчеркиваний (_). Имя объекта должно начинаться со строчной буквы и состоять только из букв, цифр, дефисов или подчеркиваний. Комментарии в модулях MIB представляются через два дефиса подряд (--); после этого обозначения текст на любой строке можно игнорировать.

Модульная, легко расширяемая структура MIB позволяет поддерживать любые новые функциональные возможности или устройства путем добавления дополнительного модуля. Когда модуль пишется как расширение другого модуля, он включает в себя раздел IMPORTS, расположенный ниже строки DEFINITIONS. В разделе IMPORTS определяются объекты, которые нужны вышестоящим модулям в иерархии MIB и модулям, в которых они, в свою очередь, определяются.

Следующее определение взято из RFC1157 и указывает на несколько объектов, импортированных из RFC1155. Этот раздел можно считать аналогом оператора include в языках программирования, например, C или Perl, и аналогом файла правил Netcool. Кроме того, для понимания объектов в текущем модуле MIB (RFC1157-SNMP) нужно знать объекты в предыдущем модуле MIB (RFC1155-SMI).
RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks FROM RFC1155-SMI;

При указании имен импортированных MIB легко сделать опечатку. Например, вы могли бы указать модуль MIB с именем RFC1212 вместо правильного имени RFC-1212. Если MIB Manager выделяет ошибки синтаксического анализа, нужно проверить раздел IMPORTS и убедиться, что модули MIB названы правильно. Кроме того, некоторые модули MIB содержат раздел EXPORTS (он также оканчивается точкой с запятой). Этот раздел информирует читателя о том, что автор MIB ожидает использования указанных объектов и другими модулями MIB. Для наших целей этот раздел не важен, и его можно игнорировать.

Определенные типы данных

Модули MIB SNMP определяются в так называемом формате ASN.13 (Abstract Syntax Notation 1). Однако SNMP использует лишь часть ASN.14. ASN.1 определяется в ITU-T X.208 и ISO 8824. Части ASN.1, применяемые к SNMP, определяются в RFC1155. RFC1155 определяет следующие допустимые типы данных SNMP:

Определяемый тип - это механизм, при помощи которого задается конкретный формат примитива или типа конструктора. Авторы MIB могут определять дополнительные типы при помощи конструкта TEXTUAL-CONVENTION.

DisplayString - хороший пример определяемого типа. В модуле MIB SNMPv2-SMI-v1 версия v1 определение DisplayString такое:
DisplayString ::= OCTET STRING (0..255)
В модуле MIB SNMPv2-TC версия v2 определение DisplayString такое:
DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Представляет собой текстовую информацию, взятую из набора символов NVT ASCII, как определено на страницах 4, 10-11 RFC 854. Кратко говоря, RFC 854 задает набор символов NVT ASCII 
так: - используются символы с кодами от 0 до 127 (десятичными) - графические символы 
(32-126) интерпретируются как символы US ASCII - NUL, LF, CR, BEL, BS, HT, VT и FF имеют 
специальные значения, определенные в RFC 854 - у остальных 25 кодов нет стандартной 
интерпретации - последовательность 'CR LF' означает новую строку - последовательность 'CR NUL' означает 
возврат каретки - 'LF' без предшествующего 'CR' означает перемещение в тот же столбец 
следующей строки. - последовательность 'CR x' с любым x, кроме LF или NUL недопустима. 
(Обратите внимание на то, что это значит, что строка может оканчиваться на 'CR LF' или на 'CR NUL', но не на CR.) Любой объект с таким синтаксисом не может содержать более 255 символов." SYNTAX OCTET STRING (SIZE (0..255))
В приведенном выше примере показано, что DisplayString - это строка OCTET STRING длиной от 0 до 255 символов. Обратите внимание на то, что каждый дескриптор объекта (OBJECT DESCRIPTOR), который соответствует типу объекта в стандартном MIB интернета, должен быть уникальной, мнемонической, пригодной для печати строкой.

Определение объектов

Распространенная ошибка при написании модулей MIB - создание неуникального имени объекта. Утверждается, что оператор RFC1155 подразумевает обязательную уникальность только для объектов в пределах одного MIB. Как уже объяснялось выше, MIB - это полный набор модулей, которые, в сочетании, позволяют управлять конкретным устройством. Поэтому объект должен быть уникален во всех модулях MIB, то есть не только в своем собственном модуле, но и среди имен объектов всех импортируемых модулей и тех модулей, которые могут импортироваться этими модулями. Обычный подход, обеспечивающий уникальность имен объектов, заключается в том, чтобы добавлять во все имена модулей спереди биржевой код компании или ее сокращенное название.

Во время определения объекты отображаются в иерархию номеров, напоминающую ветвящееся дерево. При каждом определении объект определяется как конечный узел, подчиненные родительскому объекту. Вот три корневых объекта, определяемых в дереве MIB SNMP:

Все остальные узлы в дереве MIB - дочерние узлы этих одного из этих трех корневых узлов. Например, RFC1155-SMI определяет следующие объекты:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::=
 { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER
 ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT 
IDENTIFIER ::= { private 1 }

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

Вы можете передвигаться по представлению Дерево MIB, раскрывая и сворачивая узлы дерева MIB. Ветви высшего уровня дерева MIB содержат имена модулей MIB, а ветви, содержащиеся внутри каждого модуля MIB, представляют другие элементы, составляющие этот MIB. По мере добавления в MIB дополнительных модулей в дереве MIB появляются дополнительные объекты. Для ссылки на объект можно использовать имя объекта или идентификатор объекта (OID). Аккуратнее ссылаться на OID. OID определяется как номер объекта и номера объектов-предков вплоть до корневого узла, перечисленные через точку (.). OID для объекта предприятия (узел или конечный узел) - это 1.3.6.1.4.1.

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


Библиотека | Поддержка |