какая команда используется для запроса одного или более параметров mib

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 действительно простым

Уже немало написано о том, что в названии Simple Network Management Protocol слово Simple можно смело писать в кавычках. Протокол SNMP является достаточно простым с точки зрения создания SNMP-агентов, однако на стороне управляющего ПО (SNMP manager) грамотная обработка сложных по структуре данных обычно является нетривиальной задачей.

Мы попытались упростить процесс настройки сбора данных и событий SNMP и позволить пользователям во время этого процесса:

Шаг 1: добавляем MIB-файлы

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

Модуль SNMP нашей системы AggreGate Network Manager при старте загружает все MIB-файлы, находящиеся в специальной папке сервера, после чего позволяет добавлять новые при помощи простого диалога:

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

Шаг 2: подключаем SNMP-устройство

В случае построения классической системы мониторинга этот шаг обычно не требуется, так как все устройства добавляются в систему автоматически во время периодического обнаружения устройств (network discovery). Тем не менее, во время добавления обнаруженных сканированием сети устройств выполняются примерно те же шаги:

Шаг 3: изучаем снимок устройства

После завершения этапа подключения устройства системе требуется от нескольких секунд до нескольких минут на завершение опроса устройства в рамках выбранных MIB-ов. Когда пиктограмма устройства становится зеленой, можно открывать и изучать так называемый «снимок устройства»:

В этом снимке сосредоточена практически вся суть нашего подхода к работе с данными SNMP. Прежде всего, он всегда содержит «под рукой» все реальные данные устройства. При этом все данные считываются только один раз, последующий опрос идет только по важным метрикам. Полное перечитывание снимка устройства производится раз в сутки, для снижения нагрузки на сеть его можно вообще отключить. Снимок устройства опционально сохраняется в БД при перезапуске системы мониторинга.

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

Чтобы посмотреть подробное описание любой метрики или таблицы, содержащееся в MIB-файле, достаточно навести мышкой на описание или значение метрики. Во всплывающей подсказке также виден тип данных SNMP и полный OID:

Если метрика может принимать одно из нескольких числовых значений, описанных в MIB-файле текстовыми константами, в снимке устройства сразу показывается соответствующая текущему значению константа. Полный список констант и их числовых значений доступен через контекстное меню:

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

Но наибольшую пользу наш метод работы с данными SNMP приносит при обработке таблиц. Каждая SNMP-таблица показывается в снимке устройств как отдельная метрика табличного типа:

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

При наведении на заголовок столбца во всплывающей подсказке видно описание поля, полученное из MIB-файла, а также его тип и OID:

Если имеется несколько связанных друг с другом таблиц, например использующих внешние индексы или расширение (augmentation), система автоматически обрабатывает все внутренние связи и сводит данные связанных таблиц в одно целое. В большинстве случаев пользователи даже не подозревают о существовании таких сложностей. Вот, например, как выглядит таблица hrSWRunPerfTable:

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

Поскольку единая модель данных платформы AggreGate ориентирована на работу с таблицами, таблицы данных SNMP являются идеальным кандидатом на обработку встроенными средствами. При помощи них реализуется построение топологии L2/L3, анализ данных MPLS TE и MPLS VPN, мониторинг и создание тестов IP SLA, а также сотни более простых задач.

Шаг 4: настраиваем периоды опроса и сроки хранения

AggreGate Network Manager является одновременно платформой и коробочным продуктом, поэтому в большинстве случаев после автоматического или ручного добавления устройства периоды опроса и сроки хранения метрик уже преднастроены для всех метрик и таблиц, которые система «понимает», т.е. показывает на инструментальных панелях и анализирует на предмет необходимости генерации тревожных сообщений.

Откорректировать настройки опроса (синхронизации) и хранения метрики можно через ее контекстное меню, либо через настройки аккаунта (для всех метрик сразу).

В диалоге настроек хранения показывается только срок хранения «сырых» данных в обычной базе данных (реляционной или NoSQL, в зависимости от настроек сервера). В большинстве случаев данные SNMP хранятся в кольцевой базе данных (Round-Robin Database, RRD), которая встроена в платформу AggreGate. На тему создания каналов статистики, которые перекладывают метрики и части таблиц в кольцевую БД, будет отдельная статья.

Шаг 5: переходим к обработке и визуализации данных

Когда данные собираются и сохраняются в БД сервера, можно приступать к их использованию для дела, то есть для мониторинга и управления ИТ инфраструктурой. Контекстное меню любой метрики в снимке устройства предоставляет доступ к визардам, позволяющим начать настройку тревог, отчетов, графиков, запросов, инструментальных панелей, и других средств анализа и визуализации.

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

В результате

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

При настройке мониторинга не требуется ручное указание названий MIB-ов, ввод OID-ов и других низкоуровневых идентификаторов. Это делает настройку SNMP-мониторинга достаточно быстрой и легкой.

Безусловно, нам еще есть над чем поработать. Требуется улучшение механизмов выбора индивидуальных метрик, чтобы избежать даже единократного опроса целых MIBов. Есть необходимость исключения из опроса индивидуальных строк и столбцов SNMP-таблиц. Нам интересно было бы услышать и о других недостатках процесса настройки SNMP-мониторинга в нашей системе.

А поподробнее?

Эта статья вообще не касается получения, обработки и отправки ловушек SNMP, работы по SNMP v3, и многих других аспектов.

Для более подробного рассказа мы приглашаем всех хабражителей на вебинар Мониторинг и управление по SNMP, который состоится 26 мая 2015 года в 11:00 по московскому времени. На этом вебинаре мы «вживую» продемонстрируем весь вышеописанный процесс, а также многие другие способы мониторинга сетевого, серверного и нестандартного оборудования при помощи 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:

Источник

Основы работы с SNMP

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

SNMP (simple network management protocol, простой протокол сетевого управления) – это стандартный протокол для управления устройствами в IP-сетях. С его помощью серверы могут обмениваться информацией о своем текущем состоянии, а администратор может изменять предварительно определенные значения. Сам протокол очень простой, однако структура основанных на нём программ может оказаться сложной.

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

Базовые понятия

Протокол SNMP реализуется на прикладном уровне сетевого стека. Протокол был разработан для согласованного сбора информации из самых разных систем. SNMP использует стандартизированные методы запроса информации и пути.

Существует много различных версий протокола SNMP. Кроме того, протокол частично реализуется некоторыми сетевыми аппаратными устройствами. Наиболее распространённой является версия SNMPv1, но она имеет много уязвимостей; на самом деле, основными причинами её популярности являются её вездесущность и долгое время существования. Вместо неё рекомендуется использовать более безопасную версию SNMPv3.

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

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

Менеджеры SNMP

Менеджер SNMP – это машина, которая запрашивает информацию, собранную агентами SNMP. Такая машина гораздо проще устроена, чем клиенты, поскольку она просто запрашивает данные.

Менеджером может быть любая машина, которая может отправлять запросы агентам SNMP, предоставляя валидные учётные данные (например, сервер мониторинга); иногда задачи менеджера выполняет сам администратор с помощью простых утилит для быстрого запроса данных.

Почти все команды SNMP предназначены для менеджера. Например:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest
Response

Кроме того, менеджер может отвечать на Trap и Response.

Агенты SNMP

Агенты SNMP выполняют основную работу. Они отвечают за сбор данных о локальной системе, их хранение в удобном для запросов формате, обновление БД management information base (или просто MIB).

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

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

Агенты SNMP отвечают на большинство команд протокола, среди которых:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest

Также он может отправлять сообщения Trap.

Кратко о MIB

Management Information Base, или MIB – пожалуй, самый сложный компонент системы SNMP. Это иерархическая глобально стандартизированная база данных, которая следует стандартам агентов и менеджеров системы.

Проще всего структуру MIB можно представить в виде перевёрнутого дерева. Каждая ветвь получает порядковый номер (начиная с 1) и уникальную для этого уровня иерархии строку.

Чтобы сослаться на определённый узел, нужно отследить к нему путь в базе. Идентификаторы узла (номера и строки) можно использовать как адрес. Каждый узел в иерархии обозначается точкой. Таким образом, адрес содержит ряд идентификационных строк или чисел, разделенных точками. Такой адрес называется идентификатором объекта (или OID).

MIB предоставляет стандартные ветки, которые может использовать любое устройство. Однако при внедрении SNMP в свое устройство вы можете создавать пользовательские ветки.

Все стандартные ветки принадлежат одной родительской структуре. Эта ветка определяет информацию для спецификации MIB-2 (это пересмотренный стандарт для совместимых устройств).

Базовый путь к этой ветке:

Примечание: По этой ссылке вы найдёте очень удобный ресурс для ознакомления с деревом MIB. Аналогичный инструмент представлен Cisco и называется SNMP Object Navigator. Также похожее дерево можно найти здесь.

Запрашивая информацию устройств, вы заметите, что большинство адресов начинается с 1.3.6.1.2.1.

Команды протокола SNMP

Отчасти протокол SNMP популярен благодаря простым командам. Он выполняет всего несколько операций, но они достаточно гибки.

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

Версии протокола

С момента выхода протокол SNMP прошел через множество изменений. Первая реализация SNMP, сейчас известная как SNMPv1, появилась в 1988 году и состояла из RFC 1065, RFC 1066 и RFC 1067. Эта версия до сих пор широко поддерживается, однако она имеет множество проблем с безопасностью (например, аутентификация в виде обычного текста), поэтому её использование крайне нежелательно, особенно это касается незащищенных сетей.

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

Поэтому появились дополнительные релизы версии 2, каждый из которых сохранил основную часть усовершенствований версии 2, но изменил модель безопасности. Версия SNMPv2c возобновила модель безопасности на основе сообществ (которая была использована в v1); это была самая популярная версия протокола v2. Другая реализация, SNMPv2u, основана на пользовательской модели безопасности, также не стала популярной.

В 1998 вышла третья версия SNMP (текущая). Она предлагает пользовательскую систему безопасности, которая позволяет устанавливать требования к аутентификации с помощью одной из этих моделей:

Кроме новых моделей аутентификации был реализован механизм контроля доступа, который управляет доступом пользователей к веткам. Версия 3 также может использовать протоколы безопасности SSH или TLS.

Источник