Характеристика протокола сетевого управления (SNMP)

Размещено на http://www.allbest.ru

Введение

SNMP есть Simple Network Management Protocol, он же Простой Протокол Сетевого Управления. Протокол создан в 1988 г. с целью управления большим количеством сетевых устройств. С того момента протокол набрал соответствующую популярность и стал стандартом. С момента разработки протокол SNMP был 3 раза переработан с версии SNMPv1, SNMPv2 и SNMPv3. На самом деле, версий было больше, например v2 была пересмотрена 2 раза (или даже более). Так же стоит отметить, что кроме SNMP были и другие попытки создать коммерческие и не коммерческие протоколы управления (CORBA, TMN) не увенчавшиеся успехом.

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

Содержимое получаемой информации может быть очень разнообразно, например: время аптайма, различные счетчики производительности CPU, сети и др., сетевые параметры устройств.

1. Архитектура протокола 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 (Request ID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.

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

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

· Trap - одностороннее уведомление от SNMP агента -> менеджеру о каком-либо событии.

· Get Reponse - ответ от агента к менеджеру, возвращающий запрошенные значения переменных.

· Get Request - запрос к агенту от менеджера, используемый для получения значения одной или нескольких переменных.

· Get Next Request - запрос к агенту от менеджера, используемый для получения следующего в иерархии значения переменной.

· Set Request - запрос к агенту на установку значения одной или нескольких переменных.

· Get Bulk Request - запрос к агенту на получение массива данных (тюнингованная Get Next Request). (Этот PDU был введен в SNMPv2.)

· Inform Request - одностороннее уведомление между менеджерами. Может использоваться, например, для обмена информацией о MIB (соответствие символьных OID - цифровым). В ответ менеджер формирует аналогичный пакет в подтверждение того, что исходные данные получены. (Этот PDU был введен в SNMPv2.)

Как видно, в зависимости от версии протокола, набор команд разный (например, Inform Request и GetBulk Request полноценно появился только во второй версии SNMP). Компонент SNMP MIB рассмотрим ниже.

Структура PDU

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

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

· версия - содержит версию SNMP.

· пароль (community) - содержит последовательность символов, описывающую принадлежность к группе (об этом ниже).

· тип PDU имеет цифровой идентификатор запроса (Get, Get Next, Set, Responde, Trap).

· идентификатор запроса - это тот самый набор символов, который связывает в единое целое запрос \ ответ.

· Статус ошибки - это число, характеризующее характер ошибки:

· Для запросов (Get, Set, Get NExt и др.) - 0

· Для ответов:

· 0 (No Error) - Нет ошибок,

· 1 (Too Big) - Объект не вмещается в одно Response сообщение,

· 2 (No Such Name) - не существующая переменная,

· 3 (Bad Value) - при попытке установить значение задано недопустимое значение или совершена синтаксическая ошибка,

· 4 (Read Only) - при Set запросе была попытка изменить read-only переменную,

· 5 (Gen Err) - другие ошибки.

· Индекс ошибки - не нашел внятного описания но смысл в том, что содержит некий индекс переменной, к которой относится ошибка.

· Поле связанные переменные может содержать одну или более переменную (для запросов Get - это только имя переменных, для Set - имя и устанавливаемое значение, для Response - имя и запрошенное значение).

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

· Фирма - характеризующее производителя хоста.

· Тип trapуведомления, может быть следующим:

o 0 (Coldstart) и 1 (Warmstart) - объект возвращен в начальное состояние (между ними имеется некая разница, но какая?),

o 2 (Linkdown) - интерфейс опущен, при этом, поле переменной содержит интерфейс, о котором идет речь,

o 3 (Linkup) - интерфейс поднялся, при этом, поле переменной содержит интерфейс, о котором идет речь,

o 4 (Authenticationfailure) - менеджер прислал мессадж с неверной строкой community,

o 5 (EGPneighborloss) - затрудняюсь, что-либо сказать,

o 6 (Entrprisespecific) - данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.

· Специализированный тип Trap - описан выше

· Метка времени - содержит метку времени с момента события (непонятно, относительно чего эта метка).

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

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

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

· Принимающая сторона первым делом пытается декодировать сообщение. Если принимающей стороне не удается раскодировать PDU, то пакет отбрасывается без каких-либо действий.

· Если версия SNMP в пришедшем пакете не соответствует версии сервера, то пакет так же дропается.

· После этого, сверяется аутентификационная информация (либо значение строки community, либо пользовательская информация). Могут применяться внешние модули для аутентификации (об аутентификации - ниже).

· Далее, происходит обработка сообщения. Если необходимо - генерируется ответ.

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

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

1. Если имя переменной не совпадает в точности с именем одной из переменной, доступной для операции get в нашей MIB, передаем отправителю запроса аналогичное PDU Get Response, указывая в поле кода ошибки значение no Such Name (2-нет такого имени). А в поле error-index -- индекс имени вышеупомянутого объекта в полученном сообщении (=1, в SNMPv1 - ограничение данной реализации SNMP).

2. Если размер PDU Get Response, созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение. Реализация SNMP не обязана принимать сообщения, размер которых превышает определенное значение. Однако по возможности желательна поддержка дейтаграмм больших размеров (RFC1157 SNMP), передаем отправителю аналогичное PDU Get Response, указав в поле errorstatus значение Too Big, а в поле error-index -- 0. Это обычно происходит, если запрошено больше 1 переменной или длина PDU или общая длина пакета больше стандартных пределов.

3. Если для любой переменной, содержащейся в поле связанные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, SNMP агент передает отправителю аналогичное PDU Get Response, указав в поле error-status значение Gen Err, а в поле error-index -- индекс имени вышеупомянутого объекта в полученном сообщении.

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

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

1. Если после переменной, указанной в запросе, нет следующей переменной, то передаем отправителю запроса менеджеру PDU Get Response (с содержимым аналогичным исходному запросу), указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index -- индекс имени вышеупомянутого объекта в полученном сообщении (=1 для SNMPv1), значение переменной = NULL (кажется).

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

3. Если для любой переменной в поле связанные переменные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, принимающий объект передает менеджеру PDU с исходным содержимым Get Response, указав в поле error-status значение gen Err, а в поле error-index -- индекс имени вышеупомянутого объекта в полученном сообщении.

4. Если все нормально, передаем SNMP менеджеру, отправившему PDU, такое сообщение Get Response, в котором для каждой переменной в поле связанные переменные содержится имя и значение переменной, иерархически следующей за запрошенной переменной в базе MIB. В поле error-status помещается значение no Error, а в поле error-index -- 0. Значение поля request-id в ответном PDU Get Response совпадает с идентификатором в принятом сообщении.

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

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

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

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

4. Если для любой переменной в поле связанные переменные, значение переменной не может быть установлено по причинам, которые отличаются от перечисленных выше, SNMP агент передает менеджеру PDU с исходным содержимым Get Response, указав в поле error-status значение gen Err, а в поле error-index -- индекс имени вышеупомянутого объекта в полученном сообщении.

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

4. 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 (и некоторые другие).

Дерево объектов MIB подобно системе DNS (Domain Name System). Тут аналогично имеются символьные имена (аналогично 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 поддеревьев. В данной ветке регистрируют свои поддеревья - производители оборудования.

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

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

5. Безопасность протокола 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 помещается значение No Error, а в поле error-index -- 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении. Определяет различные community строки для чтения переменных и для записи.

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

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

Для того чтобы SNMP менеджер мог работать с символьными именами, OID необходимо подсунуть ему соответствующие файлы 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 появятся следующие инструменты (перечислены не все):

· snmptranslate - Перевод MIB OID имён между цифровой и текстовой представлениями.

· snmpget - Взаимодействует с агентом, используя PDU Get Request запросы.

· snmpgetnext - Взаимодействует с агентом, используя PDU Get Next Request запросы.

· snmpbulkget - Взаимодействует с агентом, используя PDU Get Bulk Request запросы.

· snmpwalk - Получает поддерево объектов OID из MIB базы агента с помощью PDU Get Next Request запросов. Если OID не задан, то команда получает дерево, начиная от MIB-2 (iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1))

· snmpbulkwalk - Получает поддерево объектов OID из MIB базы агента с помощью PDU Get Bulk Request запросов.

· snmpset - Взаимодействует с агентом, используя PDU Set Request запросы.

· 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::.

SNMP в Debian.

Политика лицензирования Debian определяет базы MIB, как не свободное ПО, поэтому они не расположены в свободных репозитоиях, а размещены в non-free репозиториях. Для того чтобы базы корректно установились, необходимо данный репозиторий прописать в /etc/apt/sources.list, например:

snmp-protocol # grep non /etc/apt/sources.list

deb http://ftp.de.debian.org/debian stable main contrib non-free

и установить пакет snmp-mibs-downloader. (в процессе установки данный пакет попытается получить mib-базы из интернета). Так, же, необходимо в /etc/snmp/snmp.conf закомментировать строку:

snmp-protocol # cat /etc/snmp/snmp.conf

#

# As the snmp packages come without MIB files due to license reasons, loading

# of MIBs is disabled by default. If you added the MIBs you can reenable

# loaging them by commenting out the following line.

# mibs.

Заключение

Подводя краткий итог, протокол SNMP базируется на нескольких основных принципах:

1. Менеджер обращается к агенту, запрашивая информацию, которая характеризует состояние устройства, на котором работает агент.

2. Менеджер может указать агенту выполнить изменение конфигурации удаленного хоста, задав значение переменной.

3. Агент может сам сообщать менеджеру о произошедшем важном событии.

4. Вся информация о хосте храниться в древовидной структуре базы MIB.

Список литературы

1. Компьютерные сети и системы. Принципы, технологии, протоколы. / В.Г. Олифер, Н.А. Олифер.- СПб.: Питер, 2001. - 672 с.: ил.

2. Новиков Ю.В., Кондратенко С.В. - Локальные сети: архитектура, алгоритмы, проектирование. М.: Издательство ЭКОМ, 2001. - 312 с.: илл.

3. Наталья Олифер - "Журнал сетевых решений LAN" (июнь 2001), Третья версия SNMP, стр. 28.

Размещено на Allbest.ru