Как перевести mib в oid
Объяснение SNMP MIB и OID
SNMP имеет несколько компонентов под поверхностью, которые позволяют передавать информацию о производительности обратно конечному пользователю. Агенты SNMP, SNMP менеджеры, MIBS, и OIDs все работают вместе, чтобы сделать эти переводы возможными. В этой статье мы рассмотрим, что такое MIBS и OID, и что они делают. Однако, прежде чем мы это сделаем, мы должны посмотреть, что такое SNMP.
Что такое SNMP?
SNMP или Простой протокол управления сетью это хорошо известный сетевой протокол, который находится на уровне приложений. Протокол SNMP восходит к 1989 году и был создан для того, чтобы устройства могли обмениваться информацией друг с другом по сети. Сегодня SNMP используется для мониторинга устройств с поддержкой SNMP и посмотреть, как их производительность задерживается. Архитектура SNMP состоит из менеджеров SNMP и агентов SNMP.
Отношения между менеджером SNMP и агентом SNMP основаны на сообщениях и командах. Эти сообщения бывают разных форм. Некоторые из сообщений, которыми обмениваются эти два компонента, перечислены ниже:
Смотрите также: SNMP объяснил
Что такое MIB?
MIB или База управленческой информации представляет собой отформатированный текстовый файл, который находится в диспетчере SNMP и предназначен для сбора информации и ее упорядочения в иерархическом формате. Менеджер SNMP использует информацию из MIB для перевода и интерпретации сообщений перед их отправкой конечному пользователю..
Что такое OID?
Внутри MIB есть много различных управляемых объектов, которые могут быть идентифицированы OID или Идентификатор объекта. OID это адрес, который используется для различения устройств в иерархии MIB. OID используется для ссылки на уникальные характеристики и навигации по переменным на подключенном устройстве. Значение этих идентификаторов варьируется от текста к числам и счетчикам. Существует два основных типа управляемых объектов:
Они часто изображаются в виде дерева. OID форматируется в виде строки чисел, как показано ниже:
1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3
Каждый из этих номеров предоставляет вам соответствующую информацию. Например:
OID почти всегда начинаются с одинаковой последовательности чисел; 1.3.6.1.4.1. Мы рассмотрим, что означают эти цифры, более подробно ниже:
В большинстве случаев OID будут предоставляться поставщиком, у которого вы приобрели устройство.
SNMP получает запросы и ловушки SNMP
В случае прерываний SNMP агент SNMP автоматически уведомляет диспетчер SNMP о значительном событии на устройстве. Ловушки важны, потому что они отправляются менеджеру SNMP без опроса. Следовательно, ловушки помогают держать пользователя в курсе изменений внутри устройства..
Без SNMP-ловушек устройства могут передавать данные только при опросе. Ловушки SNMP также используют MIB. Эти MIB имеют свои собственные условия оповещения, которые находятся внутри устройства. Системе мониторинга SNMP необходимо настроить эти MIB, иначе они не смогут получить доступ к прерываниям, отправленным устройством..
Как использовать MIB и OID
Как мы уже говорили выше, каждое сетевое устройство с поддержкой SNMP будет иметь свою собственную таблицу MIB со многими различными OID. В большинстве MIB так много OID, что было бы практически невозможно записать всю информацию. Вместо того, чтобы делать это вручную, вы должны использовать инструмент мониторинга сети, такой как Монитор производительности сети SolarWinds или Paessler PRTG Сетевой монитор.
Монитор производительности сети SolarWindsСкачать 30-дневную бесплатную пробную версию
Сетевой монитор Paessler PRTGСкачать 30-дневную бесплатную пробную версию
Инструменты мониторинга SNMP предназначены для сбора данных из MIB и OID для представления в удобном для понимания формате. Запросы на получение и прерывания SNMP предоставляют сетевым мониторам необработанные данные о производительности, которые затем преобразуются в графические дисплеи, диаграммы и графики. Таким образом, MIB и OID позволяют вам контролировать несколько устройств с поддержкой SNMP из одного централизованного местоположения..
MIB и написание собственных MIB
Одна из интересных вещей о MIB заключается в том, что Вы можете создавать свои собственные MIB. Когда вы покупаете новое устройство, вы не ограничены использованием MIB, которые поставляются из коробки. Тем не менее, чтобы создать свой собственный MIB вам нужно знать, какие объекты вы хотите включить в него. Вы можете записать это в виде списка. После того, как вы написали список объектов, вам нужно определить место MIB в более широкой иерархии OID..
MIB и OID: винтики в машине
Хотя предпосылка SNMP относительно проста, архитектура временами может быть обманчиво сложной. Важно помнить, что отношения SNMP Manager и SNMP Agent гарантируют, что пользователь может контролировать несколько устройств из одного места..
При загрузке инструмента сетевого мониторинга агенты SNMP отправляют данные со всей сети. Информация, которую вы видите на экране, подается из прерываний SNMP и запросов Get. Вы можете просматривать эти данные в форме графиков и диаграмм, но эти данные фактически записываются в MIB и идентифицируются с помощью OID..
Данные в MIB идентифицируются с помощью OID, поэтому сетевые мониторы могут получать точную информацию, которая им нужна. Без ID получить запросы было бы невозможно, потому что инструмент мониторинга не смог бы найти переменные в MIB. MIB и OID являются неотъемлемой частью архитектуры SNMP. Эти два компонента жизненно важны для того, чтобы вы могли контролировать сетевую инфраструктуру и выполнять диагностику.
Смотрите также: Руководство по UDP (протокол дейтаграмм пользователя)
Быстрое обнаружение поддерживаемых SNMP-устройством MIB-модулей
При внедрении систем мониторинга и управления IT-инфраструктурой часто приходится сталкиваться с «нестандартными» устройствами. Нередко про такое устройство наверняка известно только то, что оно поддерживает SNMP. Подключение его к проекту придется начать с ответа на вопрос о том, какую информацию о себе оно предоставляет. Обычно для этого проводится полный опрос устройства, и полученные данные анализируются на предмет выявления полезной информации… Но тут, как говорится, есть нюансы. В этой заметке я расскажу об одном таком — о разработанном нами алгоритме быстрого определения «поддерживаемых» устройством MIB-модулей.
Зачем это надо?
Данных на устройстве может быть довольно много. Например, маршрутизатор Cisco 2600, с которым я немного поэкспериментировал в процессе написания этой статьи, выдает более 12-ти тысяч значений. 
И, надо сказать, это далеко не предел.
В связи с этим возникает пара проблем: как в этой куче информационного богатства отыскать именно полезные/нужные данные, и как это сделать за разумное время?
Решение первой лежит на поверхности: в соответствии с древней стратегией «разделяй и властвуй» надо разбить все собранные значения на относительно небольшое количество категорий, каждую из которых оценить на предмет полезности. Ответ на вопрос «как и на какие категории разбивать данные?» в данном случае тоже достаточно очевиден — все (ну, или практически все) данные до нас рассортировали по MIB-модулям, куда обычно складывают описания логически связанных между собой элементов данных (переменных).
Стандартный способ разбиения SNMP-данных в AggreGate Network Manager — по MIB-модулям.
Таким образом, подзадача выделения нужной информации сводится к отображению полученных данных на MIB-модули (связь осуществляется по идентификатору переменной — OID-у).
Существует много инструментов, делающих что-то подобное. И все они (по крайней мере, все известные нам) выполняют полный опрос устройства.
Так, к примеру, работает утилита MIB Walk в составе Engineer’s Toolset от SolarWinds, которая ту же «киску» с моего компьютера опрашивает 3,5 – 4 минуты. Вроде бы, это и не так много. Но надо учесть, что это не самое «большое» устройство, и что доступно мне оно по слабо загруженной локальной сети. В условиях настоящего «боевого» проекта, где присутствует серьезный трафик, а устройство находится в другой сети, время полного опроса может вырасти на порядки. И пока идет такой опрос, специалист, в чьи обязанности входит подключение устройства, так или иначе отвлечется, что называется «потеряет контекст», и сюда придется добавить время на «возвращение к задаче» (что нередко оказывается значительным довеском). Надо также учесть, что таких устройств в серьезном проекте часто бывает много — в некоторых случаях нам приходилось изучать по 2 – 3 десятка устройств. В конечном итоге набегает значительная величина.
Так или иначе, но и наши собственные специалисты по внедрению систем мониторинга, и самостоятельно настраивающие систему пользователи в какой-то момент стали часто упоминать ожидание завершения полного опроса SNMP-устройств в качестве одного из факторов, существенно «тормозящих» работу. И пришлось изобретать способ, позволяющий сократить время бесполезного ожидания. В итоге, мы придумали и реализовали в своей системе следующий алгоритм.
Алгоритм быстрого обнаружения доступных на SNMP-устройстве MIB-модулей
Даны список MIB-модулей и SNMP-устройство
Требуется определить, «поддерживается» ли этим устройством каждый из данных MIB-модулей.
Такая формулировка сразу ставит вопрос: Что значит «MIB-модуль поддерживается устройством»?
MIB-модуль представляет собой описание некоторого набора SNMP-переменных. В свете этого логично звучит следующий ответ на вопрос: будем считать, что MIB-модуль поддерживается, если хотя бы одна описанная в нем переменная присутствует на устройстве.
Замечание: Есть небольшая сложность: одно и то же значение может быть описано в разных MIB-ах. Ниже мы это учтем.
Из данного определения напрямую вытекает идея оптимизации: если мы нашли на устройстве одну переменную из некоторого MIB-модуля, остальные переменные данного модуля можно исключить из опроса. Поскольку переменные MIB-модуля чаще всего идут довольно большими блоками, мы можем не просто заметно, а, как показывает практика, радикально сократить количество данных, которые нам нужно будет получить от устройства. За счет этого снизится и время опроса.
Таким образом, мы не «гуляем» (WALK) по устройству, а буквально несемся по нему большими скачками.
Помня о высокой «кучности» OID-ов в MIB-модуле, можно слегка улучшить алгоритм за счет предварительного «прореживания» исходного списка OID-ов: если некоторая последовательность OID-ов относится к одному MIB-модулю (или, в более общем случае, к одному множеству MIB-модулей), то нет смысла проверять их все — запрос GET_NEXT к первом из них в любом случае выдаст либо один из этой группы, либо покажет, что данный блок данных на устройстве отсутствует.
Результаты
На рисунках представлен результат обнаружения MIB-модулей на упомянутом выше маршрутизаторе Cisco.
Начало списка обнаруженных модулей:
А это — его последняя страница:
Как видим, обнаружено 64 MIB-модуля. Кстати, время работы алгоритма: 1–2 секунды.
На следующем скриншоте — результат обнаружения на «нестандартном» устройстве Hirschmann Railswitch RSB20.
Две последних записи представляют «кастомные» MIB-модули, поставляющиеся с этим устройством.
«Вживую» процесс обнаржения MIB-модулей на Hirschmann-е можно увидеть в нашем ролике про подключение нестандартных устройств (гурманов может заинтересовать англоязычная версия). Правда вся магия с MIB-ами остается за кадром и укладывается в двух–трех секундный отрезок, но зато станет понятен наш подход к работе с SNMP-устройствами.
Как читать MIB и OID
Общая информация
Знание протокола SNMP, предназначенного для управления и наблюдения за устройствами в сети, очень полезно при диагностики здоровья всей системы. С его помощью администратор может автоматизировать сбор статистики с ключевых узлов: коммутаторов, маршрутизаторов, компьютеров и других устройств поддерживающих этот протокол. В этой статье мы рассмотрим на примерах, как понимать и использовать ключевое понятие в SNMP протоколе — базу данных MIB.
Для начала кратко опишем некоторые важные термины протокола 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:
К сожалению, иногда команда не успевает вытащить все переменные, так как на некоторых устройствах их сильно много и защита от DOS атак срабатывает раньше, блокируя доступ на некоторое время. Поэтому данные иногда удобней получать частично, лишь для определённой ветки:
Однако, полученные цифровые значения часто не раскрывают своего предназначения, поэтому, возникает обратная задача: узнать какой OID у интересующего нас объекта. Для этого придётся изучать MIB устройства.
Так, для того чтобы узнать температуру в корпусе Intel Modular Server, возмём MIB описывающего параметры вентиляторов системы и делаем в нём поиск слова temperature, находим объект fanFruInletTemperature и смотрим его описание. Вот нужный нам фрагмент:
Строка в описании объекта fans
говорит о том, что описанный объект будет расширять объект (являться веткой в дереве объектов) chassis, имея в нём индекс 206, а следующий объект fanFruTable в свою очередь будет расширять объект fans, представляя в нём ветку с индексом 1, также fanFruEntry будет первой веткой у объекта fanFruTable. В параметрах fanFruEntry и содержится интересующий нас fanFruInletTemperature.
Запоминаем адрес ветки: 206.1.1, начиная от объекта chassis. Теперь ищем далее в файле описание объекта fanFruInletTemperature:
Видим, что его индекс=16. Таким образом, 206.1.1.16 — содержит список всех температурных датчиков возле вентиляторов системы и, соответственно, 206.1.1.16.1 — номер первого из них. Сколько их всего узнаем позже. Теперь выясним адрес объекта chassis, в котором находятся только что найденные нужные нам параметры. Так, сквозной поиск строки «chassis OBJECT-IDENTITY» по всем MIB файлам приводит нас к другому MIB’у:
где мы узнаём, что он содержится в объекте components. Далее сквозной поиск строки «components OBJECT-IDENTITY» (нужно учесть, что пробелов между словами может быть разное количество) даёт строчку:
Далее находим и остальное:
Записывая все полученные ID объектов получаем полный OID для температурных датчиков: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16
Теперь можно узнать их значения, заодно выяснив и их количество:
Для облегчения работы с MIB файлами существует множество программ как платных, так и бесплатных, в том числе и online. Любой поисковик на запрос MIB browser выдаст много полезных ссылок. Я пользуюсь NuDesign Visual MIBuilder.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Как читать MIB и OID
Содержание
Общая информация
Знание протокола SNMP, предназначенного для управления и наблюдения за устройствами в сети, очень полезно при диагностики здоровья всей системы. С его помощью администратор может автоматизировать сбор статистики с ключевых узлов: коммутаторов, маршрутизаторов, компьютеров и других устройств поддерживающих этот протокол. В этой статье мы рассмотрим на примерах, как понимать и использовать ключевое понятие в SNMP протоколе — базу данных MIB. [1]
Для начала кратко опишем некоторые важные термины протокола SNMP (Simple Network Managment Protocol):
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:
К сожалению, иногда команда не успевает вытащить все переменные, так как на некоторых устройствах их сильно много и защита от DOS атак срабатывает раньше, блокируя доступ на некоторое время. Поэтому данные иногда удобней получать частично, лишь для определённой ветки:
Однако, полученные цифровые значения часто не раскрывают своего предназначения, поэтому, возникает обратная задача: узнать какой OID у интересующего нас объекта. Для этого придётся изучать MIB устройства.
Так, для того чтобы узнать температуру в корпусе Intel Modular Server, возмём MIB описывающего параметры вентиляторов системы и делаем в нём поиск слова temperature, находим объект fanFruInletTemperature и смотрим его описание. Вот нужный нам фрагмент:
Строка в описании объекта fans
говорит о том, что описанный объект будет расширять объект (являться веткой в дереве объектов) chassis, имея в нём индекс 206, а следующий объект fanFruTable в свою очередь будет расширять объект fans, представляя в нём ветку с индексом 1, также fanFruEntry будет первой веткой у объекта fanFruTable. В параметрах fanFruEntry и содержится интересующий нас fanFruInletTemperature.
Запоминаем адрес ветки: 206.1.1, начиная от объекта chassis. Теперь ищем далее в файле описание объекта fanFruInletTemperature:
где мы узнаём, что он содержится в объекте components. Далее сквозной поиск строки «components OBJECT-IDENTITY» (нужно учесть, что пробелов между словами может быть разное количество) даёт строчку:
Далее находим и остальное:
Записывая все полученные ID объектов получаем полный OID для температурных датчиков: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16
Теперь можно узнать их значения, заодно выяснив и их количество:
По приведённому несложному алгоритму можно прочитать любой MIB, главное получить его, что, к сожалению, не всегда возможно.
Для облегчения работы с MIB файлами существует множество программ как платных, так и бесплатных, в том числе и on-line (см. раздел Ссылки). Любой поисковик на запрос MIB browser выдаст много полезных ссылок. Я пользуюсь iReasoning MIB Browser, но не потому, что он лучше других, а просто я попробовал его первым и он мне вполне понравился.
Теперь, зная как читать MIB’ы и OID’ы администратору будет легче использовать и донастраивать системы мониторинга здоровья системы, такие как Zabbix, MRTG, PRTG, Cacti и т.п.