Что такое протокол snmp. Основы работы с SNMP

SNMP работает на прикладном уровне TCP/IP (седьмой уровень модели OSI). Агент SNMP получает запросы по UDP-порту 161. Менеджер может посылать запросы с любого доступного порта источника на порт агента. Ответ агента будет отправлен назад на порт источника на менеджере. Менеджер получает уведомления (Traps и InformRequests) по порту 162. Агент может генерировать уведомления с любого доступного порта. При использовании TLS или DTLS запросы получаются по порту 10161, а ловушки отправляются на порт 10162.

В SNMPv1 указано пять основных протокольных единиц обмена (protocol data units - PDU). Еще две PDU, GetBulkRequest и InformRequest, были введены в SNMPv2 и перенесены в SNMPv3.

Все PDU протокола SNMP построены следующим образом:

Ниже перечислены семь протокольных единиц обмена SNMP:

GetRequest

Запрос от менеджера к объекту для получения значения переменной или списка переменных. Требуемые переменные указываются в поле variable bindings (раздел поля values при этом не используется). Получение значений указанной переменной должно быть выполнено агентом как Атомарная операция . Менеджеру будет возвращён Response (ответ) с текущими значениями.

SetRequest

Запрос от менеджера к объекту для изменения переменной или списка переменных. Связанные переменные указываются в теле запроса. Изменения всех указанных переменных должны быть выполнены агентом как атомарная операция. Менеджеру будет возвращён Response с (текущими) новыми значениями переменных.

GetNextRequest

Запрос от менеджера к объекту для обнаружения доступных переменных и их значений. Менеджеру будет возвращён Response со связанными переменными для переменной, которая является следующей в базе MIB в лексиграфическом порядке. Обход всей базы MIB агента может быть произведён итерационным использованием GetNextRequest, начиная с OID 0. Строки таблицы могут быть прочтены, если указать в запросе OID-ы колонок в связанных переменных.

GetBulkRequest

Улучшенная версия GetNextRequest. Запрос от менеджера к объекту для многочисленных итераций GetNextRequest. Менеджеру будет возвращён Response с несколькими связанными переменными, обойдёнными начиная со связанной переменной (переменных) в запросе. Специфичные для PDU поля non-repeaters и max-repetitions используются для контроля за поведением ответа. GetBulkRequest был введён в SNMPv2.

Response

Возвращает связанные переменные и значения от агента менеджеру для GetRequest, SetRequest, GetNextRequest, GetBulkRequest и InformRequest. Уведомления об ошибках обеспечиваются полями статуса ошибки и индекса ошибки.

Эта единица используется как ответ и на Get-, и на Set-запросы, в SNMPv1 называется GetResponse .

Trap

Асинхронное уведомление от агента - менеджеру. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap (ловушки), и необязательные связанные переменные. Адресация получателя для ловушек определяется с помощью переменных trap-конфигурации в базе MIB. Формат trap-сообщения был изменён в SNMPv2 и PDU переименовали в SNMPv2-Trap.

InformRequest

Асинхронное уведомление от менеджера менеджеру или от агента менеджеру. Уведомления от менеджера менеджеру были возможны уже в SNMPv1 (с помощью Trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована, и не сообщается о потерянных пакетах. InformRequest исправляет это обратным отправлением подтверждения о получении. Получатель отвечает Response-ом, повторяющим всю информацию из InformRequest. Этот PDU был введён в SNMPv2.

Разработка и использование

Версия 1

SNMP, версия 1 (SNMPv1) - изначальная реализация протокола SNMP. SNMPv1 работает с такими протоколами, как UDP, IP, CLNS, DDP и IPX. SNMPv1 широко используется и де-факто является протоколом сетевого управления в Интернет-сообществе.

Первые RFC для SNMP, сейчас известные как SNMPv1, появились в 1988г:

• RFC 1065
• RFC 1066
• RFC 1067

Эти протоколы были пересмотрены в следующих RFC:

• RFC 1155 - Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP
• RFC 1156 - База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP
• RFC 1157 - Простой протокол сетевого управления

• Настройка SNMP на Cisco as53xx

Enter configuration commands, one per line. End with CNTL/Z.

Список № 1: Разрешить доступ из сети 10.26.95.224/27 или 255.255.255.224

as5350(config)#access-list 1 permit 10.26.95.224 0.0.0.31

Список № 2: Разрешить доступ с IP 10.26.95.254 и 10.26.95.251

as5350(config)#access-list 2 permit host 10.26.95.254

as5350(config)#access-list 2 permit host 10.26.95.251

Настройка snmp-server для чтения и записи со строкой сообщества xxas5300xx. SNMP-доступ разрешён только для access-list 2 (для 2-х IP, для остальных IP неявно запрещён)

as5350(config)#snmp-server community xxas5300xx rw 2

Разрешаем reload циски по SNMP.

as5350(config)#snmp-server system-shutdown

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

Структура PDU

Рассмотрение структуры PDU не обязательно, но это поможет более глубоко понять логику работы SNMP . Все PDU (кроме Trap) состоят из определенного набора полей, в которые записывается необходимая информация:

Что данные поля обозначают:

При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):

• Фирма – характеризующее производителя хоста
• Тип trap уведомления, может быть следующим:
  • 0 (Coldstart) и 1 (Warmstart) – объект возвращен в начальное состояние (между ними имеется некая разница, но какая?..),
  • 2 (Linkdown) – интерфейс опущен, при этом, поле переменной содержит интерфейс о котором идет речь,
  • 3 (Linkup) – интерфейс поднялся, при этом, поле переменной содержит интерфейс о котором идет речь,
  • 4 (Authenticationfailure) – менеджер прислал мессадж с неверной строкой community,
  • 5 (EGPneighborloss) – затрудняюсь что либо сказать),
  • 6 (Entrprisespecific) – данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.
• Специализированный тип Trap – описан выше
• Метка времени – содержит метку времени с момента события (непонятно, относительно чего эта метка…).

В новых версиях SNMP содержимое Trap PDU может незначительно меняться, но в целом, смысл тот же...

Логика работы протокола SNMP

Рассмотрев основные единицы обмена SNMP , можно обсудить логику работы SNMP при выполнении данных запросов\ответов. Некоторые общие особенности работы протокола SNMP , которые стоит учитывать:

Логика работы SNMP при обмене PDU-единицами

(взято частично отсюда http://logic-bratsk.ru/brlug/snmp_my/):

При получении PDU GetRequest, SNMP агент действует по следующему алгоритму:

1. Если имя переменной не совпадает в точности с именем одной из переменной , доступных для операции get в нашей MIB, передаем отправителю запроса аналогичное PDU GetResponse , указывая в поле кода ошибки значение noSuchName (2-нет такого имени), а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении (=1, в SNMPv1 - ограничение данной реализации SNMP).
2. Если размер PDU GetResponse , превышает локальное ограничение (Реализация SNMP не обязана принимать сообщения, размер которых превышает определенное значение. Однако по возможности желательна поддержка дейтаграмм больших размеров (RFC1157 SNMP).) , передаем отправителю аналогичное PDU GetResponse , указав в поле errorstatus значение T ooBig , а в поле error-index - 0 . Это обычно происходит, если запрошено больше 1 переменной или длина PDU или общая длина пакета больше стандартных пределов.
3. Если для любой переменной, содержащейся в поле связанные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, SNMP агент передает отправителю аналогичное PDU GetResponse, указав в поле error-status значение GenErr, а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении.
4. Если все нормально, передаем SNMP менеджеру, отправившему полученное сообщение, ответ - GetResponse, в котором для каждой переменной в поле связанные переменные подставлены запрошенные значения переменных. В поле error-status помещается значение NoError, а в поле error-index - 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

При получении PDU GetNextRequest, SNMP агент действует по следующему алгоритму:

1. Если после переменной, указанной в запросе, нет следующей переменной, то передаем отправителю запроса менеджеру PDU GetResponse (с содержимым аналогичным исходному запросу), указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении (=1 для SNMPv1), значение переменной = NULL (кажется).
2. Если размер PDU ответа (GetResponse), созданного в соответствии с приведенным ниже описанием, GetResponse , указав в поле errorstatus значение tooBig , а в поле error-index - 0.
3. Если для любой переменной в поле связанные переменные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, принимающий объект передает менеджеру PDU
4. Если все нормально, передаем SNMP менеджеру, отправившему PDU, такое сообщение GetResponse , в котором для каждой переменной в поле связанные переменные содержится имя и значение переменной, иерархически следующей за запрошенной переменной в базе MIB. В поле error-status помещается значение noError , а в поле error-index - 0 . Значение поля request-id в ответном PDU GetResponse совпадает с идентификатором в принятом сообщении.

При получении PDU SetRequest, SNMP агент действует по следующему алгоритму:

1. Если для любой переменной, содержащейся в поле связанные переменные, запись (операция set) не поддерживается в имеющих отношение к делу представлениях MIB, SNMP агент объект передает отправителю запроса аналогичное PDU GetResponse , указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении.
2. Если для любой переменной в запросе, запрашиваемые к изменению значения переменных не соответствуют стандартам (SMI, ASN.1 – об этом ниже), то SNMP агент передает SNMP менеджеру аналогичное PDU GetResponse, указывая в поле кода ошибки значение badValue (нет такого имени), а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении.
3. Если размер PDU ответа (GetResponse), созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение , принимающий объект передает отправителю аналогичное PDU GetResponse , указав в поле errorstatus значение tooBig , а в поле error-index - 0.
4. Если для любой переменной в поле связанные переменные, значение переменной не может быть установлено по причинам, которые отличаются от перечисленных выше, SNMP агент передает менеджеру PDU с исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)
5. Если все нормально, агент передает SNMP менеджеру, отправившему PDU, такое сообщение GetResponse , в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index - 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

Логика работы SNMP в картинках

взято отсюда (http://www.manageengine.com/network-monitoring/what-is-snmp.html)

Обмен PDU GET⁄ GET NEXT⁄ GET BULK⁄ SET

Обмен PDU Trap или notification

SNMP MIB

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

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

Имеется некая единая общая структура дерева MIB , а так же, имеются единые стандарты и принципы дальнейшего формирования данного дерева, его переменных, др. параметров, за эти правила отвечает некий разработанный стандарт под названием Структура Информации Управления (SMI , S tructure of M anagement I nformation ). Так же, имеется некий стандарт, называемый абстрактный синтаксис нотаций - ASN.1. Который тоже участвует в описании протокола SNMP и базы MIB . А еще имеется базовые правила кодирования BER (B asic E ncoding R ules), определяющие кодирование сущностей, применяемых в SNMP.

Кроме того, существует всемирное дерево регистрации стандартов IS O , содержащее базовую структура дерева MIB (точнее этих структур существует несколько, они формировались вместе с совершенствованием версий SNMP). Составное числовое имя объекта SNMP MIB соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO . За данную древовидную структуру отвечает и контролирует организация IANA (и некоторые другие).

Давайте рассмотрим типичное дерево MIB на рисунке:

Дерево объектов MIB подобно . Тут аналогично имеются символьные имена (аналогично NS имени) и называемые ASN.1 нотацией , и соответствующие им числовые значения (аналогично IP адресам), называемые dot нотацией . Каждый объект в MIB состоит из нескольких чисел, разделенных точками. Числам соответствуют текстовые наименования. При этом, в отличии от DNS - нет какого-то единого централизованного сервера, отвечающего за разолвинг имен. Все разрешения имен из символов в числа происходят силами SNMP менеджера (в зависимости от того, какие сопоставления MIB загружены в менеджер). Весь обмен между узлами SNMP происходит только в числовом виде. В символьном виде, наименования используются только для отображения на экране или в документации.

Часто OID характеризующий определенный объект в дереве MIB сравнивают со структурой телефонных номеров, т.к. они (номера) так же иерархичны и отдельные части номера назначаются различными организациями. Например, международные телефонные номера состоят из кода страны (назначаемого международной организацией) и телефонного номера в том виде, в котором он определен локально в стране. При этом, телефонный номер в стране делится на код области\края\региона, номер АТС и далее номер абонента, привязанного к АТС. Аналогично - в MIB OID верхнего уровня назначаются международной организацией (ISO IEC ???), ветки OID нижнего уровня назначаются организациями, отвечающими за эти ветки.

Итак, структура OID в дереве MIB :

В вершине дерева – корень (точка), от которого ответвляются ветви. Во многих схемах приведены некоторые ветви верхнего уровня (например itu-t, iso\itu-t и другие ниже), но информации о их назначении я не нашел… Посему, нас интересует вертка iso (0), которая хранит в себе следующие значения до internet (1) : iso.org.dod.internet , что соответствует числовому ID .1.3.6.1 .

Данный раздел (iso.org.dod.internet ) разветвляется на подразделы, которые в большинстве своем контролируются IANA и состоят (согласно RFC1155) из:

• directory OID=1.3.6.1.1 (iso.org.dod.internet. directory ) – зарезервировано для использования в будущем
• mgmt OID=1.3.6.1.2 (iso.org.dod.internet. mgmt )- в этой ветке находится стандартные ответвления объектов.
• experimental OID=1.3.6.1.3 (iso.org.dod.internet. experimental )- это ветка для экспериментов разработчиков. (не отображено на схеме )
• private OID=1.3.6.1.4 (iso.org.dod.internet. private )– раздел предназначен для использования производителями оборудования.

Далее, необходимо рассмотреть отдельным пунктом ветку 1.3.6.1.2 (iso.org.dod.internet. mgmt ), состоящую из подветки mib-2 (1) , а так же reserved(0) , pib(2) , http(9) и некоторых других. Стоит отметить, что в зависимости от версии протокола (SNMPv1 vs SNMPv2) на месте данной ветки могут быть «прилинкованы» разные поддеревья в целом имеющие примерно одинаковую структуру и одинаковые идентификаторы, но в более новой версии протокола – поддерево более расширено. (наверно, в этом и состоит несовместимость версий протокола…)

Итак iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) : данная ветка является базовой для большинства сетевых устройств и содержится практически в любом устройстве. Ветка поделена на базовые группы (которых на текущий момент более 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). В данной ветке регистрируют свои поддеревья – производители оборудования. Вот пример ответвления:

Ниже структура аналогичная всем остальным разделам – древовидна. В каждом поддереве соответствующий производитель оборудования в праве сам регистрировать свои ветвления и переменные.

Так же, важным моментом, является то, что любая ветвь базы MIB оканчивается переменной , в которую записывается некоторое значение. При этом, в MIB существует несколько типов переменных. Во-первых, они делятся на переменные «только для чтения » и доступные для изменения , которые не позволяют выполнять запрос SetRequest и позволяют выполнять, соответственно. Во-вторых, имеются строковые переменные, табличные и мн.др., значения которых так же идентифицируются по OID. В целом, если нет желания к программированию для SNMP, то этим пониманием и можно ограничиться.

Безопасность протокола SNMP (или версии протокола SNMP)

Безопасность протокола SNMP - это самый изменяемый раздел спецификации протокола со времени его создания. С каждой версией SNMP, производились попытки усилить безопасность. Первая версия протокола SNMPv1 была самой простой и небезопасной. Сообщения протокола могли быть подвержены возможности модификации, подмене или прослушиванию. Безопасность протокола базировалась на модели безопасности на основе сообществ (т.н. Community-based Security Model ), что подразумевало аутентификацию на основе единой текстовой строки - своеобразного пароля (т.н. community-sting ), которая передавалась в теле сообщения в открытом виде. Хотя, данная версия протокола самая незащищенная, она довольно часто применяется в современных сетях, т.к. является самой простой.

В одной из вторых версий 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х версий (менеджер для каждого хоста должен помнить версию агента).

Давайте рассмотрим работу протокола SNMPv2c (и SNMPv1 ) с точки зрения безопасности. При рассмотрении структуры пакета PDU было видно, что каждая единица PDU содержит community строку. При этом, SNMP агент содержит список (часто данный список состоит из одного значения) разрешенных строк и описание того, что каждая из строк может делать (фактически – набор прав). В большинстве случаев – это права read/write. При активации функций SNMP на каком-либо хосте, стандартные строки community – это public и private для возможности чтения и для возможности чтения-записи соответственно. Это строки очень желательно менять на свои. Часто, при конфигурировании SNMP о, в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index - 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.пределяют различные community строки для чтения переменных и для записи .

Принципы настройки протокола SNMP

Для того, чтобы SNMP менеджер мог работать с символьными именами OID (ASN.1 нотация), необходимо подсунуть ему соответствующие файлы SMI и MIB, хранящие соответствия символьной записи и цифровой. Для того чтобы SNMP менеджер мог взаимодействовать с каком-либо агентом, необходимо менеджеру указать на этого агента, для чего задать соответствующие настройки, например:

• Порт отправки
• Принимать ли trap
• community для чтения
• community для записи
• период опроса
• OID’ы

В большинстве реализаций менеджеров SNMP (в данном контексте, наверно, лучше сказать – систем управления сетью Network Management System ) предоставлены некие возможности механизма автоматического обнаружения SNMP агентов. В большинстве случаев это сводится к выполнению по расписанию некоторого скрипта, запускаемого в определенный промежуток времени и опрашивающего заданный диапазон IP адресов.

SNMP в Linux

• RFC 1155 (STD 16) - Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP
• RFC 1156 (Historic) - База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP
• RFC 1157 (Historic) - Простой протокол сетевого управления (SNMP)
• RFC 1213 (STD 17) - База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP: MIB-II
• RFC 1452 (Informational) - "Сосуществование версий 1 и 2 Интернет-стандарта Network Management Framework (пересмотрен в RFC 1908)
• RFC 1901 (Experimental) - Введение в SNMPv2 на основе сообществ
• RFC 1902 (Draft Standard) - Структура управляющей информации для SNMPv2 (пересмотрен в RFC 2578)
• RFC 1908 (Standards Track) - Сосуществование версий 1 и 2 Интернет-стандарта Network Management Framework
• RFC 2570 (Informational) - Введение в версию 3 Интернет-стандарта Network Management Framework (пересмотрен в RFC 3410)
• RFC 2578 (STD 58) - Структура управляющей информации, версия 2 (SMIv2)
• RFC 3410 (Informational) - Вопросы введения и применения Интернет-стандарта Network Management Framework"
• STD 62

• RFC 3411 - Архитектура для описания SNMP Management Framework
• RFC 3412 - Обработка и отправление сообщений для SNMP
• RFC 3413 - Приложения SNMP
• RFC 3414 - Модель безопасности на основе пользователей (USM) для SNMPv3
• RFC 3415 - View-based Access Control Model (VACM) для SNMP
• RFC 3416 - Версия 2 протокольных операций для SNMP
• RFC 3417 - Привязки к транспорту для SNMP
• RFC 3418 - База управляющей информации (MIB) для SNMP
• RFC 3430 (Experimental) - SNMP над привязками к транспорту в TCP
• RFC 3584 (BCP 74) - Сосуществование версий 1, 2 и 3 Интернет-стандарта Network Management Framework
• RFC 3826 (Proposed) - Алгоритм шифрования AES (Advanced Encryption Standard) в модели безопасности на основе пользователей в SNMP
• RFC 5343 (Proposed) - Контекстное EngineID-обнаружение в SNMP
• RFC 5590 (Draft) - Транспортная подсистема для SNMP
• RFC 5591 (Draft) - Транспортная модель безопасности для SNMP
• RFC 5592 (Proposed) - Транспортная модель Secure Shell для SNMP
• RFC 5608 (Proposed) - Использование службы аутентификации удаленных пользователей по коммутируемым каналам связи (RADIUS) в транспортных моделей в SNMP
• RFC 6353 (Draft) - Транспортная модель TLS для SNMP

С Уважением, Mc.Sim!

SNMP - это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков, например IPX/SPX. Протокол SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB (Management Information Base). Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB II. Кроме того, сам протокол SNMP также весьма несложен.

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

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

SNMP - это протокол типа «запрос-ответ» , то есть на каждый запрос, поступивший от менеджера, агент должен передать ответ. Особенностью протокола являет­ся его чрезвычайная простота - он включает в себя всего несколько команд.

Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.

Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.

С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.

Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие - отключить порт, приписать порт определенной VLAN и т. п. Команда Set пригодна также для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.

Команда Trap используется агентом для сообщения менеджеру о возникновении особой ситуации.

Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько значений переменных за один запрос.

Введение

Одной из проблем большинства сегодняшних сетей - быстрорастущих, больших по количеству узлов и зачастую широко раскинутых географически - является управление и получение информации о состоянии всей сети или отдельных ее участков.

Целью данной курсовой работы является изучение протокола SNMP, предназначенного для удаленного управления и сбора информации с удаленных систем. К настоящему времени данный протокол достаточно хорошо развит и используется во многих областях сетевых технологий.

SNMP Framework

Simple Network Management Protocol (SNMP) - протокол, предназначенный для сетевого управления удаленных систем. С его помощью можно управлять и получать информацию о состоянии сетевого оборудования или сетевого протокола, реализованного на удаленной системе.

SNMP является не просто протоколом для обмена управляющей информацией между объектами сети. Чаще всего под SNMP понимают Internet-Standard Management Framework или SNMP Framework , т.е. совокупность стандартов описывающих модели и средства использующиеся при сетевом управлении.

SNMP Framework состоит из нескольких частей:

Язык описания информации

Описание протокола

При развитии стандарта от версии к версии, обновляется содержание этих модулей, но основные принципы строения SNMP остаются неизменны.

Причиной модульного строения было желание упростить предполагаемый в скором времени переход от протокола SNMP к протоколам ISO. По этому были созданы протоколо-независимые SMI и MIB. В результате, планы по переходу к OSI не осуществились, но модульное строение SNMP Framework все же сыграло свою роль упростив переход от SNMPv1 к SNMPv2, и от SNMPv2 к SNMPv3.

База данных управляемых элементов

Для управления тем или иным сетевым протоколом или устройством с помощью SNMP, выделяются основные объекты этого протокола или устройства, которые могут предоставлять (для чтения или для изменения) какую-либо информацию о протоколе или устройстве. Все эти объекты являются управляемыми элементами этого протокола или оборудования. Управляемые элементы рассматриваются как объекты виртуального хранилища информации, называемого Management Information Base (MIB). В MIB все эти объекты рассматриваются как переменные, содержащие информацию о представляемом ими объекте. Например, для протокола IP, существует переменная ipDefaultTTL, которая содержит значение по умолчанию для поля TTL в заголовке датаграммы протокола IP, или переменная ipInHdrErrors, предоставляющая информацию о том, какое количество ip-пакетов было отсеено по причине ошибок в их заголовке. Наборы этих переменных определяются в MIB-модулях.

Вообще, MIB имеет структуру дерева, каждый узел которого является переменной MIB. Для нужд сетевого управления сети Internet выделена отдельное поддерево, в котором могут быть определены все требуемые элементы. В одном из поддеревьев этого дерева содержатся все управляемые элементы сети Internet. Раньше вся эта ветка определялась одним MIB-модулем.

Позже, после публикации второй версии этого MIB-модуля, был принят другой подход к созданию базы управляемых элементов. До этого существовал единственный комитет, работающий над документом, описывающим Стандартный MIB для Internet. Теперь же принято разделение на группы, каждая из которых специализируется в одной из областей сетевых технологий. Небольшие MIB-модули разработанные каждой группой, составляют единый Internet MIB. Т.о. теперь поддерево сетевого управления Internet описывается не единой спецификацией, входящей в состав SNMP, а набором отдельных документов, выпускаемых отдельно от Стандартов SNMP.

Язык описания информации

Вся База Управляемых Элементов описывается с помощью упрощенного подмножества стандартного языка OSI, Abstract Syntax Notation One (ASN.1). Это подмножество описывается в документе называемом Structure of Management Information, по этому и весь язык описания информации для SNMP называется SMI. По мимо языка определения данных этот документ описывает также и древовидную структуру MIB и все стандартные поддеревья, которые должны присутствовать во всех реализациях MIB.

Протокол

Эта часть Стандартной Модели описывает протокол, посредством которого происходит обмен информацией между управляемым объектом (называемым агентом ) и управляющей системой (называемой менеджером ). PDU (protocol data unit) протокола SNMP содержит операцию, выполняемую протоколом и список переменных и их значений, участвующих в данной транзакции.

Во всех версиях SNMP определены следующие операции: get, get-next, get-response, set-request. Более поздние версии определяют еще несколько операций. Этот модуль также содержит рекомендации о том, какой транспортных протокол может использоваться для доставки сообщений SNMP. Все версии SNMP, используемые на сегодняшний день содержат рекомендации об использовании транспортных протоколов без установки соединения (UDP).

Безопасность и администрирование

Система сетевого управления SNMP предоставляет достаточно большие возможности для непосредственного управления удаленными системами. По средствам SNMP можно получить доступ к достаточно критическим параметрам системы. Таким образом, проблемы безопасности должны учитываться на каждом этапе проектирования SNMP. В то же время безопасность любого открытого протокола всегда является очень спорным вопросом.

В первой версии SNMP проблемы безопасности практически не учитывались. Этот недостаток SNMPv1 предполагался уже на стадии разработки, т.к. на тот момент основной задачей был скорейший выпуск стандартной модели сетевого управления, в которой нуждалось интернет-сообщество, а обсуждение спорных вопросов безопасности еще на долго затянуло бы разработку стандарта.

Именно тогда проблемы безопасности и администрирования были вынесены в отдельный блок общей модели, рассмотрение которого было оставлено на будущие версии SNMP.

Развитие SNMP

В настоящее время существует три версии SNMP Framework. В следующих трех частях будут кратко описаны изменения произошедшие в каждой версии SNMP и ссылки на документы описывающие компоненты каждой версии SNMP.

SNMPv1

Первоначальным Internet-Standard Management Framework стал SNMPv1, история его развития описана в первой части. Стандарт SNMPv1 содержится в следующих документах:

SNMPv2c - Развитие SNMPv2p, кроме системы безопасности. Содержит дополнение к протоколу и типам данных, определенным ранее. Использует community string-based систему безопасности из первой версии SNMPv1. (RFC-1901 , RFC-1905 , RFC-1906).

SNMPv2u - Отличается от SNMPv2c только подсистемой безопасности. В этой модификации используется user-based подход. (RFC-1905 , RFC-1906 , RFC-1909 , and RFC-1910)

SNMPv2* - сочетает в себе лучшие стороны SNMPv2p и SNMPv2u. (Эта спецификация никогда не издавалась как официальный документ RFC)

Существовали также SNMPv1+, SNMPv1.5, SNMP++

Наибольшую поддержку IETF получил SNMPv2c, не использующий никаких нововведений в области безопасности. Он стал наиболее распространенным и используемым в интернет-сообществе. Описание этой вариации SNMPv2 Framework содержится в следующих документах:

На данный момент большинство из вышеперечисленных документов заменено их более новыми версиями и издано со статусом Стандарта. Документы, представляющие SNMPv2c на сегодняшний день, приведены в таблице в заключительной части данной.

SNMPv3

Итак, проект SNMPv2 не выполнил поставленных перед ним целей. Не было разработано стандартоного средства сетевого управления, удовлетворявшего интернет-сообщество в плане безопасности. Теперь, все эти проблемы должна была решить рабочая группа SNMPv3 (SNMPv3 WG), созданная IETF. Ей предстояло разработать единый стандарт для нового поколения SNMP. Единственной критической неразрешенной проблемой оставалась система безопасности и администрирования, по этому все силы рабочей группы были брошены на разрешение этой проблемы.

В руках SNMPv3 WG имелись предыдущие разработки и результаты работ других проектов, посвященных безопасности в SNMP:

От рабочей группы SNMPv3 требовалось найти точки соприкосновения всех концепций безопасности и администрирования представленных ранее. Также в ее задачи входило:

соответствие требованиям широкого спектра существующих сетевых окружений, имеющих различные потребности в управлении.

простота перехода от предыдущих версий SNMP к использованию SNMPv3.

простота установки и сопровождения

Части нового стандарта, не связанные с проблемами безопасности, такие как SMI, MIB, протокол, были заимствованы из SNMPv2. Таким образом, многие документы из спецификации SNMPv2 Framework получили статус стандарта и перешли в SNMPv3 Framework.

Спецификация SNMPv3 Management Framework была разделена на множество частей, каждая из которых представлена отдельным документом. Таким образом, в любой документ могли быть внесены поправки и обновления не затрагивая при этом другие элементы Модели.

В конечном счете, все документы спецификации SNMPv3 могут быть разделены на те же категории, на которые делились документы всех предыдущих версий SNMP:

Язык описания информации

База данных управляемых элементов

Описание протокола

Решение проблем безопасности и администрирования

Первые три части взяты из SNMPv2, а последняя часть является результатом основной работы проекта SNMPv3 и других проектов, разработавших концепции безопасности SNMP.

SNMPv3 WG был представлен следующий набор документов, описывающих третью версию стандартную модель сетевого управления:

Рисунок 1. Средний входящий трафик на машине iota.cs.prv

Заключение

Итак, описание любой версии SNMP Framework разделено на четыре части. Их взаимодействие определяется следующим образом.

Доступ к управляемым объектам осуществляется через виртуальное хранилище информации, называемое Management Information Base (MIB). В качестве протокола для доступа к объектам MIB используется Simple Network Management Protocol (SNMP). Объекты в MIB описываются с помощью механизмов определяемых спецификацией Structure of Management Information (SMI), предоставляющей свой язык определения информации. При любом взаимодействии объектов SNMP Framework учитывается система безопасности и администрирования принятая в данной версии SNMP.

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

Как уже говорилось ранее, ситуация с описанием MIB несколько изменилась после выхода первой версии SNMP. Следующие версии уже не включали в себя единый стандартный MIB, описывающий все, требуемые для управления, объекты сети. Последние две версии Стандарта включают в себя только модуль MIB, содержащий описание переменных для работы с объектами протокола SNMP, а также переменные, описывающие состояние системы, на котором расположен агент SNMP. Остальное содержимое документа RFC-1213 , описывавшего MIB-II первой версии SNMPv1 разделено на несколько частей, каждая из которых содержится в отдельном документе. Теперь совокупность этих модулей образует MIB-II. В свою очередь MIB-II это модуль описывающий сетевые объекты используемые в Internet.

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

Основным языком описания модулей MIB на сегодняшний день является SMIv2, который является рекомендованным стандартом IETF. Более того, IETF требует, чтобы все новые MIB модули были описаны с помощью SMIv2. Одновременно с этим все еще используется SMIv1, который также является стандартом, но без статуса рекомендации. Стандарт SMIv1 не был объявлен устаревшим, т.к. существует большое количество документов опирающихся на спецификацию SMIv1 и многие коммерческие организации еще долгое время после выпуска стандарта SMIv2 пользовались SMIv1. По этому объявление SMIv1 устаревшим потребовало бы изменения и пересмотра очень большого количества спецификаций. Тем более, что одновременное использование SMIv1 и SMIv2 не вносит особых проблем в систему сетевого управления, т.к. SMIv2 совместим со SMIv1. SNMPv2 и SNMPv3, работающие со SMIv2 могут корректно обрабатывать модули описанные с помощью SMI. SNMPv1 воспринимает только SMIv1 и не может полноценно работать с модулями описанными с помощью SMIv2, т.к. SMIv2 содержит новые типы данных. Проблемы совместной работы нескольких версий SNMP, в том числе и проблемы SMIv1/SMIv2 рассматриваются в документах RFC-2576 и RFC-3584 .

Таким образом, на сегодняшний день SMIv2 является рекомендованным стандартом IETF, а SMI является стандартом без статуса рекомендации.

На данный момент существует большое количество (около 10000) MIB-модулей, описывающих объекты для управления почти всеми известными сетевыми протоколами и устройствами. Информацию обо всех MIB-модулях можно найти на сайте http://www.mibdepot.com .

Большинство современных типов сетевого оборудования поддерживает протокол SNMP. Данный стандарт считается очень простым по структуре. Его внедрение осуществить в современных компаний несложно. Управление компьютерами посредством соответствующего протокола может быть осуществлено с применением широкого спектра программных решений. Какие основные возможности имеет SNMP? Каким образом задействуется соответствующий протокол на практике?

Что представляет собой протокол SNMP?

Для начала изучим основные сведения о рассматриваемой технологии. Что это — SNMP? Данная как Simple Network Management Protocol, и означает «Простой протокол сетевого управления». Данный стандарт относится к числу самых распространенных, что задействуются в целях управления различными девайсами в IP-сетях, функционирующих на базе архитектуры TCP/IP. Например, роутерами, коммутаторами, рабочими станциями, сетевыми принтерами.

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

Возможности SNMP

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

Рассмотрим теперь то, какие ключевые компоненты формируют инфраструктуру сетей, работающих на основе SMTP.

SNMP: основные компоненты

SNMP — протокол, который предполагает задействование нескольких сетевых компонентов. К основным можно отнести:

Управляемый объект — компьютер или приложение, на которое отправляет те или иные команды с использованием протокола, о котором идет речь, администратор сети;

База данных MIB;

Приложение-агент;

Программа-менеджер;

Система обеспечения сетевого взаимодействия.

Управляемый объект может не только получать команды от администратора, но и направлять их — в соответствии с заданными параметрами. Данные с объекта передаются на программу-менеджер, которая по устаноленным алгоритмам интерпретирует их. В свою очередь, на управляемом девайсе функционирует приложение-агент. Оно собирает информацию по соответствующему устройству и при необходимости транслирует ее в формате, адаптированном к специфике протокола SNMP.

Система обеспечения сетевого взаимодействия позволяет администратору работать с несколькими программами-менеджерами в целях осуществления контроля над функционированием инфраструктуры. В сетях может инсталлироваться при этом несколько разновидностей ПО соответствующего типа.

Важнейший, возможно, ключевой элемент протокола SNMP — MIB, или база управляющих сведений. Ее предназначение — в описании структуры данных, обмен которыми осуществляется в процессе управления девайсами. Фактически, соответствующая база данных позволяет разместить информацию, что задействуется для управления устройством, непосредственно на нем, будь то модем, сервер или, к примеру, SNMP — это универсальный протокол, и во многом его функциональность возможно реализовать благодаря, прежде всего, возможностям базы данных MIB.

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

Приложение-агент, являющееся компонентом сетевой инфраструктуры SMNP, обычно получает запросы с использованием порта 161. В свою очередь, программа-менеджер может задействовать любые порты, доступные в сети. При этом уведомления данный тип ПО получает обычно на порт 162.

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

Программа-менеджер в рамках протокола SNMP: основные возможности

Данный вид ПО позволяет благодаря возможностям рассматриваемого протокола осуществлять управление группами самых разных устройств в рамках сетевой инфраструктуры. Программа, о которой идет речь, может функционировать при условии предварительной инсталляции на девайсах, которые управляются посредством ее интерфейсов, специального приложения-агента, о котором мы сказали выше. Оно передает на сервер администратора необходимые данные с использованием протокола SNMP. В свою очередь, на стороне главного ПК функционирует рассматриваемая программа-менеджер, которая осуществляет обработку сведений, поступающих с управляемых девайсов.

Какое ПО применяется для управления сетью по протоколу SNMP?

Какие конкретно программы могут использоваться в качестве управляющих? В принципе, есть решения, адаптированные к внедрению в самых разных операционных системах протокола SNMP — Windows, Solaris. Если говорить о ПО для Windows, то в числе популярных, работающих в данной ОС и задействующих SNMP, — пакет, выпущенный Castle Rock Computing. В свою очередь, для Solaris разработано другое эффективное решение — Sun NetManager. Посредством обоих вариантов может быть выстроена эффективная базирующаяся на протоколе SNMP карта сети. Кроме того, они позволяют осуществлять прямую коммуникацию с MIB.

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

Еще одно популярное решение для управления сетевыми девайсами — Zabbix. SNMP — протокол, который данная программа также задействует. Соответствующее решение обладает большим количеством функций.

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

Особенности SNMP-сообщений

К основным сообщениям, обмен которыми может инициировать посредством протокола SNMP сервер администратора, относятся такие команды, как:

GetNextRequest;

GetBulkRequest;

InformRequest.

Сущность 1-й команды заключается в отправке запроса от программы-менеджера к приложению-агенту в целях получения того или иного значения по переменной — одной или по списку. В свою очередь, программа-менеджер получает ответ с определенными значениями.

Специфика 2-й команды заключается в отправке сообщения также от программы-менеджера к приложению-агенту, но в данном случае в целях корректировки переменной — одной или по списку. Приложение-агент принимает изменения, после чего направляет программе-менеджеру новые значения по тем или иным переменным.

Сущность 3-й команды заключается в отправке запроса от программы-менеджера к приложению-агенту определенных команд в целях обнаружения на девайсе всех доступных переменных, а также значений, которые установлены для них. В свою очередь, приложение-агент возвращает ответ, в котором содержится значение одной переменной, а также ссылка на следующую соотносительно с ее позицией в списке. Следующий запрос предполагает передачу данных, отражающих сведения по следующей переменной, а также ссылку на ту, что идет далее в очереди. В дальнейшем алгоритм оборота данных с использованием рассматриваемой SNMP-команды повторяется.

Специфика 4-й команды заключается в том, что по сути она является модернизированной версией сообщения GetNextRequest. Она предполагает, что приложение-агент передаст программе-менеджеру ответ, содержащий данные по нескольким переменным одновременно, начиная с той, что представлена в изначальном запросе.

Сущность 5-й команды — в осуществлении процедуры возврата связанной переменной, а также значений от приложения-агента к программе-менеджеру при использовании 4 типов сообщений, рассмотренных выше. При этом посредством соответствующей команды между девайсами осуществляется обмен сообщениями об ошибке.

Специфика 6-й команды — в осуществлении передачи сообщений от приложения-агента без предварительного запроса со стороны программы-менеджера. В структуре данного сообщения присутствует текущее значение по переменной. Отметим, что получатель команды в данном случае определяется посредством особых конфигураций в рамках базы MIB.

Сущность 7-й команды заключается в том, что она, фактически, соответствует уведомлению об отправке сообщения от программы-менеджера к приложению-агенту и наоборот. Ее применение обусловлено тем, что в сетевой инфраструктуре те или иные сообщения в ряде случаев могут доставляться некорректно. Команда InformRequest, по сути, подтверждает факт успешной передачи команды от одного девайса к другому.

Корректная настройка SNMP во многих случаях требует от администратора повышенного внимания проверке функциональности базы MIB. Рассмотрим то, в чем заключаются ее особенности.

MIB: особенности функционирования базы

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

Имя переменной в рамках базы MIB отражает адрес до нее, начиная от корневого каталога. В структуре переменной могут содержаться самые разные сведения, например, о времени работы девайса. В древообразной структуре MIB могут присутствовать как стандартные ветви, которые поддерживаются большинством девайсов, или же те, что добавлены производителем устройства либо организацией, в которой внедряется инфраструктура компьютерной сети. Главное в данном случае — правильно разместить соответствующие наборы переменных.

Так, если они внедряются в структуру MIB временно, то их имеет смысл разместить в разделе experimental. Непосредственно перед утверждением следует присвоить набору переменных отдельный номер. Для этого используется раздел private-enterprises. Это позволит инженерам или администраторам сети, в компетенции которых — SNMP-мониторинг и решение других задач по обеспечению функционирования инфраструктуры, открыть новую ветвь в структуре MIB для того, чтобы размещать переменные только от своей компании.

История появления SMNP

Интересно будет изучить сведения об истории разработки SNMP. Основная программная среда, в которой сейчас задействуется протокол SNMP — Windows. Однако, инициирована была его разработка еще в 1988 году - задолго до того, как операционная система от Microsoft, представленная в привычных интерфейсах, начала завоевывать рынки. Фактически, изначально SNMP разрабатывался для UNIX — семейства операционных систем, предназначенных для решения широкого круга задач по обеспечению функциональности различных компьютерных сетей. Хотя, безусловно, к тому моменту многие эксперты видели потенциал Windows, и не исключено, что разработка универсального сетевого протокола была во многом предопределена фактом потенциального роста популярности новой операционной системы.

Безусловно, был еще один фактор, сыгравший важную роль в ускорении работы над SNMP, — Web. Уже тогда появились первые онлайн-сервисы, и экспертам было понятно, что впереди — активная интеграция сетевых интерфейсов в мировом масштабе.

Так или иначе, крупнейшие производители сетевых девайсов в 1988 году решили, что им необходимо разработать универсальный набор средств, предназначенных для управления устройствами. К тому моменту фирмы выпускали собственные решения для осуществления мониторинга, а также конфигурирования девайсов. Нужна была унификация.

Разработка SNMP: основные инструкции

В августе 1988 года предприятия, выпускающие сетевое оборудование, пришли к консенсусу. В процессе разработки нового протокола были применены некоторые уже действовавшие концепции. Специалисты, которые проводили совместную работу, выявили 3 ключевых документа: RFC 1065, 1066, а также 1067. Впоследствии они были дополнены, и появились новые — RFC 1155, 1156, а также 1157. Данные источники были переработаны, и в 1991 году на их основе была выпущена первая версия протокола SNMP.

Так, документ RFC 1155 содержал в себе инструкции, определяющие:

То, в какой структуре должна отражаться управляющая информация;

То, каковы основные принципы применения синтаксиса при определении имен для переменных.

Документ RFC 1155 был дополнен источником RFC 1212 в части, опять же, синтаксиса переменных. На момент утверждения протокола SMNP был разработан ряд новых документов, таких как RFC 1213. В нем отражался список ключевых переменных, посредством которых должна была осуществляться конфигурация сетевой инфраструктуры.

Источник RFC 1157 содержал параметры, необходимые для:

Определения команд, посредством которых сервер и управляемый объект могли взаимодействовать между собой;

Осуществления обмена trap-сообщениями.

Как только был опубликован и введен протокол SNMP, адаптер, сервер — в принципе, любой девайс, который входил бы в инфраструктуру сети, мог становиться объектом управления, осуществляемого в рамках стандартных процедур. Введение SNMP стало сильнейшим фактором роста мирового рынка сетевого оборудования. Также благодаря стандартизации стало возможным внедрение в самых широких масштабах новых интерфейсов, таких как, например, Ethernet, FDDI.

Резюме

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

Посредством стандартизованных сообщений в рамках протокола SNMP осуществляются:

Запросы одного или нескольких параметров MIB;

Последовательное прочтение различных значений по тем или иным параметрам, например, табличным;

Установка конкретных значений для одной или же нескольких переменных MIB;

Возврат девайсом ответа на тот или иной запрос другого устройства;

Отправка уведомительных сообщений о тех или иных сетевых процессах.

Алгоритмы MIB могут быть как общие для всех девайсов, так и те, что прописываются производителями для конкретных типов сетевого оборудования.

Что это — SNMP с точки зрения значения для современного IT-рынка? Данная технология, очевидно, в числе важнейших, и во многих случаях не имеющая альтернативы. И это несмотря на ее простоту, которая, однако, стала результатом многолетних разработок и согласований сетевых стандартов при участии ведущих производителей оборудования.

Сетевые коммуникации, в рамках которых задействуются возможности протокола MIB, предполагают использование программ-менеджеров, а также приложений-агентов. Первые направляют различные команды вторым, после чего программное обеспечение девайса осуществляет выполнение определенных алгоритмов. Также осуществляется передача данных по установленным схемам от приложения-агента к программе-менеджеру.

Управление компьютерами сети может осуществляться с главного сервера. Для этого может быть задействована специальная программа, например, Zabbix. SNMP — протокол, поддерживаемый программами, способными работать в разных операционных системах. Изначально SNMP разрабатывался для UNIX, но были созданы виды ПО, которые позволили его применять в ОС Windows, Sun Solaris.

Таким образом, что это — SNMP? Международный стандарт, позволяющий, прежде всего, интегрировать решения от разных производителей. Изначально алгоритмы управления ими бренды задавали свои собственные. Но благодаря разработке SNMP у них появилась возможность задействовать унифицированные команды, что стимулировало спрос на выпускаемые сетевые девайсы, стало эффективным драйвером роста рынка соответствующего типа оборудования.