Как читать MIB файлы

Если для общения по SNMP со своими «железками» вы начинаете поиск не в документации бренда а ищете mib файлы для нее, эта статья не для вас.

Ну а если слова SNMP, Net-SNMP, snmpwalk, snmpget вам уже встречались, но открыв любой «*.mib» вы предпочитаете его закрыть и обратиться к какому либо из mib browsers — вам стоит это почитать.

Небольшое предисловие

Книга “Основы SNMP” издательства Символ (O’REILLY в оригинале), стояла на моей книжной полке много лет, иногда что то в ней смотрел, но первые главы с теорией были абсолютно непонятной тяжелой информацией. Пока не было реальной потребности, это было как читать о «сферическом коне в вакууме»

Лет 5 назад дошли руки до установки Zabbix в организации. И, если шаблоны для коммутаторов и маршрутизаторов легко поправил, меняя некоторые OID в зависимости от модели, выискивая их с помощью snmpwalk, то взявшись за только что установленные Системы Гарантированного Питания (СГП) Huawei ETP-48/200(60) понял, что без MIB файлов не обойтись. Шаблон Zabbix делал “с нуля”.
Сопоставление web-интерфейса:

и выгрузки всего дерева информации с помощью snmpwalk в файл не помогло, железка мне была незнакома совсем, аналогии не помогали. На github’e был найден HUAWEI-SITE-MONITOR-MIB.txt, почти подходящий для наших СГП, но я и его, как сейчас понимаю, использовал бездарно — превратил в Excel файл вида  OID <-> “его название”.
Но мне все равно это сильно помогло, СГП я мониторю уже Zabbix’ом.

Стал вопрос о шаблоне для аппаратуры ВЧ связи ССТМ «ES100» (система связи и телемеханики), взгляд упал на вышеназванную книгу и теория вдруг оказалась очень понятной. (После создания то с нуля шаблона для Zabbix sic!)

Итак, как лучше “понимать” свои железки используя их MIB файлы

Я не буду расписывать с нуля что такое SNMP, OID, как установить snmpwalk, snmpget и т.п. Информации в сети предостаточно.
Здесь, на Хабре есть прекрасная статья SNMP MIBs и как их готовить где описан другой подход к «ковырянию» в MIB но там уже требуется понимание «что внутри у животинки»

Но, по порядку..

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

Для описания этого существует целый стандарт “The Structure of Management Information ver. 1/Структура информации для управления” (SMIv1, RFC1155) и дополнения для SNMPv2 (SMIv2, RFC 2578). Если не указано, я буду использовать определения SMIv2, он сейчас встречается гораздо чаще.

Определение управляемых объектов может содержать три атрибута:

Имя 

Имя, или идентификатор объекта (OID — Object identifier) уникально определяет управляемый объект. Имена обычно бывают двух видов  — цифровые и «удобочитаемые».
В любом случае имена получаются длинные и неудобные. В SNMP-приложениях делается очень много работы для того, чтобы помочь нам удобно ориентироваться  в пространстве имен.

Тип и синтаксис 

Тип данных управляемого объекта определяется при помощи части языка ASN.1 (Abstract Syntax Notation One). ASN.1 — это способ указать, как данные представляются и передаются между менеджерами и агентами в контексте SNMP. Преимущество ASN.1 заключается в том, что он независим от машины. Это означает, что компьютер с ОС Windows может связываться с любым Unix или мэйнфреймом и не беспокоиться о таких вещах, как порядок байтов. 
Если интересны подробности, дальше Хабра ходить не нужно, вот очень подробная статья: ASN.1 простыми словами (кодирование типа REAL)

Кодировка 

Конкретный управляемый объект кодируется в строку октетов с использованием правил «Basic Encoding Rules» (BER стандарта ASN.1). Правила BER определяют, как объекты кодируются и декодируются, чтобы их можно было транспортировать по среде передачи, например Ethernet.

Имена OID

Все объекты организованы в древовидную иерархическую структуру (только корень root обычно рисуется сверху). Идентификаторы (имена) объектов состоят из ряда целых чисел, определяемых узлами дерева и разделенных точками. Более удобочитаемая форма, состоящая из слов разделенных точками по сути тоже самое, только каждому узлу соответствует свое имя (слово) а наиболее часто употребляемые кусты (куски) дерева описаны одним именем:

так OID .1.3.6.1.2.1.1.2 вместо .iso.org.dod.internet.mgmt.mib-2.sysObjectID описывается как SNMPv2-MIB::sysObjectID  (кстати запомните этот OID, к нему вернемся позже)

Начало дерева имен можно представить следующей картинкой

рисовал картинку не сам…

(да я взял ее в блоге компании Selectel, хорошая статья (https://selectel.ru/blog/snmp/) и это не реклама компании — статья просто хорошая

На таких рисунках чаще всего не отображают ветви ccitt(0) и joint(2), это следы зарождения SNMP еще до согласования с международной организацией по стандартизации ISO. 

Вот определение поддерева internet и его поддеревьев на языке ANS.1 (именно на нем написаны все MIB файлы, в которых нам предстоит разбираться)

directory сейчас не используется,
experimental зарезервирована для целей тестирования,
mgmt (management) определяет стандартный набор управляемых объектов интернета,
за объекты в private люди и организации отвечают сами.

Если запустить:

без указания какого либо OID, команда вернет  все дерево, что найдет перебором по пути .1.3.6.1.2.1. это её поведение по умолчанию. Но это будет общая, стандартная информация, которая нам мало что расскажет о самой “железке”.
Все, что относится к конкретному оборудованию конкретного производителя находится в ветке enterprises и всю информацию из нее можно получить, запустив:

snmpwalk -v 2c -c MySeCrEt IP_addr_host  .1.3.6.1.4.1.

или же “спросить поточнее” у самой железки, запросив вышеупомянутый мною OID:
snmpwalk -v 2c -c MySeCrEt IP_addr_host  .1.3.6.1.2.1.1.2 

вернет, например для Huawei ETP 48/200
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.2011.6.164.1.2

если вам необходимо получить информацию в числовом виде, используйте ключ -On (options numerical) команды snmpwalk, ответ будет

.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.2011.6.164.1.2

Кстати вы заметили, что мы спрашивали OID .1.3.6.1.2.1.1.2 
а получили OID .1.3.6.1.2.1.1.2.0?

Далее будет сказано подробнее, объекты в SMI могут быть одиночными (скалярами) или организованы в виде таблицы.  
sysObjectID именно скаляр — и это является причиной частых ошибок при использовании snmpget

snmpget имеет тот же синтаксис что и snmpwalk но возвращает только один OID, тот что запрошен. Так что при изучении “железок” проще пользоваться snmpwalk, ну или с точностью “до нуля” указывать OID

Описание MIB

Изучать MIB лучше на конкретном примере. Я буду использовать части HUAWEI-SITE-MONITOR-MIB.mib, не самое очевидное может для вас, но тем интереснее — понять что то, с чем не связаны
начнем с заголовков:

HUAWEI-SITE-MONITOR-MIB DEFINITIONS ::= BEGIN       IMPORTS      huaweiUtility          FROM HUAWEI-MIB          OBJECT-GROUP, NOTIFICATION-GROUP          FROM SNMPv2-CONF          Integer32, Unsigned32, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE          FROM SNMPv2-SMI          TEXTUAL-CONVENTION          FROM SNMPv2-TC;           --     September 15, 2010 at 11:00 GMT      hwSiteMonitorMIB MODULE-IDENTITY     LAST-UPDATED "201103040000Z"    -- March 04, 2011 at 00:00 GMT     ORGANIZATION     "Huawei Technologies Co.,Ltd."     CONTACT-INFO     "Floor 5, Block 4, R&D Building,     Huawei Longgang Production Base,     Shenzhen,   P.R.C.     http://www.huawei.com     Zip: 518129."     DESCRIPTION     "Site Monitor MIB defines MIB objects which provides load and backup management,      patch management NMS interfaces.     The current version is V1.01"     REVISION "201103040000Z"    -- March 04, 2011 at 00:00 GMT     DESCRIPTION     "Add hwAcOffLongTimeAlarmTraps, hwAcOffLongTimeAlarmResumeTraps"     REVISION "201010310000Z"    -- October 31, 2010 at 00:00 GMT     DESCRIPTION     "Huawei site monitor mib V1.00"     ::= { huaweiUtility 164 }

любой MIB файл начинается с импорта из других MIB, (посмотрите на досуге SNMPv2-TC или SNMPv2-CONF вы увидите что такое хорошо структурированная информация), 
контактной информации, описания, версий и т.п. и определяет отправную точку этого MIB файла, его положения в дереве.

hwSiteMonitorMIB ::= { huaweiUtility 164 }

и, зная числовое обозначение 1.3.6.1.4.1.2011.6.164 даже не имея под рукой HUAWEI-MIB я могу предположить, что: 

huaweiUtility ::= { huaweiMIB 6 }

huaweiMIB ::= { enterprises 2011 }

насчет названия huaweiMIB я могу ошибаться, но смысл понятен.

Далее следует описание текстовых обозначений. Они введены только в SMIv2 и позволяют создавать управляемые объекты более абстрактно. 

-- -- Textual conventions --          DisplayString ::= TEXTUAL-CONVENTION     STATUS current     DESCRIPTION     "Description."     SYNTAX OCTET STRING (SIZE (1..64))           RowStatus ::= TEXTUAL-CONVENTION     STATUS current     DESCRIPTION     "Description."     SYNTAX INTEGER     {     active(1),     notInService(2),     notReady(3),     createAndGo(4),     createAndWait(5),     destroy(6)     }

Вообще все текстовые обозначения могут быть следующих типов:

Типы текстовых обозначений

Теперь подробнее о синтаксисе определений объектов. Общий вид следующий:

<имя> OBJECT-TYPE
SYNTAX <тип данных>
UnitsParts <дополнительно, см. Дополнения в определении объекта в SMIv2>
MAX-ACCESS <см. Дополнения в определении объекта в SMIv2>
STATUS <см. Дополнения в определении объекта в SMIv2>
DESCRIPTION
“Текстовое описание, характеризующее этот объект”

AUGMENTS { <имя таблицы> }

::= { <Уникальный OID, определяющий этот объект> }

Атрибут SYNTAX  обеспечивает определение управляемых объектов. Типы данных просто способ определить какой вид информации может содержать управляемый объект. Эти типы аналогичны тем, которые можно встретить в языках программирования, например C

Типы данных, определенные в SMIv1

В SMIv2 добавлено еще несколько типов данных

Типы данных добавленные в SMIv2

И, наконец, мы дошли до описания оставшихся атрибутов объектов

Дополнения в определении объекта в SMIv2

Этой теории вполне достаточно, чтобы понять весь MIB файл.

-- -- Node definitions --          -- 1.3.6.1.4.1.2011.6.164.1     hwSiteMonitorMIBObjects OBJECT IDENTIFIER ::= { hwSiteMonitorMIB 1 }             -- 1.3.6.1.4.1.2011.6.164.1.1     hwSiteInfo OBJECT IDENTIFIER ::= { hwSiteMonitorMIBObjects 1 }           -- 1.3.6.1.4.1.2011.6.164.1.1.1     hwSiteSummary OBJECT IDENTIFIER ::= { hwSiteInfo 1 }           -- 1.3.6.1.4.1.2011.6.164.1.1.1.1     hwSiteId OBJECT-TYPE     SYNTAX Unsigned32     MAX-ACCESS read-only     STATUS current     DESCRIPTION     "Site ID, default value: 000,000.     Naming rule of the site device ID (six digits):      The first three digits indicate the device name and the last three digits      indicate the serial number (SN) of the device. If the last three digits are 000,     it indicates a virtual device. "     ::= { hwSiteSummary 1 }

 В начале описывается объекты структуры hwSiteMonitorMIBObjects как составляющая hwSiteMonitorMIB   и т.д. и наконец первый “настоящий” объект hwSiteId     

как видите, это скаляр и 

snmpget -v 2c -c MySeCrEt  10.XX.XX.197 .1.3.6.1.4.1.2011.6.164.1.1.1.1

вернет

SNMPv2-SMI::enterprises.2011.6.164.1.1.1.1 = No Such Instance currently exists at this OID

поэтому, поняв из MIBа что это скаляр, мы выполняем

snmpget -v 2c -c MySeCrEt  10.XX.XX.197 .1.3.6.1.4.1.2011.6.164.1.1.1.1.0

и получаем

SNMPv2-SMI::enterprises.2011.6.164.1.1.1.1.0 = STRING: «Mayak»

как видим, хотя объект и read-only, подрядчик при первоначальной настройке изменил на имя подстанции, или, что вероятнее, этот MIB не совсем от этой СГП  

А вот пример отсутствия у нас дизеля, и он действительно не предусмотрен проектом СГП

 -- 1.3.6.1.4.1.2011.6.164.1.1.1.9     hwSiteDGWorkStatus OBJECT-TYPE     SYNTAX INTEGER     {     idle(1),     working(2),     unknown(255)     }     MAX-ACCESS read-only     STATUS current     DESCRIPTION     "State of the diesel working state. It is an enumeration type:     If the enumeration value is 1, it indicates that the diesel is in the idle state;     If the enumeration value is 2, it indicates that the diesel is in      the working state;       If the enumeration value is 255, it indicates diesel operation status unknown. "     ::= { hwSiteSummary 9 }

snmpget -v 2c -c MySeCrEt  10.XX.XX.197 .1.3.6.1.4.1.2011.6.164.1.1.1.9.0

SNMPv2-SMI::enterprises.2011.6.164.1.1.1.9.0 = No Such Object available on this agent at this OID

С одиночными (скалярами) объектами разобрались, они все подобны.

Рассмотрим объекты таблицы. 

Например батареи, которыми укомплектована СГП. Они имеют установочные параметры — имена, ID, пороги алармов по температуре. Батарей может быть от 0 до какого то числа.
(не бесконечности)

      -- 1.3.6.1.4.1.2011.6.164.1.4.4     hwBattString OBJECT IDENTIFIER ::= { hwSiteBatterys 4 }      -- 1.3.6.1.4.1.2011.6.164.1.4.4.1     hwBattStringConfigTable OBJECT-TYPE     SYNTAX SEQUENCE OF HwBattStringConfigEntry     MAX-ACCESS not-accessible     STATUS current     DESCRIPTION     "Battery string config table. Use this table to get battery string equipment ID      and equipment name, to set battery standard capacity and battery install time       as well. This table's index is hwBattStringConfigIndex, clone battery       string config table."     ::= { hwBattString 1 }

Объект hwBattStringConfigTable, обратите внимание, он not-accessible и snmpget c этим OID вернет No Such Object и добавление нуля к этому OID не поможет, это объект контейнер*(таблица)* , он не содержит данных, только другие объекты (строки таблицы), а точнее последовательность (sequence of) объектов типа HwBattStringConfigEntry — обратите внимание название ВСЕГДА с большой буквы, это название ТИПА ОБЪЕКТА, определяемого далее в MIB файле

    -- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1     hwBattStringConfigEntry OBJECT-TYPE     SYNTAX HwBattStringConfigEntry     MAX-ACCESS not-accessible     STATUS current     DESCRIPTION     "Battery string config table entry."     INDEX { hwBattStringConfigIndex }     ::= { hwBattStringConfigTable 1 }

Объект  hwBattStringConfigEntry  одна КОНКРЕТНАЯ строка таблицы (название всегда с маленькой буквы) имеющая тип HwBattStringConfigEntry (название с большой буквы) и дальше следует описание самого типа, это по сути СПИСОК (SEQUENCE) столбцов, входящих в эту строку

    HwBattStringConfigEntry ::=     SEQUENCE {     hwBattStringConfigIndex     Integer32,     hwBattStringEquipId     Unsigned32,     hwBattStringEquipName     OCTET STRING,     hwSetBattsTempUpperLimit     Integer32,     hwSetBattsTempLowerLimit     Integer32,     hwSetBattsTempMeasureUpperLimit     Integer32,     hwSetBattsTempMeasureLowerLimit     Integer32,     hwSetBattStdCapacity     Integer32,     hwSetBattInstallTime     OCTET STRING,     hwBattStringConfigRowStatus     RowStatus       }

Дальше следуют описания объектов (столбцов) составляющих строку hwBattStringConfigEntry 

Самый первый объект INDEX и он входит в состав всех объектов, составляющих hwBattStringConfigEntry 

 небольшое отступление: я раньше представлял себе “строение” SNMP “по человечески”, считал что если 1.1.1.2 например это какой то объект, то 1.1.1.2.1.5, 1.1.1.2.2.6, 1.1.1.2.3.7  это какие-то параметры (атрибуты) этого объекта (я жестоко ошибался),
а на самом деле:
164.1.4.4.1.1.4.2289
164.1.4.4.1.1.4.2290
164.1.4.4.1.1.5.2289
164.1.4.4.1.1.5.2290

это два параметра 164.1.4.4.1.1.4 и 164.1.4.4.1.1.5 двух объектов(строк) 2289 и 2290

так вот 2289 и 2290 — это и есть INDEX, присваивается в момент загрузки устройства и может измениться после перезагрузки

именно поэтому, если вы хотите, чтобы например интерфейсы  не меняли в SNMP свой ifIndex рекомендуют прописывать в конфигурации: 
на оборудовании Cisco: snmp-server ifindex persist 
а на оборудовании Huawei: ifindex constant

    -- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.1     hwBattStringConfigIndex OBJECT-TYPE     SYNTAX Integer32 (1..100)     MAX-ACCESS read-only     STATUS current     DESCRIPTION     "Device table index of the battery string, which value range: 1 to 100."     ::= { hwBattStringConfigEntry 1 }           -- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.2     hwBattStringEquipId OBJECT-TYPE     SYNTAX Unsigned32 (3001..3100)     MAX-ACCESS read-only     STATUS current     DESCRIPTION     "Batteries device ID, can be configured by users. Value range: 003,001 to 003,100,      in which the first three digits specify the device type and the last three       specify the device SN."     ::= { hwBattStringConfigEntry 2 } 

Идентификатор оборудования hwBattStringEquipId, ранее в этом файле (я не показываю) были описаны группы оборудования: 1000 — Монитор, 2000 — Выпрямители, 3000 — Батареи и т.д. поэтому конкретные батареи в группе будут иметь идентификаторы 3001, 3002 и т.д

 -- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.3     hwBattStringEquipName OBJECT-TYPE     SYNTAX OCTET STRING (SIZE (0..63))     MAX-ACCESS read-write     STATUS current     DESCRIPTION     "Batteries device name, of the character string type, is used to specify       the batteries. Users can configure it.     Otherwise, the configured character can not be any other languages except English."     ::= { hwBattStringConfigEntry 3 }

Вот пример целочисленного объекта измеряемого в градусах по Цельсию, позволяющего хранить (в Integer объекте) до десятых долей градуса. 
Как? Посмотрите описание, возвращаемое значение необходимо делить на 10:

    -- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.4     hwSetBattsTempUpperLimit OBJECT-TYPE     SYNTAX Integer32 (-50..100)     UNITS "centigrades"     MAX-ACCESS read-write     STATUS current     DESCRIPTION     "Upper threshold of the battery temperature alarm, can be configured by users.      Value range: -50 to 100, Unit: centigrade (°„C), and the value is an integer (.0)."     ::= { hwBattStringConfigEntry 4 }

 А вот элемент возвращающий Ампер-часы (тоже integer но хранит до десятых долей)

     -- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.8     hwSetBattStdCapacity OBJECT-TYPE     SYNTAX Integer32 (0..10000)     UNITS "Ah"     MAX-ACCESS read-write     STATUS current     DESCRIPTION     "Set battery standard capacity, is an inherent attribute of the device.       Value range: 0 to 10000, unit: Ah, the value is an integer (.0). "     ::= { hwBattStringConfigEntry 8 }

 

    -- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.9     hwSetBattInstallTime OBJECT-TYPE     SYNTAX OCTET STRING (SIZE (0..128))     MAX-ACCESS read-write     STATUS current     DESCRIPTION     "Set battery install time, of the character string type,       can be configured by users.     Otherwise,       the configured character can not be any other languages except English. "     ::= { hwBattStringConfigEntry 9 }       -- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.100     hwBattStringConfigRowStatus OBJECT-TYPE     SYNTAX RowStatus     MAX-ACCESS read-create     STATUS current     DESCRIPTION     "RowStatus of battery string config table."     ::= { hwBattStringConfigEntry 100 }

Я пропустил несколько объектов таблицы, по сути все одно и тоже. На моем конкретном оборудовании snmpwalk -v 2c -c MySeCrEt  10.XX.XX.197 1.3.6.1.4.1.2011.6.164.1.4.4.1 возвращает:

SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.1.5 = INTEGER: 5
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.1.6 = INTEGER: 6
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.2.5 = Gauge32: 3001
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.2.6 = Gauge32: 3002
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.3.5 = STRING: «Battery String1»
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.3.6 = STRING: «Battery String2»
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.4.5 = INTEGER: 50
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.4.6 = INTEGER: 50
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.5.5 = INTEGER: -10
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.5.6 = INTEGER: -10
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.8.5 = INTEGER: 190
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.8.6 = INTEGER: 190
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.100.5 = INTEGER: 1
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.100.6 = INTEGER: 1 

Вы же видите hwBattStringConfigIndex у меня принимает значения 5 и 6, установлены 2 батареи и все объекты(столбцы) представлены 2 раза для каждого INDEX’а  (строки) отдельно

не всегда индекс нужного вам параметра будет последним числом в строке

озаботился созданием в Zabbx триггера состояния канала. Часто это не падение интерфейса, это может быть резервный канал, редко попадающий в таблицу маршрутизации, или стойка ВЧ связи, у которой с Ethernet портом все хорошо, а ВЧ тракт лёг. Самое простое это триггер на состояние Cisco IPSLA или Huawei NQA, но у Huawei, если настроен больше чем один NQA test, один от другого можно отделить с помощью ‘#SNMPINDEX’, из строки:
‘1.3.6.1.4.1.2011.5.25.111.4.1.1.3.{#SNMPINDEX}.{переменный_увеличивающийся на 1 индекс}’
и даже если настроить один запрос и не хранение последних значений, последняя часть превратится в {в длинный постоянный индекс}, все равно опрашивать надо:
«1.3.6.1.4.1.2011.5.25.111.4.1.1.3.11.80.105.110.103.79.118.101.114.82.82.76.7.80.105.110.103.78.69.83″
«1.3.6.1.4.1.2011.5.25.111.4.1.1.3.12.80.105.110.103.79.118.101.114.86.79.76.83.7.80.105.110.103.78.69.83″
где 11 и 12 как раз определяют номер NQA test

 Вышеописанную таблицу проще понять если представить в виде ….. да, таблицы Excel:

hwBattStringConfigTable oid: 1.3.6.1.4.1.2011.6.164.1.4.4.1

А каждая вместе взятая строка таблицы (не заголовки), это объект HwBattStringConfigEntry описатель структуры данных (строки)

Надеюсь этот небольшой опус кому-нибудь поможет прийти к пониманию SNMP и MIB файлов немного быстрее, чем я к этому шел 🙂