Команда snmp mib flash cache это что значит

Объяснение SNMP MIB и OID

Любой, кто знаком с сетями, слышал о Протокол SNMP. SNMP — это тип протокола, который позволяет администраторам контролировать состояние оборудования и программного обеспечения. Устройства с поддержкой SNMP можно контролировать удаленно с помощью инструментов мониторинга сети, чтобы отслеживать производительность и доступность. MIBs и OIDs некоторые из секретных ингредиентов этого важного протокола.

SNMP имеет несколько компонентов под поверхностью, которые позволяют передавать информацию о производительности обратно конечному пользователю. Агенты SNMP, SNMP менеджеры, MIBS, и OIDs все работают вместе, чтобы сделать эти переводы возможными. В этой статье мы рассмотрим, что такое MIBS и OID, и что они делают. Однако, прежде чем мы это сделаем, мы должны посмотреть, что такое SNMP.

Что такое SNMP?

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

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

Менеджер SNMP — это система, которая отвечает за связь с подключенными устройствами агента SNMP. Здесь находится ваше решение для мониторинга сети. Менеджер SNMP запрашивает агентов, получает ответы от агентов и устанавливает переменные агентов.

Отношения между менеджером SNMP и агентом SNMP основаны на сообщениях и командах. Эти сообщения бывают разных форм. Некоторые из сообщений, которыми обмениваются эти два компонента, перечислены ниже:

• ПОЛУЧИТЬ — Отправляется, когда менеджер SNMP пытается получить информацию из MIB, чтобы выяснить значение переменной.
• ОТВЕТ — Агент отправляет RESPONSE менеджеру SNMP при ответе на запрос GET. Это предоставляет менеджеру SNMP переменные, которые были запрошены изначально.
• GetNext — Менеджер SNMP отправляет это сообщение агенту для получения информации от следующего OID в дереве MIB..
• GetBulk — Агент SNMP использует сообщение GETBULK для извлечения таблиц данных, используя множество различных команд GETNEXT.
• УСТАНАВЛИВАТЬ — SET — это сообщение, отправляемое менеджером SNMP агенту для изменения конфигурации и выдачи команд.
• TRAP — Оповещение, отправленное агентом SNMP, чтобы уведомить SNMP Manager, когда событие происходит в устройстве.

Смотрите также: SNMP объяснил

Что такое MIB?

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

Ресурсы, хранящиеся в MIB, называются управляемыми объектами или переменными управления. Самый простой способ думать о MIB — это центральный центр данных внутри устройства. MIB содержит все данные о производительности, которые доступны при загрузке инструмента мониторинга сети.

Что такое OID?

Внутри MIB есть много различных управляемых объектов, которые могут быть идентифицированы OID или Идентификатор объекта. OID это адрес, который используется для различения устройств в иерархии MIB. OID используется для ссылки на уникальные характеристики и навигации по переменным на подключенном устройстве. Значение этих идентификаторов варьируется от текста к числам и счетчикам. Существует два основных типа управляемых объектов:

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

Они часто изображаются в виде дерева. OID форматируется в виде строки чисел, как показано ниже:

1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3

Каждый из этих номеров предоставляет вам соответствующую информацию. Например:

Изо (1)
.org (3)
.dod (6)
.internet (1)
.private (4)
. переход (868)
.продукты (2)
.шасси (4)
.card (1)
.slotCps (2)
.cpsSlotSummary (1)
.cpsModuleTable (1)
.cpsModuleEntry (1)
.cpsModuleModel (3) .3562.3

OID почти всегда начинаются с одинаковой последовательности чисел; 1.3.6.1.4.1. Мы рассмотрим, что означают эти цифры, более подробно ниже:

1 iso — ISO это имя группы, которая запустила стандарт OID
.3 org — организация, указанная рядом с этой цифрой
.6 dod — Министерство обороны США
.1 интернет — определяет, что общение будет происходить через интернет
.4 private — указывает, что устройство изготовлено частной компанией
.1 предприятие — утверждает, что производитель является предприятием

В большинстве случаев OID будут предоставляться поставщиком, у которого вы приобрели устройство.

SNMP получает запросы и ловушки SNMP

Извлечение данных с устройств с SNMP может быть выполнено одним из двух способов; с SNMP Получить запрос или SNMP Trap. Запрос на получение SNMP — это когда пользователь запрашивает данные о производительности устройства. Как только агент SNMP получает этот запрос, он отправляет обратно OID, которые могут быть прочитаны системой мониторинга 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 должен иметь свое собственное место в дереве, где он не будет сталкиваться с любым существующим MIB. Лучший способ написать MIB — использовать существующий MIB в качестве шаблона. Изменение имен и определений в MIB дает пользователю прочную основу для продвижения вперед. Если вы решите пойти по этому пути, рекомендуется выполнить его через проверку синтаксиса MIB, чтобы убедиться, что он работает..

MIB и OID: винтики в машине

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

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

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

Смотрите также: Руководство по UDP (протокол дейтаграмм пользователя)

Источник

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

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

Что про что

Данный материал представляет собой перевод Net-SNMP Tutorial — Commands программы Net-SNMP использующейся для работы с протоколом SNMP во многих UNIX системах, включая Linux и *BSD. В конце перевода приводятся некоторые советы и полезные ссылки.

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

Содержание:

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

Утилита snmptranslate позволяет с командной строки изучать MIB-деревья.
В самом простом случае, она принимает в качестве аргумента OID и выводит его тестовое описание: Возможно также обратное преобразование, для этого необходимо только добавить опцию -On Заметьте, что аргумент, передаваемый программе, может описывать OID в любом виде, и опция -On влияет только на вывод ( -O , от слова Output): Хотите узнать полное значение OID? Используйте опцию -Of: Проблема с вышеупомянутой командой в том, что вам необходимо помнить весь OID, который вы хотите использовать в аргументе.
Ничего страшного, используйте опцию -IR ( -I , от слова Input) для поиска по всему MIB-дереву: С помощью опции -Ib возможен поиск по MIB-дереву с использованием регулярных выражений: Чтобы получить весь список найденных по регулярному выражению значений, используйте опцию -TB : Получить дополнительную информацию о MIB-узлем можно с -Td (description) опцией: И наконец, если вы хотите получить аккуратную диаграмму секции MIB-дерева, используйте -Tp опцию: Запустив snmptranslate -Tp без каких-либо аргументов, можно получить всё MIB-дерево целиком.

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

Команда snmpget используется для чтения информации с устройства, заданного по его имени(host name), аутентификационной информации и OID. Пример: В приведённом примере test.net-snmp.org — это имя хоста с которого мы получаем данные, используя SNMP общество(community string) demopublic и запрашиваем значение OID’а system.sysUpTime.0.
Ранние версии утилит ucd-snmp использовали по умолчанию SNMPv1 и community name следовало за именем хоста. Текущие версии net-snmp используют по-умолчанию SNMPv3 и требуют как номер версии, так и community string в опциях коммандной строки. SNMPv2, по сути подобен SNMPv1, но с небольшими модификациями, и так же использует передачу community names в качестве паролей в виде открытого текста. Результат команды, использующей SNMPv2c, будет аналогичным: Все утилиты(кроме snmptranslate) позволяют использовать сокращения OID’ов и производят поиск по всему MIB дереву, так что вы можете указать только часть OID’а: Частой ошибкой является указание команде snmpget OID’а без индекса. В приведённом примере значение запрашиваемое по OID’у является скаляром, и индекс скаляра всегда равен ‘0’(нулю). Необходимо добавление ‘.0’ в конец OID’а, в противном случае произойдёт ошибка. Заметьте, что сообщения об ошибке несколько различны для SNMPv1 и SNMPv2c: Возможно получение значений нескольких OID’ов одной командой:

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’ов

Команда snmpset используется для изменения данных на удалённом хосте/устройстве. Для каждой переменной, что вам необходимо изменить, необходимо указать OID, тип данных и само значение.
Вы можете увидеть поддерживаемые типы данных в конце вывода команды snmpset, запущенной с ключом -h :
Для примера проверим, а затем изменим значение OID’а, используя snmpget и snmpset:

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

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

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

TRAP’ы(ловушки) могут использоваться для уведомления станции управления о каких-либо неполадках.
Далее мы рассмотрим определение TRAP’ов в MIB-файлах, создание их с помощью утилиты snmptrap , и приём утилитой snmptrapd .
Примечание: как уже было отмечено, запись OID’а использует нотацию типа МОДУЛЬ::идентификатор, что используется в нижеприведённых примерах, а вывод команды snmptrapd подразумевает использование опции -OS.
Определение TRAP’ов.
TRAP’ы SNMPv1 и SNMPv2(INFORM’ы) используют два совершенно разных вида определений.
TRAP’ы SNMPv1 определяются в MIB файле используя макроопределение TRAP-TYPE, как в следующем примере: Так мы определили одну enterprice-специфичную TRAP, которая может быть вызвана следующим образом:

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

А так — вывод snmptrapd при получении INFORM’а: Определение действий при приёме TRAP’ов и INFORM’ов.
Утилита snmptrapd имеет возможность выполнять другие программы в случае получения ловушки-уведомления. Этим управляет директива traphandle, имеющая следующий синтаксис: Заметьте, что в качестве информации о том, какая TRAP(или INFORM) будет получена, используется OID. Это подразумевает под собой необходимость представления ловушек SNMPv1 в формате SNMPv2, что описано в RFC 2089. Обычно OID для описанной выше TRAP создаётся путём взятия ENTERPRICE параметра и добавления к нему под-идентификаторов 0 и 17. Значения OID’а для SNMPv1 TRAP’ов определяются аналогично SNMPv2.
Команда определят название программы, запускаемой при получении TRAP демоном snmptrapd . Программа получает данные TRAP на стандартный ввод. Первая строка — это имя хоста, вторая — IP-адрес отправителя TRAP, и последующие линии содержат пары значений OID ЗНАЧЕНИЕ с данными из полученной TRAP.
Пример shell-скрипта, вызываемого snmptrapd : Далее используем следующий snmptrapd.conf файл: И имитируем отключение сетевого интерфейса с помощью snmptrap :

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

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

и напоследок — наш enterprice specific INFORM:

Генерация TRAP’ов агентом
Агент также способен посылать TRAP’ы. При запуске генерируется TRAP SNMPv2-MIB::coldStart, а при выключении UCD-SNMP-MIB::ucdShutDown
Эти TRAP’ы отправляются хостам, определённым в snmpd.conf файле с помощью директив trapsink и trap2sink (для SNMPv1 и SNMPv2 соответственно) Дополнительно агент может отсылать TRAP’ы в случае неудавшейся аутентификации хостам, указанным директивой authtrapenable файла snmpd.conf , или путём активации переменной SNMPv2-MIB::snmpEnableAuthenTraps:

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

Основные отличия между TRAP’ами и INFORM’ами: TRAP — это SNMP сообщение, отправленное одним приложением другому приложению(обычно это удалённый хост). Их основная задача состоит в уведомлении о случившемся. Недостатком TRAP’ов является отстутствие возможности получения подтверждения о том, что TRAP был принят удалённым хостом. SNMPv2 PDU исправляют эту ситуацию, введя понятие INFORM, которое представляет собой тот же самый TRAP, но с подтверждением. Таким образом, если приложение на удалённом хосте получает INFORM, то оно отправляет в ответ подтверждение о получении. Следовательно можно быть наверняка уверенным в том, что необходимое уведомление доставлено. С помощью команды snmptrap возможна отправка как TRAP’ов, так и INFROM’ов, в последнем случае нужно добавить опцию -Ci (либо использовать команду snmpinform ). Обратите внимание, что для отпраки INFORM’ов нужно использовать SNMPv2c или SNMPv3. Программа snmptrapd способна принимать как INFORM’ы, так и TRAP’ы.
Примечание: Для того, чтобы программа snmptrapd успешно принимала TRAP’ы и INFORM’ы SNMPv3, отправленные определённым пользователем, тот должен быть правильно настроен, используя директивы createUser , рассматриваемые ниже. Если запустить snmptrapd с опцией -Dusm , то в таких случаях будет выведено сообщение «no such user». SNMPv3, пользователи и engineID’ы

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

INFORM’ы работают по схожему принципу. Для отсылки INFORM’a используйте удалённый engineID, который должен находиться в удалённой базе пользователей вместе с securityName. Программа snmptrap (и не только) отыскивает удалённый engineID и выбирает необходимого в данном случае пользователя(securityName). Итак, всё, что вам необходимо сделать, это создать в базе пользователей программы snmptrapd (подразумевается, что вы настраиваете получение TRAP’ов и INFORM’ов) необходимые учётные записи:

1. Остановите запущённую snmptrapd
2. Добавьте в /var/net-snmp/snmptrapd.conf следующую строку:
3. Где myuser это securityName, mypassword — это пароль для аутентификации, а myotherpassword — это пароль для шифрования(оставьте его пустым, если не хотите менять или не хотите использовать шифрование)
4. Перезапустите программу snmptrapd

Теперь вы можете использовать snmpinform для отсылки snmptrapd INFORM’а coldStart:

Если вы сделали всё правильно, то должны увидеть подобное от snmptrapd : TRAP’ы SNMPv3
Использование TRAP’ов SNMPv3 порою может несколько запутать, но даёт хорошее понимание работы протокола, если вы немного поразмыслите об этом. Отличие TRAP’ов SNMPv3 в использовании engineID локального приложения, отсылающего TRAP вместо engineID удалённого приложения. Это значит, что вы должны создать необходимых пользователей в вашей удалённой базе,- по одному для каждого engineID, с которого вы хотите отсылать TRAP’ы. Если у вас 100 SNMP агентов отсылают TRAP’ы SNMPv3 на ваш TRAP-приёмник, то вы должны будете создать 100 записей createUser в конфигурационном файле /var/net-snmp/snmptrapd.conf .
Итак, проверьте следующее:

1. Остановите snmptrapd
2. вставьте в файл /var/net-snmp/snmptrapd.conf следующую строку:
3. Заметьте, что значение engineID пользователя явно задано как 0x0102030405(это не рекомендуется, но в действительности не имеет значения)
4. (пере)запустите snmptrapd .

Теперь вы имеете возможность отправить с помощью snmptrap coldStart v3 TRAP сообщение TRAP-демону:

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

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

Утилиты Net-SNMP могут производить преобразование цифровых OID’ов в текстовые используя файлы-описания MIB’ов. В комплекте уже идёт набор из нескольких стандартных MIB’ов, но во многих случаях этого недостраточно.
Утилиты Net-SNMP загружают MIB’ы по-умолчанию из следующих двух директорий:

1. $HOME/.snmp/mibs
2. /usr/local/share/snmp/mibs

К примеру, у вас есть MIB, которую вы хотите использовать и которая называется CISCO-RHINO-MIB (такая действительно есть). Поместите эту MIB в одну из вышеперечисленных директорий. Если вы взяли MIB из какого-либо файла(как RFC например), убедитесь, что убрали оттуда все данные, не относящиеся к MIB(заглавный текст, разделители страниц). Первая строка файла должна начинаться с текста типа «CISCO-RHINO-MIB DEFINITIONS ::= BEGIN»
Попробуем преобразовать в цифровой вид имя узла из CISCO-RHINO-MIB, пусть это будет cicsoLS1010ChassisFanLed.
Убедимся, что snmptranslate ничего не выдаст нам о таком узле:

Ага, она не знает. Теперь мы должны скачать файл CISCO-RHINO-MIB.mib и поместить его в директорию, где он будет найден утилитами Net-SNMP. Скопируем его в $HOME/.snmp/mibs .
Воспользуемся флагом -m команды snmptranslate для загрузки MIB’а. Использование опции » -m +CISCO-RHINO-MIB указывает на загрузку не только MIB’ов, использующихся по-умолчанию, но также и на загрузку CISCO-RHINO-MIB(знак ‘+’ означает «добавить»).

Опа. Из первой строки можно увидеть, что нам также необходим CISCO-SMI MIB. Скачиваем его и копируем в $HOME/.snmp/mibs . Выполняем команду повторно:

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

Вас наверняка интересует, как сделать, чтобы нужные MIB’ы автоматически подгружались утилитами Net-SNMP без их явного указания в командной строке. Есть несколько путей сделать это.
Примечание пользователям программы Ethereal: Один из этих методов годится и для Ethereal, т.к. тот не имеет возможности подгружать нужные MIB’ы используя опции -m и -M , что мы рассматривали выше.
В первую очередь вы можете поместить следующие строки в файл snmp.conf . Этот файл может быть помещён как в системный конфигурационный файл Net-SNMP(напр. /usr/local/share/snmp.conf ), так и в персональный( $HOME/.snmp/snmp.conf ): Для указания нужных MIB’ов можно также использовать переменную окружения с названием MIBS(далее пример для оболочки /bin/sh ):

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

3-я версия протокола SNMP имеет значительные улучшения по части безопасности в сравнении с предыдущими версиями. Так, SNMPv1 и SNMPv2c используют для аутентификации community-строку отсылаемую открытым текстом. Такой вид аутентификации весьма небезопасен, т.к. может быть легко перехвачен сниффером.
SNMPv3 значительно улучшена по части безопасности и разделяет аутентификацию и авторизицию на следующие две части:

• USM — User-based Security Module, содежит список пользователей и их атрибутов. USM описан в RFC 2574.
• VACM — Version-based Access Control Module, контроллирует доступ пользователей(так и SNMPv1/v2c communities), в т.ч. доступ к определённым секциям MIB-дерева. VACM описан в RFC 2575.

Рассмотрим пример использования Net-SNMP для изменения(set) данных на удалённом хосте.
Профиль пользователя содержит следующие данные:

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

/.snmp/snmp.conf , используя третью колонку таблицы.

Параметр Опция коммандной строки Обозначение в snmp.conf securityName -u NAME defSecurityName NAME authProtocol -a (MD5|SHA) defAuthType (MD5|SHA) privProtocol -x (AES|DES) defPrivType DES authKey -A PASSPHRASE defAuthPassphrase PASSPHRASE privKey -X PASSPHRASE defPrivPassphrase PASSPHRASE securityLevel -l (noAuthNoPriv|authNoPriv|authPriv) defSecurityLevel (noAuthNoPriv|authNoPriv|authPriv) context -n CONTEXTNAME defContext CONTEXTNAME

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

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

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

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

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

Все команды пакета Net-SNMP, за исключением snmptrapd и snmpd , могут использовать опции которые мы рассмотрим ниже.
Для получения списка всех опций запустите программу с опцией » -h «. С помощью флага -O , передаваемого в качестве опции командам Net-SNMP, можно изменять формат вывода:

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

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

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

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

Как видите, usmUserEntry использует в качестве индексов два строковых значения: usmUserEngineID и usmUserName. По умолчанию команды Net-SNMP используют вывод, наиболее понятный для человека: Видим два OID’а: значение одного — «. «, другого — «MD5User». Первое строковое значение представляет собой engineID, которое состоит из непечатных символов(отсюда и многоточие), второе же — представляет собой как раз строку, которую мы безо всяких проблем можем прочесть. Немного подумав, пробуем просмотреть индексы в числовом виде: Как видите, OID’ы — это не просто строковое значение, порою всё несколько сложнее.
При использовании строковых значений в командах Net-SNMP перед кавычками ставятся обратные слэши, как того требует большинство оболочек:
-OX
Использование этой опции является куда более лучшим методом отображения значений индексов. Обратите внимание, что такой формат используется только при выводе.
Значения, возвращаемые MIB’ами IPv6, бывает довольно сложно прочесть, формат весьма запутан по сравнению с теми значениями, что вы могли видеть.
Рассмотрим IPV6-MIB:ipv6RouteTable: видим: в качестве индекса используется IPv6 адрес и два чиловых(integer) значения. Посмотрим на это: да, не так уж легко разобраться. Тогда попробуем так: Выглядит приятнее. Такой формат выделяет квадратными скобками каждый индекс, и использует информацию DISPLAY-HINT и преобразование строк для их правильного отображения.

-Os , -OS , и -Of
Сократить вывод слишком длинных OID’ов можно с помощью опции -Os и -OS ( -OS добавляет название MIB’а перед OID’ом): Намного короче, как видите отображается только последний узел OID’а.
Опция же -Of , напротив, выводит полный OID:
-Ov
Флаг -Ov выводит только значение, но не название переменной:
-Oq
Флаг -Oq обеспечивает наиболее быстрый(q — quick) вывод, что может быть полезно в случае использования команд Net-SNMP в различных скриптах: Заметьте, что в таком формате отсутствует знак равенства и символы «OID:» спереди.
Разумеется, вы можете комбинировать разные опции: Для shell-скриптов будет полезна опция -Oqv . Команда вернёт только значение атрибута, что весьма удобно использовать в скриптах:

Источник