Linux interface snmp oid

Linux interface snmp oid

Linux OID’s
system: 1,3,6,1,2,1,1 sysDescr: 1,3,6,1,2,1,1,1
sysDescr_instance: 1,3,6,1,2,1,1,1,0
sysObjectID: 1,3,6,1,2,1,1,2
sysObjectID_instance: 1,3,6,1,2,1,1,2,0
sysUpTime: 1,3,6,1,2,1,1,3
sysUpTime_instance: 1,3,6,1,2,1,1,3,0
sysContact: 1,3,6,1,2,1,1,4
sysContact_instance: 1,3,6,1,2,1,1,4,0
sysName: 1,3,6,1,2,1,1,5
sysName_instance: 1,3,6,1,2,1,1,5,0
sysLocation: 1,3,6,1,2,1,1,6
sysLocation_instance: 1,3,6,1,2,1,1,6,0
sysServices: 1,3,6,1,2,1,1,7
sysServices_instance: 1,3,6,1,2,1,1,7,0
sysORLastChange: 1,3,6,1,2,1,1,8
sysORLastChange_instance: 1,3,6,1,2,1,1,8,0

Load CPU

1 minute Load: .1.3.6.1.4.1.2021.10.1.3.1
5 minute Load: .1.3.6.1.4.1.2021.10.1.3.2
15 minute Load: .1.3.6.1.4.1.2021.10.1.3.3

percentage of user CPU time: .1.3.6.1.4.1.2021.11.9.0
raw user cpu time: .1.3.6.1.4.1.2021.11.50.0
percentages of system CPU time: .1.3.6.1.4.1.2021.11.10.0
raw system cpu time: .1.3.6.1.4.1.2021.11.52.0
percentages of idle CPU time: .1.3.6.1.4.1.2021.11.11.0
raw idle cpu time: .1.3.6.1.4.1.2021.11.53.0
raw nice cpu time: .1.3.6.1.4.1.2021.11.51.0

Memory Statistics
Total Swap Size: .1.3.6.1.4.1.2021.4.3.0
Available Swap Space: .1.3.6.1.4.1.2021.4.4.0
Total RAM in machine: .1.3.6.1.4.1.2021.4.5.0
Total RAM used: .1.3.6.1.4.1.2021.4.6.0
Total RAM Free: .1.3.6.1.4.1.2021.4.11.0
Total RAM Shared: .1.3.6.1.4.1.2021.4.13.0
Total RAM Buffered: .1.3.6.1.4.1.2021.4.14.0
Total Cached Memory: .1.3.6.1.4.1.2021.4.15.0

Disk Statistics
Path where the disk is mounted: .1.3.6.1.4.1.2021.9.1.2.1

Path of the device for the partition: .1.3.6.1.4.1.2021.9.1.3.1
Total size of the disk/partion (kBytes): .1.3.6.1.4.1.2021.9.1.6.1
Available space on the disk: .1.3.6.1.4.1.2021.9.1.7.1
Used space on the disk: .1.3.6.1.4.1.2021.9.1.8.1
Percentage of space used on disk: .1.3.6.1.4.1.2021.9.1.9.1
Percentage of inodes used on disk: .1.3.6.1.4.1.2021.9.1.10.1

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

Выдать сколько свободного места в корневом катологе / на локальном компьютере .

#cd /etc/snmp/ #nano snmpd.conf

disk / 10000
(10 mb)

#snmpget -v 1 -c public target_name_or_ip .1.3.6.1.4.1.2021.9.1.7.1

UCD-SNMP-MIB::dskAvail.1 = INTEGER: 6831612

# df Filesystem 1K-blocks Used Available Use% Mounted on

/dev/mapper/ubuntu-root 9671608 2352576 6831608 26% /

varrun 231308 128 231180 1% /var/run

varlock 231308 0 231308 0% /var/lock

udev 231308 52 231256 1% /dev

devshm 231308 0 231308 0% /dev/shm

/dev/sda1 241116 45191 183477 20% /boot

# snmpwalk -v 1 -c public localhost .1.3.6.1.4.1.2021.9 UCD-SNMP-MIB::dskIndex.1 = INTEGER: 1 UCD-SNMP-MIB::dskPath.1 = STRING: / UCD-SNMP-MIB::dskDevice.1 = STRING: /dev/mapper/ubuntu-root UCD-SNMP-MIB::dskMinimum.1 = INTEGER: 10000 UCD-SNMP-MIB::dskMinPercent.1 = INTEGER: -1 UCD-SNMP-MIB::dskTotal.1 = INTEGER: 9671608 UCD-SNMP-MIB::dskAvail.1 = INTEGER: 6831596 UCD-SNMP-MIB::dskUsed.1 = INTEGER: 2352588 UCD-SNMP-MIB::dskPercent.1 = INTEGER: 26 UCD-SNMP-MIB::dskPercentNode.1 = INTEGER: 28 UCD-SNMP-MIB::dskErrorFlag.1 = INTEGER: noError(0) UCD-SNMP-MIB::dskErrorMsg.1 = STRING: #

Возможны проблемы с настройками демона snmpd файл /etc/snmpd.conf

netstat -an | grep 161 udp 0 0 127.0.0.1:161 0.0.0.0:*

snmpd слушет только локальный комьютер на порту 161 и не будет отвечать на запросы с удаленного хоста . Изменить данную ситуацию можно в файле /etc/default/snmpd

Источник

Linux SNMP: Simple Network Management Protocol:

Installing and using SNMP on Linux

Related YoLinux Tutorials:

SNMP or Simple Network Management Protocol, is a technology standard for alert messages (trap), monitoring (get), and configuring (set) network devices. SNMP comes in three varieties: v1, v2 and v3, of which v3 is the only version to be considered secure.

The variables associated with a network device configuration is defined in the Management Information Base, or MIB. The MIB is a collection of information for managing the network element and is comprised of managed objects identified by the Object Identifier (OID). Each OID is unique and identifies a special characteristic of the managed network device. SNMP is built upon a client (SNMP manager) — server (SNMP agent/network device) architecture pattern with a message schema defined by the MIB and sent over UDP port 161 (SNMP agent) and port 162 (SNMP manager). Each of the data values defined by the MIB are associated with an OID identified by a hierarchy of numbers separated by periods.

Installation:

  • CentOS/RedHat: sudo yum install net-snmp-utils net-snmp net-snmp-devel
    (RPMs also included with CentOS/RHEL 6 and 7 install DVDs)
  • Ubuntu: sudo apt-get install snmp snmpd snmp-mibs-downloader

Configure:

  • System file /etc/snmp/snmpd.conf
    This file default restricts access to localhost only.
  • User file

Start:

  • CentOS/RedHat:
    • sudo systemctl enable snmpd.service
    • sudo systemctl start snmpd.service
    • sudo systemctl status snmpd.service
  • Ubuntu:
    • sudo systemctl enable snmpd.service
    • sudo systemctl start snmpd.service
    • sudo systemctl status snmpd.service
  • snmpwalk -v 1 localhost -c public .1.3.6.1
  • snmpwalk -v 1 localhost -c public system

[Potential Pitfall] : open up the firewall rules:

  • Open firewall to everything (if using iptables): sudo iptables -F
    or
  • if using firewald: sudo firewall-cmd --permanent --new-service=snmp
    this command will add service to directory /etc/firewalld/services/

Note: Ports 161 and 162 need to be available. See /etc/services:

  • RHEL 7: snmpget -v 1 -c public localhost sysDescr.0 Ubuntu: snmpget -v 1 -c public localhost .1.3.6.1.2.1.1.1.0
  • RHEL 7: snmptranslate -Tp | less

MIB files have to be installed on your system so that it understands the schema hierarchy of the system you want to query.

net-snmp-config --default-mibs --default-mibdirs

Look in /usr/share/snmp/mibs/ for a full list of system MIB files.

  • Print table: snmptable -v 1 -c public localhost sysORTable
    (CentOS/RHEL only)
  • Print system uptime: snmpget -v 1 localhost -c public .1.3.6.1.2.1.1.3.0
  • Print CPU 15 minute load: snmpget -v 1 localhost -c public .1.3.6.1.4.1.2021.10.1.3.3
  • Command Description
    snmpcmd options and behavior common to most of the Net-SNMP command-line tools
    snmpwalk retrieve a subtree of management values using SNMP GETNEXT requests
    snmpget communicates with a network entity using SNMP GET requests
    snmpset communicates with a network entity using SNMP SET requests
    snmptrap sends an SNMP notification to a manager (also snmpinform)
    snmpgetnext communicates with a network entity using SNMP GETNEXT requests to get the next variable that is lexicographically «next» in the remote entity’s MIB
    snmptable retrieve an SNMP table and display it in tabular form
    snmpdelta Monitor delta differences in SNMP Counter values
    snmptest flexible SNMP application that can monitor and manage information on a network entity
    snmpdf display disk space usage on a network entity via SNMP
    snmpusm creates and maintains SNMPv3 users on a network entity
    snmpstatus retrieves a fixed set of management information from a network entity
    snmpnetstat display networking status and configuration information from a network entity via SNMP
    snmpbulkget SNMP application that uses the SNMP GETBULK request to query a network entity efficiently for information
    snmpbulkwalk retrieve a subtree of management values using SNMP GETBULK requests
    snmp.conf configuration files for the Net-SNMP applications
    SNMP Variables Format of specifying variable names to SNMP tools

    The Object Identifiers (OID)s are used to identify a specific characteristic of a managed device.

    There are two types of Managed OIDs:

    1. Scalar: managed object with a single instance (a single key to a key-value pair)
    2. Tabular: multiple data instances such as the rows of a table (e.g. CPU with multiple cores each with its’ own specific charateristics)

    SNMP uses ASN.1 (Abstract Syntax Notation One) to define the data types used to build an SNMP message and uses Basic Encoding Rules (BER) to define the data types.

    Two data types each with multiple sub-types:

    • Primitive Type: type/length(bytes)/data
      • integer
      • octet (byte, char)
      • string
      • null
      • boolean
      • OID
    • Complex Type: type/length/(type/length/data)(type/length/data)
      • sequence
      • SNMP PDU (Protocol Data Unit) — complex data types specific to SNMP
    OID Description
    CPU Statistics
    .1.3.6.1.4.1.2021.10.1.3.1 Load 1 minute
    .1.3.6.1.4.1.2021.10.1.3.2 Load 5 minute
    .1.3.6.1.4.1.2021.10.1.3.3 Load 15 minute
    .1.3.6.1.4.1.2021.11.9.0 percentage of user CPU time
    .1.3.6.1.4.1.2021.11.50.0 raw user cpu time
    .1.3.6.1.4.1.2021.11.10.0 percentages of system CPU time
    .1.3.6.1.4.1.2021.11.52.0 raw system cpu time
    .1.3.6.1.4.1.2021.11.11.0 percentages of idle CPU time
    .1.3.6.1.4.1.2021.11.53.0 raw idle cpu time
    .1.3.6.1.4.1.2021.11.51.0 raw nice cpu time
    Memory Statistics
    .1.3.6.1.4.1.2021.4.3.0 Total Swap Size
    .1.3.6.1.4.1.2021.4.4.0 Available Swap Space
    .1.3.6.1.4.1.2021.4.5.0 Total RAM in machine
    .1.3.6.1.4.1.2021.4.6.0 Total RAM used
    .1.3.6.1.4.1.2021.4.11.0 Total RAM Free
    .1.3.6.1.4.1.2021.4.13.0 Total RAM Shared
    .1.3.6.1.4.1.2021.4.14.0 Total RAM Buffered
    .1.3.6.1.4.1.2021.4.15.0 Total Cached Memory
    Disk Statistics
    .1.3.6.1.4.1.2021.9.1.2.1 Disk path where disk is mounted
    .1.3.6.1.4.1.2021.9.1.3.1 Path of the device for the partition
    .1.3.6.1.4.1.2021.9.1.6.1 Total size of the disk/partition (kBytes)
    .1.3.6.1.4.1.2021.9.1.7.1 Available space on the disk
    .1.3.6.1.4.1.2021.9.1.8.1 Used space on the disk
    .1.3.6.1.4.1.2021.9.1.9.1 Percentage of space used on disk
    .1.3.6.1.4.1.2021.9.1.10.1 Percentage of inodes used on disk
    System Statistics
    .1.3.6.1.2.1.1.3.0 System uptime
    .1.3.6.1.2.1.1.5.0 Host name

    Installation:

    • CentOS/RedHat: sudo yum install net-snmp-gui
      (uses EPEL repository)
    • Ubuntu: sudo apt-get install tkmib

    Run: tkmib localhost


    Select the «walk» button to traverse the OIDs.

    Источник

    Руководство по командам 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 . Команда вернёт только значение атрибута, что весьма удобно использовать в скриптах:

    Источник

    Читайте также:  Как заправить картридж kyocera p2040dn
    Поделиться с друзьями
    КомпСовет
    Adblock
    detector