Что такое snmp oid

SNMP MIBs и как их готовить

Доброго времени суток, читатель.

Предыстория

Установка MIBs

Стандартные

MIBs обычно распространяются в виде архива с пачкой файлов. Многие из них, составленные в iana и ietf, повторяются в каждом архиве, но передаются для совместимости.
Для работы в системе по умолчанию (конкретно для Debian) они должны лежать примерно в /usr/share/mibs
Для начала установим стандартные mibs в систему.

В файле конфигурации /etc/snmp/snmp.conf включить нужные. Пример:

mibs :ALL включает все, что не совсем хорошо. Рекомендую для каждого оборудования иметь папку с mib’ами, т.к. они могут отличаться из одной прошивки к другой.

Частный случай

После распаковки структура следующая:

Программное обеспечение

D-View

Net-SNMP

Возвращаюсь к тому, с чего начинал пост:
Мы скачали архив с MIBs и будем использовать утилиту snmptranslate из пакета Net-SNMP. Для удобства складываем все mibs в одну директорию, но это все равно не хватает:

Чтобы долго не мучатся скопируем недостающие файлы из mibs коммутатора des-3200 с опцией не перезаписывать существующие. И здесь мы уже получаем положительный результат:

Теперь, когда трансляция работает, можно вкусить всю прелесть иерархии OIDs. Для этого есть флаги:

Примеры использования

Можно просканировать все mibs и увидеть, что swL2macNotifyInfo есть и на других коммутаторах

Подводные камни D-Link

Здесь мы видим, что иерархия не сложилась до конца.
После исправления становится так:

Если не указать конкретный MIB, то получим ошибки в других mibs

Еще пример

Еще бонус в виде команды snmptable

Итого

В данный момент, я перевожу OID SNMP Traps с коммутаторов в понятный для оператора формат. Это послужит основой для системы регистрации событий на оборудовании. Использовать MIBs в приложении мы не собираемся по причине непереносимости и не универсальности. Думаю подавляющее большинство библиотек используют для трансляции OID системные базы MIBs и конфиг /etc/snmp/snmp.conf (их использует Net-SNMP, а библиотека обращется к последнему), а глобально включать эти модули MIBs мы не хотим. Эти данные можно использовать для экспериментов и добиться более универсального варианта по использованию MIBs, но для меня этого достаточно.

UPD:
Полезные ключи:
-TB ищет в MIBs Object Name по regexp
-On выводит Object ID
Примеры:

Источник

Объяснение 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 (протокол дейтаграмм пользователя)

Источник

Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.

Введение в протокол SNMP

Архитектура протокола SNMP

Сеть, использующая SNMP для управления содержит три основных компонента:

Давайте попытаемся рассмотреть обозначенные компоненты.

SNMP менеджер и SNMP агент

Итак, как я уже сказал, SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника (о полной структуре пакета SNMP опишу ниже). Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент таким образом предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.

SNMP PDU (или сообщения SNMP протокола)

Как видно, в зависимости от версии протокола, набор команд разный (например InformRequest и GetBulkRequest полноценно появился только во второй версии SNMP). Компонент SNMP MIB рассмотрим ниже.

Структура PDU

Рассмотрение структуры PDU не обязательно, но это поможет более глубоко понять логику работы SNMP. Все PDU (кроме Trap) состоят из определенного набора полей, в которые записывается необходимая информация:

Что данные поля обозначают:

При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):

В новых версиях SNMP содержимое Trap PDU может незначительно меняться, но в целом, смысл тот же.

Логика работы протокола SNMP

Рассмотрев основные единицы обмена SNMP, можно обсудить логику работы SNMP при выполнении данных запросов\ответов. Некоторые общие особенности работы протокола SNMP, которые стоит учитывать:

Логика работы SNMP при обмене PDU-единицами

(взято частично отсюда http://logic-bratsk.ru/brlug/snmp_my/):

При получении PDU GetRequest, SNMP агент действует по следующему алгоритму:

При получении PDU GetNextRequest, SNMP агент действует по следующему алгоритму:

При получении PDU SetRequest, SNMP агент действует по следующему алгоритму:

Логика работы SNMP в картинках

взято отсюда (http://www.manageengine.com/network-monitoring/what-is-snmp.html)

Обмен PDU GET⁄ GET NEXT⁄ GET BULK⁄ SET

Обмен PDU Trap или notification

SNMP MIB

Давайте попробуем понять MIB. Это совсем не люди в черном ) Как я уже сказал, это Management information base, то есть база набор управляющей информации. Каждый сетевой узел, имеющий на своем борту SNMP агента (читай – поддерживающий протокол SNMP) предоставляет свой набор данных, тот, который в него «вложили» программисты\разработчики при проектировании железки\программы. То есть в каждом сетевом устройстве с поддержкой SNMP имеется своя база MIB со строго обозначенным набором переменных. Каждая база MIB имеет древовидную структуру, каждый объект в которой характеризуется уникальным идентификатором объекта (Object Identifier, OID).

Каждая ветка MIB-иерархии оканчивается некоторой переменной (так же имеющей свой OID), содержащей в себе определенное значение, которое записывается в переменную SNMP агентом, работающем на хосте. Данное значение неким образом характеризует данный хост (например, содержит информацию об аптайме, загрузке сетевого интерфейса и мн.др. параметры).

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

Давайте рассмотрим типичное дерево MIB на рисунке:

Итак, структура OID в дереве MIB:

В вершине дерева – корень (точка), от которого ответвляются ветви. Во многих схемах приведены некоторые ветви верхнего уровня (например itu-t, iso\itu-t и другие ниже), но информации о их назначении я не нашел… Посему, нас интересует вертка iso (0), которая хранит в себе следующие значения до internet (1): iso.org.dod.internet, что соответствует числовому ID .1.3.6.1.

Данный раздел (iso.org.dod.internet) разветвляется на подразделы, которые в большинстве своем контролируются IANA и состоят (согласно RFC1155) из:

Далее, необходимо рассмотреть отдельным пунктом ветку 1.3.6.1.2 (iso.org.dod.internet.mgmt), состоящую из подветки mib-2 (1), а так же reserved(0), pib(2), http(9) и некоторых других. Стоит отметить, что в зависимости от версии протокола (SNMPv1 vs SNMPv2) на месте данной ветки могут быть «прилинкованы» разные поддеревья в целом имеющие примерно одинаковую структуру и одинаковые идентификаторы, но в более новой версии протокола – поддерево более расширено. (наверно, в этом и состоит несовместимость версий протокола…)

Итак iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1): данная ветка является базовой для большинства сетевых устройств и содержится практически в любом устройстве. Ветка поделена на базовые группы (которых на текущий момент более 170), характерные для любого сетевого оборудования. Давайте рассмотрим наиболее применяемые:

Отдельного абзаца так же достоин подраздел iso.org.dod.internet.private (1.3.6.1.4), содержащий в себе поддерево enterprise (1). Данная ветвь контролируется IANA и содержит в себе более 40000 поддеревьев (ознакомьтесь с актуальным списком http://www.iana.org/assignments/enterprise-numbers ). В данной ветке регистрируют свои поддеревья – производители оборудования. Вот пример ответвления:

Ниже структура аналогичная всем остальным разделам – древовидна. В каждом поддереве соответствующий производитель оборудования в праве сам регистрировать свои ветвления и переменные.

Безопасность протокола SNMP (или версии протокола SNMP)

В одной из вторых версий SNMP (SNMPv2p) была попытка реализовать аутентификацию на основе сторон (т.н.Party-based Security Model). Технология кроме аутентификации, так же поддерживала возможность шифрования трафика. Данная технология не прижилась, как «сложная и запутанная» ) и в данный момент не используется. После чего SNMP второй версии вернулась к Community-based Security и стала именоваться SNMPv2c и применяется по сей день. SNMPv2 была переписана чуть более чем полностью, в результате чего существенно повышено быстродействие протокола, безопасность.

Третья версия протокола (SNMPv3) была более удачно доработана и поддерживает как аутентификацию на основе имени пользователя (т.н. User-based Security Model), так и шифрование трафика. Хотя их можно и не использовать.

Версии протокола между собой не совместимы. Несовместимость заключается в разнице пакетов PDU, в наличии дополнительных команд в более новых версиях протокола (возможно, в других…). В RFC 2576 имеется некоторая информация, позволяющая организовать возможность совместного использования SNMPv1 и v2. Для этого есть 2 пути: 1. Использование прокси-агентов (агент преобразует PDU SNMPv2 в PDU SNMPv1), 2. Использование менеджера с поддержкой 2х версий (менеджер для каждого хоста должен помнить версию агента).

Принципы настройки протокола SNMP

Для того, чтобы SNMP менеджер мог работать с символьными именами OID (ASN.1 нотация), необходимо подсунуть ему соответствующие файлы SMI и MIB, хранящие соответствия символьной записи и цифровой. Для того чтобы SNMP менеджер мог взаимодействовать с каком-либо агентом, необходимо менеджеру указать на этого агента, для чего задать соответствующие настройки, например:

В большинстве реализаций менеджеров SNMP (в данном контексте, наверно, лучше сказать – систем управления сетью Network Management System) предоставлены некие возможности механизма автоматического обнаружения SNMP агентов. В большинстве случаев это сводится к выполнению по расписанию некоторого скрипта, запускаемого в определенный промежуток времени и опрашивающего заданный диапазон IP адресов.

SNMP в Linux

В большинстве дистрибутивов Linux для работы с SNMP используется пакет net-snmp (RedHat) и snmp + snmpd (в Debian в snmp лежит клиентская часть, а в snmpd – серверная часть), который позволяет использовать протокол SNMP посредством отправки и получения PDU. После установки пакета(ов) в linux появятся следующие инструменты (перечислены не все):

Основной и часто используемой из всех указанных команд, является snmpwalk. При указании данной команды, без OID она попытается получить все объекты из ветки iso.org.dod.internet.mgmt.mib-2. В ссылках ниже можно найти отличный сборник примеров использования данных программ.

SNMP в Debian

Политика лицензирования Debian определяет базы MIB, как несвободное ПО, поэтому они не расположены в свободных репозитоиях, а размещены в non-free репозиториях. Для того чтобы базы корректно установились, необходимо данный репозиторий прописать в /etc/apt/sources.list, например:

и установить пакет snmp-mibs-downloader. (в процессе установки данный пакет попытается получить mib-базы из интернета). Так, же, необходимо в /etc/snmp/snmp.conf закомментировать строку:

Маленький итог о SNMP

Итак, в статье я постарался как можно понятней рассказать о SNMP, чтобы применять эту технологию в сетях мониторинга. Подводя краткий итог протокол SNMP базируется на нескольких основных принципах:

Ссылки SNMP

Источники загрузки MIB файлов (каталоги MIB):

Источник

Для чего предназначен SNMP: руководство по NMS, MIB, OID, ловушкам и агентам

SNMP (Simple Network Management Protocol) представляет собой коммуникационный протокол, который позволяет отслеживать управляемые сетевые устройства, включая маршрутизаторы, коммутаторы, серверы, принтеры и другие устройства, которые включены через IP через единую систему управления / программное обеспечение.

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

Менеджер (NMS)

Компонент Manager — это просто часть программного обеспечения, которое установлено на компьютере (которое при объединении называется Network Management System), которое проверяет устройства в вашей сети, как часто вы указываете информацию.

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

Агенты

SNMP Agent — это часть программного обеспечения, которое поставляется вместе с сетевым устройством (маршрутизатором, коммутатором, сервером, Wi-Fi и т. Д.), Которое при включении и настройке выполняет всю тяжелую работу для Менеджера путем компиляции и хранения всех данных из своего данное устройство в базу данных (MIB).

Эта база данных правильно структурирована, чтобы программное обеспечение менеджера могло легко опросить информацию и даже отправить информацию Менеджеру, если произошла ошибка.

Какие номера портов используют SNMP?

Управляемые сетевые устройства

Управляемые сетевые устройства, в том числе маршрутизаторы, коммутаторы, Wi-Fi, серверы (Windows и другие), настольные ПК, ноутбуки, принтеры, UPS и т. Д., Имеют встроенное в них программное обеспечение агента, которое должно быть либо включено, либо настроено, либо просто настроено правильно для того, чтобы быть опрошены NMS.

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

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

Чтобы упростить MIB, подумайте об этом так: MIB-файлы — это набор Вопросов, которые Менеджер может спросить у агента. Агент просто собирает эти вопросы и сохраняет их локально и обслуживает их по NMS по запросу.

Упрощенный пример работы MIB: NMS спросит у сетевого устройства вопрос, в данном случае, что такое ответ на вопрос 2?

Агент управляемых сетевых устройств затем отвечает с ответом на вопрос 2. Чтобы еще больше разбить это, давайте построим еще один пример.

Скажем, мы хотим знать системное время работы устройства.

Распределение номера OID

OID, Object Identifier — это просто номер, составленный MIB, объектом интереса и экземпляром. Каждый идентификатор является уникальным для устройства, и при запросе будет предоставлена ​​информация о том, что было запрошено OID.

Существует два типа OID:

Скаляр — это экземпляр одного объекта — например, имя поставщика устройства. Может быть только одно имя поставщика, так что это будет скалярный OID.

С другой стороны, Tabular может иметь несколько результатов для своего OID — например, процессор Quad Core приведет к 4 различным значениям ЦП.

Ловушки

Ловушки используются, когда устройству необходимо предупредить программное обеспечение сетевого управления о событии без опроса. Ловушки гарантируют, что NMS получает информацию, если определенное событие происходит на устройстве, которое должно быть записано без предварительного опроса NMS.

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

MIB — это номер, который идентифицирует определенные характеристики или значения устройства, но если в системе управления сетью нет определенной MIB, которую отправляет ловушка сетевого устройства, нет способа интерпретировать, что такое MIB, и не будет записывать событие.

Версии (v1, v2c, v3)

Этот протокол прошел несколько пересмотров на протяжении многих лет, начиная с 1988 года, начиная с версии 1. Теперь мы до версии 3, но большинство систем управления сетью поддерживают все версии протокола.

Версия 1

Версия 1 была первой версией протокола, определенного в RFC 1155 и 1157. Эта версия является самой простой из 3-х версий протокола и является самой небезопасной из-за ее простой текстовой аутентификации.

Версия 2 (или 2c)

Версия 2 протокола была введена в 1993 году с большими улучшениями по сравнению с первой версией, включая транспортные сопоставления, элементы структуры MIB и, что самое важное, улучшенные обновления для проверки подлинности и безопасности.

Тем не менее, версии 1 и 2 / 2c имели встроенные риски безопасности, как упоминалось выше, — строки сообщества, которые эквивалентны паролям, где передается по проводу в виде прозрачного / обычного текста, позволяя любому, кто нюхает сеть, получить доступ к строке и могут компрометировать сетевые устройства и, возможно, перенастроить их с помощью SNMP.

Версия 3

Версия 3 протокола, дебютировавшая в 1998 году, сделала большие шаги для обеспечения безопасности набора протоколов, реализовав так называемую «пользовательскую безопасность». Эта функция безопасности позволяет вам устанавливать аутентификацию на основе требований пользователя. 3 уровня аутентификации:

Версия 3 протокола является наиболее безопасной из группы, но с добавленной безопасностью и шифрованием добавлена ​​конфигурация и сложность настройки и конфигурации. Но при работе с сетевыми устройствами более высокого уровня, которые содержат конфиденциальную информацию, вознаграждение перевешивает головную боль при правильной настройке.

Источник