Как читать MIB и OID
Общая информация
Знание протокола SNMP, предназначенного для управления и наблюдения за устройствами в сети, очень полезно при диагностики здоровья всей системы. С его помощью администратор может автоматизировать сбор статистики с ключевых узлов: коммутаторов, маршрутизаторов, компьютеров и других устройств поддерживающих этот протокол. В этой статье мы рассмотрим на примерах, как понимать и использовать ключевое понятие в SNMP протоколе — базу данных MIB.[1]
Для начала кратко опишем некоторые важные термины протокола SNMP (Simple Network Managment Protocol):
MIB - Managment Information Base - база данных информации управления, хранящая информацию обо всех объектах (параметрах и настройках) устройства.
OID - Object IDentificator - числовой идентификатор объекта в дереве MIB.
Object Name — имя объекта, уникальная константа для всего MIB, однозначно соответствующая определённому OID.
MIB — это структурированный текстовый файл или несколько файлов, которые содержат информацию о всех объектах устройства. Объектом может быть какая-нибудь настройка или параметры системы. У каждого объекта есть свой набор полей, таких как тип данных, доступность (чтение, запись), статус (обязательный, необязательный), текстовое название настройки. Также объект может содержать другие объекты.
Есть стандартные MIB'ы, определяемые различными RFC и огромное множество MIB'ов от производителей оборудования, которые дополняют стандартные и могут быть взяты с сайтов этих компаний. Эти дополнения необходимы, чтобы описать специфические для устройства параметры. Можно также составить и свои MIB'ы, нигде их не регистрировать и успешно использовать.
Каждый объект в MIB имеет свой уникальный цифровой адрес OID и имя Object Name. SNMP менеджер, используя OID, способен считывать или устанавливать значение объекта. Например, адрес объекта (OID) содержащего наименование системы: 1.3.6.1.2.1.1.5, а его имя (object name): sysName. Так как всё общение между SNMP агентом устройства и SNMP менеджером (системой наблюдения или администратором) происходит через OID, то понимать, что они описывают, очень даже полезно. Имя объекта играет ту же роль в SNMP, что и DNS имя в ip сетях — более наглядное описательное представление набора чисел. Строго говоря в разных MIB'ах оно может представлять разные OID, хотя, те что описаны в RFC, по идее должны быть уникальными для всех.
Как читать OID
Вышеприведённый OID (1.3.6.1.2.1.1.5) для объекта sysName построен целиком на стандартном MIB, и будет существовать скорее всего на всех устройствах. Он читается так:
| 1 | iso | International Organization for Standardization (ISO) |
| 3 | identified-organization | Схема определения организации согласно ISO/IEC 6523-2 |
| 6 | dod | United States Department of Defense (DoD). Эта организация изначально занималась стандартизацией протокола |
| 1 | internet | Интернет |
| 2 | mgmt | IETF Management |
| 1 | mib-2 | База OID для спецификации MIB-2 |
| 1 | system | Характеристики системы |
| 5 | sysName | Имя системы |
OID специфичного объекта для конкретного устройства, дополненный своими MIB'ами, будет значительно длиннее. Вот пример OID датчика температуры у первого вентилятора в Intel Modular Server: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.1. Первые 7 параметров из стандартных MIB'ов, остальные 10 из MIB'ов Intel. Четыре первых мы уже расшифровали выше, остальные поясняются следующим образом:
| 4 | private | Частные проекты |
| 1 | enterprise | Частные организации |
| 343 | intel | Этот номер закреплён за компанией Intel |
| 2 | products | Продукты |
| 19 | modularsystems | Серверы линейки Modular System |
| 1 | multiFlexServer | Тип сервера Multi-Flex Server |
| 2 | components | Компоненты |
| 10 | chassis | Контейнер для информации об аппаратном блоке |
| 206 | fans | Вентиляторы |
| 1 | fanFruTable | Таблица вентиляторов |
| 1 | fanFruEntry | Информация о вентиляторе |
| 16 | fanFruInletTemperature | Температура возле вентилятора |
| 1 | датчик возле первого вентилятора |
Вся описательная информация находится как раз в текстовых файлах MIB, поэтому давайте разберёмся как их читать.
Как читать MIB
При работе с удалённой системой по SNMP протоколу все запросы происходят через OID, отражающий положение объекта в дереве объектов MIB. Все OID системы можно получить просканировав устройство, например командой snmpwalk:
snmpwalk -c public -v2c 10.0.0.1
где
- -c public - обращение к сообществу (comminity) public, на многих устройствах оно существует по умолчанию и в режиме только для чтения;
- -v2c - использовать вторую версию протокола SNMP;
- 10.0.0.1 - IP адрес устройства.
К сожалению, иногда команда не успевает вытащить все переменные, так как на некоторых устройствах их сильно много и защита от DOS атак срабатывает раньше, блокируя доступ на некоторое время. Поэтому данные иногда удобней получать частично, лишь для определённой ветки:
snmpwalk -c public -v2c 10.0.0.1 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16
Однако, полученные цифровые значения часто не раскрывают своего предназначения, поэтому, возникает обратная задача: узнать какой OID у интересующего нас объекта. Для этого придётся изучать MIB устройства.
Так, для того чтобы узнать температуру в корпусе Intel Modular Server, возмём MIB описывающего параметры вентиляторов системы и делаем в нём поиск слова temperature, находим объект fanFruInletTemperature и смотрим его описание. Вот нужный нам фрагмент:
--
-- fans tree
--
fans OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Container for Fan specific information as
well as all components logically contained
within."
::= { chassis 206 }
fanFruTable OBJECT-TYPE
SYNTAX SEQUENCE OF FanFruEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row describes a Fan FRU in the chassis
Current, this should include the 3 Fan FRUs
(the two system Fan FRUs and the I/O Fan FRU)
All system FRUs rows will be present"
::= { fans 1 }
fanFruEntry OBJECT-TYPE
SYNTAX FanFruEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
".."
INDEX { fanFruIndex }
::= { fanFruTable 1 }
FanFruEntry ::=
SEQUENCE {
fanFruIndexIndex,
fanFruPresencePresence,
fanFruVendorDisplayString,
fanFruMfgDateDisplayString,
fanFruDeviceNameDisplayString,
fanFruPartIdromBinary16,
fanFruSerialNoIdromBinary16,
fanFruMaximumPowerPower,
fanFruNominalPowerPower,
fanFruAssetTagIdromBinary16,
fanFruPowerLedPowerLedStates,
fanFruFaultLedFaultLedStates,
fanFruOpCodeVersionDisplayString,
fanFruBootBlockVersionDisplayString,
fanFruNumOfFansINT32withException,
fanFruInletTemperatureINT32withException
}
Строка в описании объекта fans
::= { chassis 206 }
говорит о том, что описанный объект будет расширять объект (являться веткой в дереве объектов) chassis, имея в нём индекс 206, а следующий объект fanFruTable в свою очередь будет расширять объект fans, представляя в нём ветку с индексом 1, также fanFruEntry будет первой веткой у объекта fanFruTable. В параметрах fanFruEntry и содержится интересующий нас fanFruInletTemperature.
Запоминаем адрес ветки: 206.1.1, начиная от объекта chassis. Теперь ищем далее в файле описание объекта fanFruInletTemperature:
fanFruInletTemperature OBJECT-TYPE
SYNTAX INT32withException
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"FRU Inlet Temperature in Degrees Celsius"
::= { fanFruEntry 16 }
Видим, что его индекс=16. Таким образом, 206.1.1.16 - содержит список всех температурных датчиков возле вентиляторов системы и, соответственно, 206.1.1.16.1 - номер первого из них. Сколько их всего узнаем позже. Теперь выясним адрес объекта chassis, в котором находятся только что найденные нужные нам параметры. Так, сквозной поиск строки "chassis OBJECT-IDENTITY" по всем MIB файлам приводит нас к другому MIB'у:
chassis OBJECT-IDENTITY
STATUS current
DESCRIPTION
"chassis for the Multi-Flex Server product.
Container for chassis specific information
as well as all components logically contained within."
::= { components 10 }
где мы узнаём, что он содержится в объекте components. Далее сквозной поиск строки "components OBJECT-IDENTITY" (нужно учесть, что пробелов между словами может быть разное количество) даёт строчку:
components OBJECT IDENTIFIER::= { multiFlexServer 2 }
Далее находим и остальное:
--
-- Path to our product
--
intelOBJECT IDENTIFIER ::= { enterprises 343 }
productsOBJECT IDENTIFIER ::= { intel 2 }
modularsystems OBJECT IDENTIFIER ::= { products 19 }
multiFlexServer OBJECT IDENTIFIER ::= { modularsystems 1 }
Записывая все полученные ID объектов получаем полный OID для температурных датчиков: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16
Теперь можно узнать их значения, заодно выяснив и их количество:
$ snmpwalk -c public -v2c 10.0.0.1 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16 iso.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.1 = INTEGER: 27 iso.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.2 = INTEGER: 26 iso.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.3 = INTEGER: 19
По приведённому несложному алгоритму можно прочитать любой MIB, главное получить его, что, к сожалению, не всегда возможно.
Для облегчения работы с MIB файлами существует множество программ как платных, так и бесплатных, в том числе и on-line (см. раздел Ссылки). Любой поисковик на запрос MIB browser выдаст много полезных ссылок. Я пользуюсь iReasoning MIB Browser, но не потому, что он лучше других, а просто я попробовал его первым и он мне вполне понравился.
Теперь, зная как читать MIB'ы и OID'ы администратору будет легче использовать и донастраивать системы мониторинга здоровья системы, такие как Zabbix, MRTG, PRTG, Cacti и т.п.
Ссылки
- ↑ Первоначально статья была опубликована в журнале Системный администратор, январь 2011
См. также
- Обзорная статья по протоколу SNMP.
- On-line сервисы для чтения MIB:
- http://www.oid-info.com/get/ - поиск по OID с детальным пояснением всех узлов. Есть возможность расширить список своими MIB'ами. Можно посмотреть дерево объектов.
- http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en - поиск по OID и Object Name. Кроме стандартных, есть специфичные для Cisco MIB'ы
