В этой теме описаны типы объектов, определяемых в SNMP v1 и v2.
Вы можете найти информацию об объекте, описанную в следующих разделах, выбрав модуль в представлении Модули MIB и выполнив поиск ifIndex в поле Поиск представления Дерево OID. Скопируйте объект ifIndex в иерархии Дерево OID, чтобы посмотреть информацию об объекте и информацию текстовых соглашений в представлении Подробности.
OBJECT IDENTIFIER определяется в SNMP v1 и служит основным блоком при построении дерева MIB. Идентификаторы объектов аналогичны заголовкам глав в книге, они не содержат фактических сведений, но дают представление о том, какого рода сведения содержатся в их потомках.
OBJECT-TYPE определяется в SNMP v1 и служит контейнером для информации об управляемом устройстве или некоторой измеряемой величине, характеризующей устройство.
TEXTUAL-CONVENTION (TC) - это определение типа объекта, само оно объектом не считается. В представлении Модули MIB можно выбрать Текстовые соглашения из списка Представление, чтобы посмотреть проанализированные текстовые соглашения в дереве MIB. Выберите имя TC в дереве MIB, и его определение появится в окне Подробности.
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "Событие BGP Established генерируется, когда BGP FSM
переходит в состояние ESTABLISHED." ::= 1 Родительский объект прерывания указывается в разделе ENTERPRISE. Однако можно определить объект дерева MIB как дочерний объект номер 1 родительского объекта bgp. Например, bgpVersion определяется как { bgp 1} в модуле RFC1269-MIB. Поэтому невозможно добавить прерывание v1 в дерево MIB как конечный узел с родительским узлом ENTERPRISE.
В SNMP v2 определение TRAP-TYPE заменяется на NOTIFICATION-TYPE, причем указывается, что это новое прерывание v2 определяется, как все объекты MIB - с заданием родителя и номера его дочернего узла, так что обсуждаемые трудности относятся только к прерываниям v1. В разделе 4.1 RFC1155 определяется, что применение нуля (0) как номера дочернего узла недопустимо; оно резервируется для использования в будущем. SNMP v2 использует нулевой номер, разрешая поставщикам добавлять прерывания v1 в MIB v2, добавляя ноль в имя предприятия, а затем добавляя номер прерывания после этого нуля. Поэтому в v2 можно определить идентификатор объекта с нулевым дочерним номером предприятия, а затем добавить прерывания v1 как дочерние узлы этого нулевого узла.
Это соглашение привело к еще одной распространенной ошибке у авторов MIB. В разделе 4 RFC1155 утверждается следующее:
"Определение типа объекта состоит из пяти полей: OBJECT: ------- Текстовое имя, указывающее OBJECT DESCRIPTOR для типа объекта, вместе с соответствующим OBJECT IDENTIFIER. Syntax: Абстрактный синтаксис для типа объекта. Он должен быть разрешен до экземпляра ObjectSyntax типа ASN.1 (определен ниже). Definition: Текстовое описание семантики этого типа объектов. Реализации должны обеспечивать, чтоб экземпляры объектов в них соответствовали этому определению, так как этот MIB предназначен для использования в средах различных поставщиков. Поэтому жизненно важно, что значение объектов было единым на всех компьютерах. Access: один из следующих - read-only, read-write, write-only или not-accessible. Status: один из следующих - mandatory, optional или obsolete. В последующих замечаниях могут быть заданы также другие поля для объектов, которые они определяют."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Достигнут порог 15-минутного интервала Loss of Framing." ::= { adslAtucTraps 0 1 } Объекты, передаваемые с прерыванием v1 или уведомлением v2 называют переменными привязки. Переменные привязки содержат дополнительную информацию о сообщаемом событии. В прерывании v1 переменные привязки конкретизируются в разделе VARIABLES, а в уведомлении v2 переменные привязки перечисляются в разделе OBJECTS. Они используются одинаково во всех версиях SNMP. Порядок, в котором переменные привязки появляются в списке, важен, поскольку в коде PDU (пакет SNMP) связанные значения задаются в том же порядке, в котором они перечислены в MIB.
Пусть в разделе OBJECTS указаны следующие три переменных привязки: ifIndex, ifAdminStatus и ifOperStatus. Это значит, что в коде ifIndex указывается первым, ifAdminStatus - вторым, и ifOperStatus - третьим. Посмотрев IF-MIB, мы обнаружим, что тип объекта ifIndex определен как InterfaceIndex. Так как это - не допустимый примитивный тип ASN.1 для SNMP, он должен быть текстовым соглашением. Выполнив поиск по текстовому соглашению, мы обнаружим, что InterfaceIndex в действительности разрешается как тип Integer32 (32-битное целое). Таким образом, когда PDU поступает в MIB Manager, первая переменная привязки будет целым числом. Чтобы определить значение этого целого числа, MIB Manager должен обратиться к модулю IF-MIB, найти ifIndex и прочитать связанную информацию об объекте. Проверяя вторую переменную привязки, мы находим перечисляемый целый тип:
SYNTAX INTEGER { up(1), -- готов к передаче пакетов down(2),
testing(3) -- в некотором режиме тестирования }Когда переменная привязки декодируется из пакета SNMP, ее значение будет целым числом, интерпретируемым на основе пунктов в этом списке перечисления. Когда MIB Manager используется для создания файла правил, он создаст таблицу просмотра, чтобы автоматически связывать целые числа в перечислении с их текстовыми представлениями. Третья переменная привязки - тоже перечисляемого типа с теми же значениями. Поэтому если ifAdminStatus имеет значение 1 (up), а ifOperStatus - 2 (down), мы знаем, почему было сгенерировано событие, и можем перейти к попытке определить причину этого отключения.
Переменные связывания представляются пользователю в файле правил как $1, $2, $3 и т.д., при этом каждый номер соответствует номеру переменной привязки. MIB Manager создает элементы на основе элементов переменной привязки и использует их для задания переменных в таблице подробностей. Например, элементами, использованными в таблице подробностей, могут быть $ifIndex = $1 - целое число, $ifAdminStatus = $2, который может быть up (1), и $ifOperStatus = $3, который может быть down (3). Любые изменения, внесенные в параметры объектов, автоматически задаются в файле правил с использованием набора соглашений, заданного в Netcool Knowledge Library (NCKL).
Таблицы представляют собой эквивалент многомерного массива со строками и столбцами данных. Табличный объект определяется как последовательность (SEQUENCE OF) объектов Entry. Затем объект Entry определяется как последовательность объектов OBJECT-TYPE. Иногда поставщик разрабатывает необычную систему, как например, в маршрутизаторе Cisco 10k. Это устройство работает с внутренней таблицей условий предупреждений и генерирует прерывания или уведомление при внесении изменения в таблицу. Далее, чтобы узнать текущее состояние активных оповещений для данного устройства, необходимо отправить требование SNMP GET для содержимого таблицы. В результате получение оповещений для менеджера SNMP оказывается более трудным, хотя и возможным, и администратору понадобиться соответствующий инструмент.
OCTET - это конструкт данных, состоящий из восьми бит (обычно называемый байт). Далее, OCTET STRING - это строка байтов. Термин OCTET STRING не подразумевает, что все байты в строке - алфавитно-цифровые символы. Это могут быть и двоичные символы, используемые как битовые маски.