Как узнать oid snmp

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

Источник

Управление и мониторинг сервера с помощью инструментов Net-SNMP

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

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

Читайте также:

Данное руководство научит вас работать с набором инструментов net-snmp.

Примечание: Подразумевается, что вы выполнили руководство Установка и настройка демона и клиента SNMP в Ubuntu 14.04.

Клиентские команды SNMP

Набор инструментов net-snmp содержит довольно много утилит, которые помогают выполнять запросы или настраивать значения OID на удаленных хостах. Большинство инструментов используют общий синтаксис и имеют схожие шаблоны использования. Рассмотрим основы некоторых наиболее популярных инструментов.

Примечание: Руководство подразумевает, что вы знакомы с командами аутентификации net-snmp. Все данные аутентификации в приведённых ниже командах обозначены как authentication_info.

В предыдущем руководстве вы создали файл snmp.conf с настройками клиента. Теперь его можно удалить: в этом руководстве вы научитесь добавлять данные аутентификации в конфигурационный файл.

Если у вас нет конфигурационного файла snmp.conf, замените authentication_info в каждой команде информацией для подключения к удалённому демону. Аккаунт demo использует следующие данные:

Примечание: Если вы используете другой аккаунт, не забудьте откорректировать учётные данные.

Извлечение значения OID с помощью SnmpGet

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

В базовом синтаксисе нужно указать известный числовой OID. К примеру, чтобы извлечь описание системы, нужно ввести:

snmpget authentication_info host 1.3.6.1.2.1.1.1.0

Поскольку в предыдущем руководстве на менеджер был установлен пакет snmp-mibs-downloader, вы также можете сослаться на OID по имени. К примеру, ту же информацию можно получить с помощью:

snmpget authentication_info host sysDescr.0

Извлечение следующего доступного OID с помощью SnmpGetNext

Эта команда извлекает значение OID, идущего после запрашиваемого OID. Иерархия MIB позволяет извлекать значения последовательно. Используя это свойство, вы можете получить значение (и метку OID) следующего объекта с помощью любого объекта в дереве.

Ранее вы получили описание системы. Теперь попробуйте узнать следующий OID и его значение. Для этого нужно использовать:

snmpgetnext authentication_info host sysDescr.0
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10

Эта команда вернёт ObjectID системы, который является следующим объектом в дереве. Эту команду можно обновлять, указывая полученный OID, и таким образом получать доступ к следующему объекту.

snmpgetnext authentication_info host sysObjectID.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (114216) 0:19:02.16

Извлечение раздела иерархии MIB с помощью SnmpWalk

С помощью команды snmpwalk можно получить доступ ко всем OID, которые подчиняются заданному OID. Эта команда выведет целое дерево, которое принадлежит указанной точке.

К примеру, чтобы получить все значения в точке system, нужно ввести:

Эта команда автоматически отправляет хосту запросы SNMP GetNext, пока не построит все дерево под запрашиваемым значением.

Чтобы вывести всё дерево MIB, выполните команду:

Она выведет всё доступное текущему пользователю дерево.

Эта команда в сочетании с grep позволяет искать OID по имени. Предположим, вы знаете, что OID с именем sysUpTime.0 выдает время работы SNMP на удалённых хостах, но вы также хотите узнать, как давно работает сам сервер.

Команда snmpwalk может вывести всю иерархию объектов OID, а затем grep отфильтрует их по слову «uptime» в имени. Флаг –i отключает чувствительность к регистру.

Проверив несколько из полученных значений вы обнаружите, что OID с именем hrSystemUptime.0 содержит нужное значение. Теперь вы можете использовать этот OID, чтобы узнать, как давно работает машина.

snmpget authentication_info host hrSystemUptime.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (9795352) 1 day, 3:12:33.52

Преобразование числовых OID в буквенные с помощью snmptranslate

Утилита snmptranslate – одна из самых полезных в наборе. Она никак не взаимодействует с удалённым хостом, она просто помогает получить необходимые сведения об иерархии MIB.

Утилита snmptranslate позволяет преобразовать числовые объекты в буквенные, и так получить их текстуальную репрезентацию.

snmptranslate 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0

Команда выдаёт модуль MIB, который определяет буквенное имя и имя самого OID.

Также эта утилита выполняет преобразование в обратном направлении. Возьмём, к примеру, MIB hrSystemUptime.0, который сообщает время работы системы. Попробуйте узнать, какое место этот объект занимает в дереве. Чтобы получить числовой адрес, нужно использовать флаг –On.

Укажите требуемый модуль MIB, чтобы получить информацию об OID:

Этот инструмент может предоставить множество другой информации о любой точке. К примеру, флаг –Td позволяет получить полное описание и путь.

Эти опции применимы и к некоторым другим инструментам набора.

Извлечение табличных данных с помощью SnmpTable

SNMP хранит и табличные данные. Команда snmpwalk может отобразить любые необходимые данные, однако она не всегда сохраняет форматирование.

К примеру, так snmpwalk покажет OID udpTable:

snmpwalk authentication_info host udpTable
UDP-MIB::udpLocalAddress.0.0.0.0.161 = IpAddress: 0.0.0.0
UDP-MIB::udpLocalAddress.0.0.0.0.35679 = IpAddress: 0.0.0.0
UDP-MIB::udpLocalPort.0.0.0.0.161 = INTEGER: 161
UDP-MIB::udpLocalPort.0.0.0.0.35679 = INTEGER: 35679

Теперь попробуйте отправить такой же запрос с помощью snmptable:

snmptable authentication_info host udpTable

Вы получите таблицу:

udpLocalAddress udpLocalPort
0.0.0.0 161
0.0.0.0 35679

С такими данными гораздо удобнее работать.

Изменение значений с помощью SnmpSet

Эта команда используется для записи значения в OID. Все предыдущие команды предназначены для получения информации, а эта команда используется для изменения данных на хосте.

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

snmpset authentication_info host OID_to_modify data_type new_value

Синтаксис довольно прост и понятен, но типы данных требуют более подробного объяснения. Каждый тип представлен одним символом. Доступны следующие типы данных:

Пакет snmp-mibs-downloader позволяет вставлять символ = вместо идентификатора типа.

Чтобы протестировать эту команду, закомментируйте одно значение в файле snmpd.conf на агенте. Жёсткое кодирование значений в файле делает их менее гибкими и не позволяет изменять их методами SNMP.

Откройте на агенте файл /etc/snmp/snmpd.conf:

sudo nano /etc/snmp/snmpd.conf

Закомментируйте директиву sysLocation:

#sysLocation Sitting on the Dock of the Bay

Сохраните и закройте файл. Перезапустите сервис.

sudo service snmpd restart

Перейдите на менеджер и установите Earth в качестве значения OID sysLocation. Параметр s задаёт тип данных (строки).

snmpset authentication_info host sysLocation.0 s «Earth»
SNMPv2-MIB::sysLocation.0 = STRING: Earth

Теперь проверьте, сможет ли спецификатор типа = правильно установить тип значения.

snmpset authentication_info host sysLocation.0 = «New York City»
SNMPv2-MIB::sysLocation.0 = STRING: New York City

Как видите, спецификатор = работает правильно.

Отправка запросов с помощью SnmpBulkGet и SnmpBulkWalk

При повторном запуске команд snmpget и snmpwalk можно создать большое количество сетевого трафика.

Команды snmpbulkget и snmpbulkwalk устраняют эту проблему; они собирают все возвращаемые значения в одну транзакцию вместо того, чтобы отправлять каждое значение OID в отдельной транзакции.

Передайте команде snmpbulkget один или несколько OID или веток, и вы получите пакет значений дополнительных OID.

snmpbulkget authentication_info host system
SNMPv2-MIB::sysDescr.0 = STRING: Linux target 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (429891) 1:11:38.91
SNMPv2-MIB::sysContact.0 = STRING: call now
SNMPv2-MIB::sysName.0 = STRING: target
SNMPv2-MIB::sysLocation.0 = STRING: New York City
SNMPv2-MIB::sysServices.0 = INTEGER: 72
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance

Команда snmpbulkget работает так же, как snmpgetnext. По сути, команда snmpbulkget – это команда snmpwalk, которая возвращает результат в одном пакете.

Команда snmpbulkwalk работает аналогичным образом, но продолжит выполнять BulkGet, пока не извлечёт все поддерево.

Заключение

Набор утилит net-snmp – надёжное и гибкое средство для извлечения и управления данных. С помощью этих утилит вы можете создать сложную среду для мониторинга и управления серверами.

Источник

Руководство по командам Net-SNMP

Mark Silinio
последнее обновление 21/04/05
Оригинал: silinio.webhost.ru

Что про что

Примечания по переводу:

Содержание:

snmptranslate: анализ OID’ов в MIB деревьях

snmpget: получение информации с удалённого хоста

snmpgetnext: получение информации следующего OID’а

Команда snmpgetnext похожа на snmpget, с тем лишь различием, что возвращает OID и его значение, следующее в MIB-дереве за тем, что указано в качестве аргумента:

Так, snmpgetnext может использоваться для последовательного просмотра OID’ов просто путём указания в аргументе последнего полученного OID’а:
Фактически команда snmpwalk, рассматриваемая ниже, делает то же самое за один раз!
В отличие от snmpget, snmpgetnext возвращает значение для OID’а, написанного без индекса(см. про snmpget выше). В таком случае с snmpgetnext не будет возникать ошибки, т.к. вы получаете значение следующей переменной независимо от того, указан ли индекс для переменной в аргументе команды:

snmpwalk: серия snmpnext комманд за раз

Команда snmpwalk автоматически выполняет серию snmpnext команд внутри заданного OID’ом диапазона. К примеру, если вы хотите получить всю информацию, хранящуюся в MIB группе system, используйте следующую команду:

snmptable: отображение SNMP-таблицы

Команда snmptable отображает SNMP таблицу в разбитом на колонки виде. Рассмотрим данные sysORTable. В отличие от команды snmpwalk, отображающей данные в виде длинного списка, snmptable форматирует вывод в удобном для чтения виде (иногда, как в примере ниже, вывод может быть весьма широк):

Но вы можете менять ширину выводимой таблицы:

snmpset: изменение OID’ов

Как вы могли видеть, мы успешно изменили значение OID’а ucdDemoPublicString.0.
Заметьте, что в случае, когда вы не имеете права на изменение(запись) объекта, сообщения об ошибке различны для SNMPv1 и SNMPv2c:

В SNMPv1 отсутствуют описания ошибок, но это исправлено в SNMPv2c. Весьма рекомендуется использовать SNMPv2c вместо SNMPv1, но ещё более лучшим вариантом будет SNMPv3 как в плане безопасности, так и в плане сообщений об ошибках,- SNMPv3 будет рассмотрен чуть позже.

snmptrap: посылка и принятие TRAP’ов, реагирование на них

При её получении snmptrapd выведет такой текст на экран: Формат INFORM’ов SNMPv2 отличен от формата TRAP’ов SNMPv1 и выглядит подобным образом: Это определение аналогично TRAP’у SNMPv1 что рассматривали выше. Так выглядит вызов INFORM’а SNMPv2:

получаем такой вывод от snmptrapd : и такой вывод нашей handler-программы:

вызов нашей enterprice specific TRAP’ы даёт такой вывод handler-программы:

Отправка и приём TRAP’ов и INFORM’ов для SNMPv3

TRAP’ы и INFORM’ы более гибки при использовании SNMPv3 благодаря отличной реализации базы пользователей. Сообщения SNMPv1 и SNMPv2c, использующие community-строки, выдают информацию любому пользователю. SNMPv3 отклоняет запрос, если пользователь отстутствует в базе пользователей SNMPv3. Всё просто, не так ли? За исключением одной небольшой проблемы: база пользователей приложения SNMPv3 описывает пользователей парой значений в виде имени пользователя(называемого «securityName») и идентификатора данного SNMP приложения, с которым осущевствляется связь(зовётся «engineID»). Обычно когда вы используете приложения Net-SNMP(snmpget, snmpwalk и пр.), они сами находят engineID и используют имя пользователя, engineID и пароль в базе пользователей на основе engineID удалённого приложения. Потом будет проще
SNMPv3 INFORM’ы

Вывод будет аналогичен предыдущему примеру.
Далее должно идти долгое объяснение про v3 engineID, INFORM’ы, TRAP’ы, обнаружение engineID, секретные ключи, пароли, локальные ключи и пр. Всё это безобразие занимает 18223 строк текста в RFC 2570-2575, потому не будем повторяться здесь.

Использование локальных MIB-файлов

Работает!
Ещё один момент: вы можете набрать эту команду другим способом(такой набор наиболее предпочтителен и рекомендуется ведущими разработчиками Net-SNMP):

Опции специфичные для SNMPv3

Рассмотрим детальнее вывод последней команды.
— Каждый пользователь имеет имя(securityName), тип аутентификации(authProtocol), тип privacy(privProtocol), а также ключи аутентификации(authKey) и privacy(privKey).
— Аутентификация происходит путём подписывания отправляемого сообщения с помощью authKey. authProtocol на сегодняшний день может быть MD5 или SHA, тогда как authKeys и privKeys генерируются из парольной фразы длиной не менее 8-ми символов
— Аутентификация происходит с применением пользовательского privKey для шифрования данных отсылаемого сообщения. privProtocol может быть AES или DES.
Сообщения могут быть отосланы неаутентифицированными, аутентифицированными, или аутентифицированными и зашифрованными в зависимости от значания securityLevel.
Таблица ниже описывает, как все эти значения могут быть указаны в командной строке. Вы также можете прописать значения по умолчанию в файл

Примеры
Пример запроса без аутентификации (как минимум, требуется указать имя пользователя):

Запрос с аутентификацией:

И наконец, запрос с аутентификацией и шифрованием:

Конечно же они все выглядят похоже т.к. работают подобным образом. Но хост в примерах выше позволял использовать любой уровень аутентификации. Хосты, что вы будете настраивать, должны иметь более жёсткие правила безопасности и иметь хотя бы authNoPriv уровень при настройке VACM контроля доступа. И в завершении, пропишем snmp.conf подобным образом: Таким образом все аргументы, используемые нами ранее в командной строке, будут автоматически браться из этого файла:

Опции влияющие на формат вывода

Несколько примеров использования этой возможности:

-On
Данный флаг позволяет выводить OID’ы в числовом формате вместо текстового:

-Oe
Этот флаг определяет, нужно ли показывать обяснение(перед числом в скобках) полученного числового значения:

-Ob
Многие SNMP таблицы используют в качестве индекса строки. Затем строки транслируются в OID сегменты для выполнения SNMP запроса. Давайте попробуем разобраться в этом на следующем примере. Рассморим OID usmUserEntry:

Источник

Zabbix Documentation 4.2

Sidebar

Table of Contents

3 Обнаружение SNMP OID’ов

Обзор

В этом разделе мы выполним обнаружение SNMP на коммутаторе.

Ключ элемента данных

Обнаружение SNMP OID’ов поддерживается начиная с Zabbix сервера/прокси 2.0.

Для настройки правила обнаружения, выполните следующее:

Все обязательные поля ввода отмечены красной звёздочкой.

OID’ы для обнаружения добавляются в поле SNMP OID в следующем формате: discovery[<#МАКРОС1>, oid1, <#МАКРОС2>, oid2, …,]

где , … допустимые имена низкоуровневых макросов и oid1, oid2. являются OID’ами способными сгенерировать осмысленные значения для этих макросов. Встроенный макрос содержит индекс обнаруженного OID, который применяется к обнаруженным объектам. Обнаруженные объекты группируются по значению макроса .

Для понимания того, что мы имеем в виду, давайте выполним несколько раз snmpwalk на нашем коммутаторе:

И зададим SNMP OID равным: discovery[<#IFDESCR>, ifDescr, <#IFPHYSADDRESS>, ifPhysAddress]

Теперь это правило будет обнаруживать объекты с макросом <#IFDESCR>равным WAN, LAN1 и LAN2, макросом <#IFPHYSADDRESS>равным 8:0:27:90:7a:75, 8:0:27:90:7a:76, и 8:0:27:2b:af:9e, макросом <#SNMPINDEX>равным индексам обнаруженных OID 1, 2 и 3:

Если обнаруженный объект не имеет указанный OID, тогда по этому объекту соответстующий макрос пропускается. Например, если у нас есть следующие данные:

Тогда, в случае SNMP обнаружения discovery[<#IFDESCR>, ifDescr, <#IFALIAS>, ifAlias] вернется следующая структура:

Прототипы элементов данных

Следующий скриншот иллюстрирует каким образом мы можем использовать эти макросы в прототипах элементов данных:

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

Прототипы триггеров

Следующий скриншот иллюстрирует каким образом мы можем использовать эти макросы в прототипах триггеров:

Прототипы графиков

Следующий скриншот иллюстрирует каким образом мы можем использовать эти макросы в прототипах графиков:

Результат нашего правила обнаружения:

Обнаруженные объекты

Когда сервер выполнит правило обнаружения, будут созданы реальные элементы данных, триггеры и графики на основе значений, которые вернет правило обнаружения SNMP. В настройках узла сети эти объекты будут иметь префикс с оранжевой ссылкой на правило обнаружения, с которого пришли эти объекты.

Источник