SNMP протокол (основы)

Приветствую тебя, гость. Пришлось в последнее время внедряться в сетевой мониторинг. Очень актуальная тема для мониторинга – 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 для управления содержит три основных компонента:

1. SNMP менеджер – ПО, устанавливаемое на ПК администратора (системы мониторинга)
2. SNMP агент – ПО, запущенное на сетевом узле, за которым осуществляется мониторинг.
3. 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).

SNMP работает на 7 уровне модели OSI, то есть является службой прикладного уровня. Взаимодействие агента и менеджера на уровне протокола SNMP организуется посредством т.н. пакетов объектов PDU (Protocol Data Unit), которые инкапсулируются в транспортный протокол. Хотя, SNMP поддерживает различные виды транспорта, в 99% случаев используется – UDP. При этом, каждое сообщение PDU содержит определенную команду (на чтение переменной, запись значения переменной, или ответ\trap агента). В целом, взаимодействие узлов по SNMP можно представить следующей последовательностью: менеджер -> SNMP(PDU)-UDP-IP-Ethernet-IP-UDP-SNMP(PDU) ->агент. При использовании шифрования в SNMP, по умолчанию используются порт для запросов\ответов udp/10161, а Trap отправляются на udp/10162.

Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB. Тем самым делая ее доступной для менеджеров. Давайте рассмотрим схему взаимодействия SNMP-агент – SNMP-менеджер:

Итак, как я уже сказал, SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника (о полной структуре пакета SNMP опишу ниже). Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент таким образом предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.

SNMP PDU (или сообщения SNMP протокола)

Выше я упомянул о единице обмена между узлами SNMP – PDU (Protocol Data Unit), давайте разберем данное понятие. Для обмена между агентом и менеджером используется определенный набор сообщений PDU команд:

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) состоят из определенного набора полей, в которые записывается необходимая информация.

Если для любой переменной, содержащейся в поле связанные переменные, запись (операция set) не поддерживается в имеющих отношение к делу представлениях MIB, SNMP агент объект передает отправителю запроса аналогичное PDU GetResponse, указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.

Если для любой переменной в запросе, запрашиваемые к изменению значения переменных не соответствуют стандартам (SMI, ASN.1 – об этом ниже), то SNMP агент передает SNMP менеджеру аналогичное PDU GetResponse, указывая в поле кода ошибки значение badValue (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.

Если размер PDU ответа (GetResponse), созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение, принимающий объект передает отправителю аналогичное PDU GetResponse, указав в поле errorstatus значение tooBig, а в поле error-index — 0.

Если для любой переменной в поле связанные переменные, значение переменной не может быть установлено по причинам, которые отличаются от перечисленных выше, SNMP агент передает менеджеру PDU с исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)

Если все нормально, агент передает SNMP менеджеру, отправившему PDU, такое сообщение GetResponse, в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

SNMP MIB

Давайте попробуем понять MIB. Это совсем не люди в черном ) Как я уже сказал, это Management information base, то есть база набор управляющей информации. Каждый сетевой узел, имеющий на своем борту SNMP агента (читай – поддерживающий протокол SNMP) предоставляет свой набор данных, тот, который в него «вложили» программисты\разработчики при проектировании железки\программы. То есть в каждом сетевом устройстве с поддержкой SNMP имеется своя база MIB со строго обозначенным набором переменных. Каждая база MIB имеет древовидную структуру, каждый объект в которой характеризуется уникальным идентификатором объекта (Object Identifier, OID).

Каждая ветка 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 (и некоторые другие).

Ветка поделена на базовые группы (которых на текущий момент более 170), характерные для любого сетевого оборудования. Давайте рассмотрим наиболее применяемые:

1. iso.org.dod.internet.mgmt.mib-2.system (1.3.6.1.2.1.1) – ветка содержит в себе несколько объектов, характеризующих хост (аптайм, версия ОС и др.), описана в RFC1213.
2. iso.org.dod.internet.mgmt.mib-2.interface (1.3.6.1.2.1.2) – содержит объекты, описывающие сетевую подсистему хоста (количество интерфейсов, размер MTU, скорость передачи, физические адреса и т.п.), описана в RFC2863.
3. iso.org.dod.internet.mgmt.mib-2.ip (1.3.6.1.2.1.4) – содержит набор объектов, описывающих данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов и мн.др). Описана в RFC1213.
4. iso.org.dod.internet.mgmt.mib-2.tcp (1.3.6.1.2.1.6) и iso.org.dod.internet.mgmt.mib-2.udp (1.3.6.1.2.1.7) – содержат объекты, хранящие в себе информацию, касающуюся соответствующего транспортного протокола. Описана в RFC1213
5. И мн. др., которые в принципе имеют довольно наглядное наименование и которые далее «раскрываются» на большее множество объектов.

Отдельного абзаца так же достоин подраздел iso.org.dod.internet.private (1.3.6.1.4), содержащий в себе поддерево enterprise (1). Данная ветвь контролируется IANA и содержит в себе более 40000 поддеревьев (ознакомьтесь с актуальным списком http://www.iana.org/assignments/enterprise-numbers ). В данной ветке регистрируют свои поддеревья – производители оборудования.

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

• Порт отправки
• Принимать ли 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 появятся следующие инструменты (перечислены не все):

• snmptranslate – Перевод MIB OID имён между цифровой и текстовой представлениями.
• snmpget – Взаимодействует с агентом, используя PDU GetRequest запросы.
• snmpgetnext – Взаимодействует с агентом, используя PDU GetNextRequest запросы.
• snmpbulkget – Взаимодействует с агентом, используя PDU GetBulkRequest запросы.
• snmpwalk – Получает поддерево объектов OID из MIB базы агента с помощью PDU GetNextRequest запросов. Если OID не задан, то команда получает дерево, начиная от MIB-2 (iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1))
• snmpbulkwalk – Получает поддерево объектов OID из MIB базы агента с помощью PDU GetBulkRequest запросов.
• snmpset – Взаимодействует с агентом, используя PDU SetRequest запросы.
• snmptrap – Посылает SNMP Trap или информационные сообщения.
• snmptest – Взаимодействует с сетью, используя SNMP запросы.
• …

Основной и часто используемой из всех указанных команд, является snmpwalk. При указании данной команды, без OID она попытается получить все объекты из ветки iso.org.dod.internet.mgmt.mib-2. В ссылках ниже можно найти отличный сборник примеров использования данных программ.

Так же, стоит отметить, что когда Вы работаете с указанными командами, наименование переменных OID «сворачивается» до короткого пути, например путь OID iso.org.dod.internet.mgmt.mib-2.system.sysName.0 (1.3.6.1.2.1.1.5.0) будет свернут до SNMPv2-MIB::sysName.0. На иллюстрации дерева MIB видно, как выделен красной заливкой путь iso.org.dod.internet.mgmt.mib-2, собственно, он и свернут в название данной ветки и представлен как SNMPv2-MIB::.