| Каталог документации / Раздел "Сети, протоколы, сервисы" | (Архив | Для печати) |
| ||
|
Mark Silinio <silinio(at)mail.ru>
последнее обновление 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, как в следующем примере:
TRAP-TEST-MIB DEFINITIONS ::= BEGIN
IMPORTS ucdExperimental FROM UCD-SNMP-MIB;
demotraps OBJECT IDENTIFIER ::= { ucdExperimental 990 }
demo-trap TRAP-TYPE
STATUS current
ENTERPRISE demotraps
VARIABLES { sysLocation }
DESCRIPTION "This is just a demo"
::= 17
END
Так мы определили одну enterprice-специфичную TRAP, которая может быть вызвана следующим образом:
При её получении snmptrapd выведет такой текст на экран:
1999-11-12 23:26:07 localhost [127.0.0.1] TRAP-TEST-MIB::demotraps:
Enterprise Specific Trap (demo-trap) Uptime: 1 day, 5:34:06
SNMPv2-MIB::sysLocation.0 = "Just here"
Формат INFORM'ов SNMPv2 отличен от формата TRAP'ов SNMPv1 и выглядит подобным образом:
NOTIFICATION-TEST-MIB DEFINITIONS ::= BEGIN
IMPORTS ucdavis FROM UCD-SNMP-MIB;
demonotifs OBJECT IDENTIFIER ::= { ucdavis 991 }
demo-notif NOTIFICATION-TYPE
STATUS current
OBJECTS { sysLocation }
DESCRIPTION "Just a test notification"
::= { demonotifs 17 }
END
Это определение аналогично TRAP'у SNMPv1 что рассматривали выше. Так выглядит вызов INFORM'а SNMPv2:
А так - вывод snmptrapd при получении INFORM'а:
1999-11-13 08:31:33 localhost [127.0.0.1]:
SNMPv2-MIB::sysUpTime.0 = Timeticks: (13917129) 1 day, 14:39:31.29
SNMPv2-MIB::snmpTrapOID.0 = OID: NOTIFICATION-TEST-MIB::demo-notif
SNMPv2-MIB::sysLocation.0 = "just here"
Определение действий при приёме TRAP'ов и INFORM'ов.
Утилита snmptrapd имеет возможность выполнять другие программы в случае получения ловушки-уведомления. Этим управляет директива traphandle, имеющая следующий синтаксис: traphandle OID командаЗаметьте, что в качестве информации о том, какая 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:
#!/bin/sh
read host
read ip
vars=
while read oid val
do
if [ "$vars" = "" ]
then
vars="$oid = $val"
else
vars="$vars, $oid = $val"
fi
done
echo trap: $1 $host $ip $vars
Далее используем следующий snmptrapd.conf файл:
# the generic traps traphandle SNMPv2-MIB::coldStart /home/nba/bin/traps cold traphandle SNMPv2-MIB::warmStart /home/nba/bin/traps warm traphandle IF-MIB::linkDown /home/nba/bin/traps down traphandle IF-MIB::linkUp /home/nba/bin/traps up traphandle SNMPv2-MIB::authenticationFailure /home/nba/bin/traps auth # this one is deprecated traphandle .1.3.6.1.6.3.1.1.5.6 /home/nba/bin/traps egp-neighbor-loss # enterprise specific traps traphandle TRAP-TEST-MIB::demo-trap /home/nba/bin/traps demo-trap traphandle NOTIFICATION-TEST-MIB::demo-notif /home/nba/bin/traps demo-notifИ имитируем отключение сетевого интерфейса с помощью snmptrap:
получаем такой вывод от snmptrapd:
1999-11-13 12:46:49 localhost [127.0.0.1] TRAP-TEST-MIB::traps:
Link Down Trap (0) Uptime: 1 day, 18:54:46.27
IF-MIB::ifIndex.0 = 1
и такой вывод нашей 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 соответственно)
# send v1 traps trapsink nms.system.com public # also send v2 traps trap2sink nms.system.com secret # send traps on authentication failures authtrapenable 1Дополнительно агент может отсылать 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'ов) необходимые учётные записи:
snmpinform для отсылки snmptrapd INFORM'а coldStart:
Если вы сделали всё правильно, то должны увидеть подобное от snmptrapd:
2001-10-31 11:21:05 localhost.localdomain [127.0.0.1]:
sysUpTimeInstance = Timeticks: (42) 0:00:00.42 snmpTrapOID.0 = OID: coldStart.0
TRAP'ы SNMPv3
Использование TRAP'ов SNMPv3 порою может несколько запутать, но даёт хорошее понимание работы протокола, если вы немного поразмыслите об этом. Отличие TRAP'ов SNMPv3 в использовании engineID локального приложения, отсылающего TRAP вместо engineID удалённого приложения. Это значит, что вы должны создать необходимых пользователей в вашей удалённой базе,- по одному для каждого engineID, с которого вы хотите отсылать TRAP'ы. Если у вас 100 SNMP агентов отсылают TRAP'ы SNMPv3 на ваш TRAP-приёмник, то вы должны будете создать 100 записей createUser в конфигурационном файле /var/net-snmp/snmptrapd.conf.Итак, проверьте следующее:
snmptrap coldStart v3 TRAP сообщение TRAP-демону:
Вывод будет аналогичен предыдущему примеру. Далее должно идти долгое объяснение про v3 engineID, INFORM'ы, TRAP'ы, обнаружение engineID, секретные ключи, пароли, локальные ключи и пр. Всё это безобразие занимает 18223 строк текста в RFC 2570-2575, потому не будем повторяться здесь... Использование локальных MIB-файловУтилиты Net-SNMP могут производить преобразование цифровых OID'ов в текстовые используя файлы-описания MIB'ов. В комплекте уже идёт набор из нескольких стандартных MIB'ов, но во многих случаях этого недостраточно.Утилиты Net-SNMP загружают MIB'ы по-умолчанию из следующих двух директорий:
Попробуем преобразовать в цифровой вид имя узла из 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):
mibs +CISCO-RHINO-MIB mibs +SOME-OTHER-SPIFFY-MIBДля указания нужных MIB'ов можно также использовать переменную окружения с названием MIBS(далее пример для оболочки /bin/sh):
Опции специфичные для SNMPv33-я версия протокола SNMP имеет значительные улучшения по части безопасности в сравнении с предыдущими версиями. Так, SNMPv1 и SNMPv2c используют для аутентификации community-строку отсылаемую открытым текстом. Такой вид аутентификации весьма небезопасен, т.к. может быть легко перехвачен сниффером.SNMPv3 значительно улучшена по части безопасности и разделяет аутентификацию и авторизицию на следующие две части:
Профиль пользователя содержит следующие данные: Рассмотрим детальнее вывод последней команды. - Каждый пользователь имеет имя(securityName), тип аутентификации(authProtocol), тип privacy(privProtocol), а также ключи аутентификации(authKey) и privacy(privKey). - Аутентификация происходит путём подписывания отправляемого сообщения с помощью authKey. authProtocol на сегодняшний день может быть MD5 или SHA, тогда как authKeys и privKeys генерируются из парольной фразы длиной не менее 8-ми символов - Аутентификация происходит с применением пользовательского privKey для шифрования данных отсылаемого сообщения. privProtocol может быть AES или DES. Сообщения могут быть отосланы неаутентифицированными, аутентифицированными, или аутентифицированными и зашифрованными в зависимости от значания securityLevel. Таблица ниже описывает, как все эти значения могут быть указаны в командной строке. Вы также можете прописать значения по умолчанию в файл ~/.snmp/snmp.conf, используя третью колонку таблицы.
Примеры Пример запроса без аутентификации (как минимум, требуется указать имя пользователя): Запрос с аутентификацией: И наконец, запрос с аутентификацией и шифрованием: Конечно же они все выглядят похоже т.к. работают подобным образом. Но хост в примерах выше позволял использовать любой уровень аутентификации. Хосты, что вы будете настраивать, должны иметь более жёсткие правила безопасности и иметь хотя бы authNoPriv уровень при настройке VACM контроля доступа. И в завершении, пропишем snmp.conf подобным образом:
defContext none defSecurityName MD5User defAuthPassphrase The Net-SNMP Demo Password defVersion 3 defAuthType MD5 defSecurityLevel authNoPrivТаким образом все аргументы, используемые нами ранее в командной строке, будут автоматически браться из этого файла: И ещё проверка: Затем: Опции влияющие на формат выводаВсе команды пакета 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. Команда вернёт только значение атрибута, что весьма удобно использовать в скриптах:
Советы
Ссылки
|
| <- Назад |
|
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |
