Пример обработки дерева mib
Обновлено: 18.09.2024
Утилита 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: получение информации с удалённого хоста
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:
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
- Остановите запущённую snmptrapd
- Добавьте в /var/net-snmp/snmptrapd.conf следующую строку:
- Где myuser это securityName, mypassword - это пароль для аутентификации, а myotherpassword - это пароль для шифрования(оставьте его пустым, если не хотите менять или не хотите использовать шифрование)
- Перезапустите программу snmptrapd
- Остановите snmptrapd
- вставьте в файл /var/net-snmp/snmptrapd.conf следующую строку:
- Заметьте, что значение engineID пользователя явно задано как 0x0102030405(это не рекомендуется, но в действительности не имеет значения)
- (пере)запустите snmptrapd .
Вывод будет аналогичен предыдущему примеру.
Далее должно идти долгое объяснение про v3 engineID, INFORM'ы, TRAP'ы, обнаружение engineID, секретные ключи, пароли, локальные ключи и пр. Всё это безобразие занимает 18223 строк текста в RFC 2570-2575, потому не будем повторяться здесь.
Использование локальных MIB-файлов
Ага, она не знает. Теперь мы должны скачать файл 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
- USM - User-based Security Module, содежит список пользователей и их атрибутов. USM описан в RFC 2574.
- VACM - Version-based Access Control Module, контроллирует доступ пользователей(так и SNMPv1/v2c communities), в т.ч. доступ к определённым секциям MIB-дерева. VACM описан в RFC 2575.
Запрос с аутентификацией:
И наконец, запрос с аутентификацией и шифрованием:
Конечно же они все выглядят похоже т.к. работают подобным образом. Но хост в примерах выше позволял использовать любой уровень аутентификации. Хосты, что вы будете настраивать, должны иметь более жёсткие правила безопасности и иметь хотя бы 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 . Команда вернёт только значение атрибута, что весьма удобно использовать в скриптах:
Переменные AT-группы (attable, преобразование адресов; префикс=1.3.6.1.2.1.3).
| еременные at-группы | Тип данных | Описание | atEntry |
|---|---|---|---|
| atIfIndex | integer | Число интерфейсов. | 1 |
| atPhysAddress | physaddress | Физический адрес. Если эта переменная равна строке нулевой длины, физический адрес отсутствует. | 2 |
| atNetAddress | networkaddress | IP-адрес. | 3 |
Переменные UDP-группы (тип данных - counter; префикс=1.3.6.1.2.1.7)
| Имя переменной | Тип данных | Описание | Код |
|---|---|---|---|
| udpInDatagrams | counter | Число UDP-дейтограмм, присланных процессам пользователя. | 1 |
| udpNoPorts | counter | Число полученных UDP-дейтограмм, для которых отсутствует прикладной процесс в порте назначения. | 2 |
| udpInErrors | counter | Число не доставленных UDP-дейтограмм по причинам, отличающимся от отсутствия процесса со стороны порта назначения (напр., ошибка контрольной суммы). | 3 |
| udpOutDatagrams | counter | Число посланных UDP-дейтограмм. | 4 |
| udpTable | counter | Таблица, содержащая данные о принимающей стороне | 5 |
Переменные SNMP-группы (тип данных - counter; префикс=1.3.6.1.2.1.11)
INTEGER (целое число). Некоторые переменные объявляются как целые без ограничений (например, MTU для интерфейса), некоторые определены с конкретными значениями (например, флаг IP о перенаправлении установлен в 1, если перенаправление включено, или в 2, если перенаправление выключено), а другие определены с их минимальными и максимальными значениями (например, номера портов TCP и UDP находятся в диапазоне от 0 до 65535).
NULL (ноль). Означает, что у соответствующей переменной нет значения. Используется, например, в качестве всех значений для переменных в запросах get или get-next, пока эти переменные запрашиваются, а не устанавливаются.
IpAddress (IP адрес). OCTET STRING (восьмеричная строка) длиной 4, с 1 байтом на каждый байт IP адреса.
PhysAddress (физический адрес). OCTET STRING (восьмеричная строка), содержит физический адрес (например, 6-байтный Ethernet адрес).
Counter (счетчик). Неотрицательное целое число, значение которого увеличивается монотонно от 0 до значения 232-1 (4.294.967.295) и затем вновь возвращается в 0.
Gauge (критерий). Неотрицательное целое число в диапазоне от 0 до 232-1, значение которого может увеличиваться или уменьшаться, однако изменения прекращаются по достижении максимального значения. Это означает, что если значение достигнет величины 232-1, критерий будет оставаться в этом значении до тех пор, пока не будет сброшен. Примером может служить переменная MIB tcpCurrEstab: это количество TCP соединений, находящихся в настоящий момент в состоянии ESTABLISHED (установлено) или CLOSE_WAIT (ожидание закрытия).
TimeTicks (тики времени). Счетчик, который считает время в сотых долях секунды с какой-либо исходной точки. Различные переменные могут указывать начало счета с различных исходных точек, исходная точка используемая для каждой переменной этого типа и указывается, когда переменная объявляется в MIB. Например, переменная sysUpTime это количество сотых долей секунды, в течение которых агент был включен.
SEQUENCE OF (последовательность чего). Это определение вектора со всеми элементами, которые имеют тот же самый тип данных. Если каждый элемент имеет простой тип данных, такой как целое, мы имеем простой вектор (одномерный массив). Однако мы увидим, что SNMP использует эти типы данных с каждым элементом вектора, который является последовательностью (SEQUENCE) (структура). Поэтому мы можем считать их двумерными массивами или таблицей. Например, таблица слушающих процессов (listener) UDP называется udpTable, и является последовательностью (SEQUENCE OF) 2-элементной структуры (SEQUENCE) UdpEntry.
Приветствую тебя, гость и постоянный читатель. Пришлось в последнее время внедряться в сетевой мониторинг. Очень актуальная тема для мониторинга - SNMP (Simple Network Management Protocol). Часто приходилось использовать SNMP, но руки не доходили до его описания. Сегодня хочу изложить свое понимание данной технологии.
Введение в протокол SNMP
SNMP есть Simple Network Management Protocol, он же Простой Протокол Сетевого Управления. Протокол создан в 1988 г. с целью управления большим количеством сетевых устройств. С того момента протокол набрал соответствующую популярность и стал стандартом. С момента разработки протокол SNMP был 3 раза переработан с версии SNMPv1, SNMPv2 и SNMPv3. На самом деле, версий было больше, например v2 была пересмотрена 2 раза (или даже более). Так же стоит отметить, что кроме SNMP были и другие попытки создать коммерческие и не коммерческие протоколы управления (CORBA, TMN . ) не увенчавшиеся успехом.
Кроме управления устройствами, очень часто всегда SNMP используют для мониторинга. SNMP может получать различную информацию от любых сетевых устройств, будь то роутер, свич или просто компьютер (в которых имеется поддержка данного протокола (читай - запущен агент SNMP). Содержимое получаемой информации может быть очень разнообразно, например: время аптайма, различные счетчики производительности CPU, сети и др., сетевые параметры устройств.
Архитектура протокола SNMP
Сеть, использующая SNMP для управления содержит три основных компонента:
- SNMP менеджер - ПО, устанавливаемое на ПК администратора (системы мониторинга)
- SNMP агент - ПО, запущенное на сетевом узле, за которым осуществляется мониторинг.
- SNMP MIB - MIB это Management information base. Этот компонент системы обеспечивает структурированость данных, которыми обмениваются агенты и менеджеры. По сути - это некая база данных в виде текстовых фалов.
Давайте попытаемся рассмотреть обозначенные компоненты.
SNMP менеджер и SNMP агент
Для понимания назначения компонентов, можно сказать, что SNMP менеджер является прослойкой (интерфейсом) между оператором\администратором и сетевым узлом с запущенным SNMP агентом. Так же, можно сказать, что SNMP агент - это интерфейс между SNMP менеджером и железным оборудованием на сетевом узле. Если провести аналогию протокола SNMP с клиент-серверной архитектурой (например, веб-сервера) то веб-сервер работает как служба на некотором порту, а пользователь силами браузера обращается к веб-серверу как клиент. Это четко обозначенная архитектура с выраженным клиентом и сервером. В случае SNMP роли клиента и сервера несколько размыты. Например, SNMP агент является своего рода службой, работающей на устройстве (за которым производится мониторинг) и обрабатывает запросы на определенном порту udp/161, то есть фактически является сервером. А SNMP менеджер является своего рода клиентом, который обращается к серверу SNMP агенту. В SNMP существует т.н. Trap. Это запрос от агента к менеджеру. Точнее даже не запрос, а уведомление. При отправке данного уведомления, агент и менеджер "меняются ролями". То есть, менеджер в таком случае должен являться сервером, работающем на порту udp/162, а агент является клиентом. В последних версиях SNMP trap может именоваться как извещение (notification).
Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB. Тем самым делая ее доступной для менеджеров. Давайте рассмотрим схему взаимодействия SNMP-агент - SNMP-менеджер:
Итак, как я уже сказал, SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника (о полной структуре пакета SNMP опишу ниже). Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент таким образом предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.
- Trap – одностороннее уведомление от SNMP агента –> менеджеру о каком-либо событии.
- GetReponse – ответ от агента к менеджеру, возвращающий запрошенные значения переменных.
- GetRequest - запрос к агенту от менеджера, используемый для получения значения одной или нескольких переменных.
- GetNextRequest - запрос к агенту от менеджера, используемый для получения следующего в иерархии значения переменной.
- SetRequest - запрос к агенту на установку значения одной или нескольких переменных.
- GetBulkRequest – запрос к агенту на получение массива данных (тюнингованная GetNextRequest). (Этот PDU был введен в SNMPv2.)
- InformRequest – одностороннее уведомление между менеджерами. Может использоваться, например для обмена информацией о MIB (соответствие символьных OID - цифровым). В ответ менеджер формирует аналогичный пакет в подтверждение того, что исходные данные получены. (Этот PDU был введен в SNMPv2.)
Как видно, в зависимости от версии протокола, набор команд разный (например InformRequest и GetBulkRequest полноценно появился только во второй версии SNMP). Компонент SNMP MIB рассмотрим ниже.
Структура PDU
Рассмотрение структуры PDU не обязательно, но это поможет более глубоко понять логику работы SNMP. Все PDU (кроме Trap) состоят из определенного набора полей, в которые записывается необходимая информация:
Что данные поля обозначают:
При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):
- Фирма – характеризующее производителя хоста
- Тип trapуведомления, может быть следующим:
- 0 (Coldstart) и 1 (Warmstart) – объект возвращен в начальное состояние (между ними имеется некая разница, но какая. ),
- 2 (Linkdown) – интерфейс опущен, при этом, поле переменной содержит интерфейс о котором идет речь,
- 3 (Linkup) – интерфейс поднялся, при этом, поле переменной содержит интерфейс о котором идет речь,
- 4 (Authenticationfailure) – менеджер прислал мессадж с неверной строкой community,
- 5 (EGPneighborloss) – затрудняюсь что либо сказать ),
- 6 (Entrprisespecific) – данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.
В новых версиях SNMP содержимое Trap PDU может незначительно меняться, но в целом, смысл тот же.
Логика работы протокола SNMP
Логика работы SNMP при обмене PDU-единицами
При получении PDU GetRequest, SNMP агент действует по следующему алгоритму:
При получении PDU GetNextRequest, SNMP агент действует по следующему алгоритму:
При получении PDU SetRequest, SNMP агент действует по следующему алгоритму:
Логика работы SNMP в картинках
Обмен PDU GET⁄ GET NEXT⁄ GET BULK⁄ SET
Обмен PDU Trap или notification
SNMP MIB
Каждая ветка MIB-иерархии оканчивается некоторой переменной (так же имеющей свой OID), содержащей в себе определенное значение, которое записывается в переменную SNMP агентом, работающем на хосте. Данное значение неким образом характеризует данный хост (например, содержит информацию об аптайме, загрузке сетевого интерфейса и мн.др. параметры).
Имеется некая единая общая структура дерева MIB, а так же, имеются единые стандарты и принципы дальнейшего формирования данного дерева, его переменных, др. параметров, за эти правила отвечает некий разработанный стандарт под названием Структура Информации Управления (SMI, Structure of Management Information). Так же, имеется некий стандарт, называемый абстрактный синтаксис нотаций - ASN.1. Который тоже участвует в описании протокола SNMP и базы MIB. А еще имеется базовые правила кодирования BER (Basic Encoding Rules), определяющие кодирование сущностей, применяемых в SNMP.
Кроме того, существует всемирное дерево регистрации стандартов ISO, содержащее базовую структура дерева MIB (точнее этих структур существует несколько, они формировались вместе с совершенствованием версий SNMP). Составное числовое имя объекта SNMP MIB соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO. За данную древовидную структуру отвечает и контролирует организация IANA (и некоторые другие).
Давайте рассмотрим типичное дерево MIB на рисунке:
![Managenent Information base]()
Дерево объектов MIB подобно системе DNS (Domain Name System). Тут аналогично имеются символьные имена (аналогично NS имени) и называемые ASN.1 нотацией, и соответствующие им числовые значения (аналогично IP адресам), называемые dot нотацией. Каждый объект в MIB состоит из нескольких чисел, разделенных точками. Числам соответствуют текстовые наименования. При этом, в отличии от DNS - нет какого-то единого централизованного сервера, отвечающего за разолвинг имен. Все разрешения имен из символов в числа происходят силами SNMP менеджера (в зависимости от того, какие сопоставления MIB загружены в менеджер). Весь обмен между узлами SNMP происходит только в числовом виде. В символьном виде, наименования используются только для отображения на экране или в документации.
Часто OID характеризующий определенный объект в дереве MIB сравнивают со структурой телефонных номеров, т.к. они (номера) так же иерархичны и отдельные части номера назначаются различными организациями. Например, международные телефонные номера состоят из кода страны (назначаемого международной организацией) и телефонного номера в том виде, в котором он определен локально в стране. При этом, телефонный номер в стране делится на код области\края\региона, номер АТС и далее номер абонента, привязанного к АТС. Аналогично - в MIB OID верхнего уровня назначаются международной организацией (ISO IEC . ), ветки OID нижнего уровня назначаются организациями, отвечающими за эти ветки.
Итак, структура OID в дереве MIB:
![MIB SNMP ветка enterprise]()
Ниже структура аналогичная всем остальным разделам – древовидна. В каждом поддереве соответствующий производитель оборудования в праве сам регистрировать свои ветвления и переменные.
Безопасность протокола SNMP (или версии протокола SNMP)
В одной из вторых версий SNMP (SNMPv2p) была попытка реализовать аутентификацию на основе сторон (т.н.Party-based Security Model). Технология кроме аутентификации, так же поддерживала возможность шифрования трафика. Данная технология не прижилась, как "сложная и запутанная" ) и в данный момент не используется. После чего SNMP второй версии вернулась к Community-based Security и стала именоваться SNMPv2c и применяется по сей день. SNMPv2 была переписана чуть более чем полностью, в результате чего существенно повышено быстродействие протокола, безопасность.
Третья версия протокола (SNMPv3) была более удачно доработана и поддерживает как аутентификацию на основе имени пользователя (т.н. User-based Security Model), так и шифрование трафика. Хотя их можно и не использовать.
Версии протокола между собой не совместимы. Несовместимость заключается в разнице пакетов PDU, в наличии дополнительных команд в более новых версиях протокола (возможно, в других…). В RFC 2576 имеется некоторая информация, позволяющая организовать возможность совместного использования SNMPv1 и v2. Для этого есть 2 пути: 1. Использование прокси-агентов (агент преобразует PDU SNMPv2 в PDU SNMPv1), 2. Использование менеджера с поддержкой 2х версий (менеджер для каждого хоста должен помнить версию агента).
Принципы настройки протокола SNMP
Для того, чтобы SNMP менеджер мог работать с символьными именами OID (ASN.1 нотация), необходимо подсунуть ему соответствующие файлы SMI и MIB, хранящие соответствия символьной записи и цифровой. Для того чтобы SNMP менеджер мог взаимодействовать с каком-либо агентом, необходимо менеджеру указать на этого агента, для чего задать соответствующие настройки, например:
- Порт отправки
- Принимать ли trap
- community для чтения
- community для записи
- период опроса
- OID’ы
- …
В большинстве реализаций менеджеров SNMP (в данном контексте, наверно, лучше сказать – систем управления сетью Network Management System) предоставлены некие возможности механизма автоматического обнаружения SNMP агентов. В большинстве случаев это сводится к выполнению по расписанию некоторого скрипта, запускаемого в определенный промежуток времени и опрашивающего заданный диапазон IP адресов.
SNMP в Linux
В большинстве дистрибутивов Linux для работы с SNMP используется пакет net-snmp (RedHat) и snmp + snmpd (в Debian в snmp лежит клиентская часть, а в snmpd – серверная часть), который позволяет использовать протокол SNMP посредством отправки и получения PDU. После установки пакета(ов) в linux появятся следующие инструменты (перечислены не все):
SNMP в Debian
Политика лицензирования Debian определяет базы MIB, как несвободное ПО, поэтому они не расположены в свободных репозитоиях, а размещены в non-free репозиториях. Для того чтобы базы корректно установились, необходимо данный репозиторий прописать в /etc/apt/sources.list, например:
и установить пакет snmp-mibs-downloader. (в процессе установки данный пакет попытается получить mib-базы из интернета). Так, же, необходимо в /etc/snmp/snmp.conf закомментировать строку:
Маленький итог о SNMP
Итак, в статье я постарался как можно понятней рассказать о SNMP, чтобы применять эту технологию в сетях мониторинга. Подводя краткий итог протокол SNMP базируется на нескольких основных принципах:
Пространство имен для идентификаторов объектов MIB является иерархическим. Он структурирован таким образом, что каждому управляемому объекту можно назначить глобально уникальное имя.
Центр для частей пространства имен назначается отдельным организациям. Это позволяет организациям назначать имена без консультации с Интернетом для каждого назначения. Например, пространство имен, назначенное Microsoft, — это 1.3.6.1.4.1.311, которое определено в MSFT. MIB. Корпорация Майкрософт имеет право назначать имена объектам в любом месте под этим пространством имен.
Идентификатор объекта в иерархии записывается в виде последовательности субидентификаторов, начиная с корня и заканчивая объектом. Подидентификаторы разделяются точкой.
Читайте также:
