Главная | Контакты | Настройки СМЕНИТЬ ПАЛИТРУ:

Главная > Технологии > Протокол > SNMP

Введение в SNMP

Иваненко С.

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

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


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

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

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


Основной концепцией протокола является то, что вся необходимая для управления устройством информация хранится на самом устройстве - будь то сервер, модем или маршрутизатор - в так называемой Административной Базе Данных ( MIB - Management Information Base ).

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

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

Поэтому SNMP как непосредственно сетевой протокол предоставляет только набор команд для работы с переменными MIB. Этот набор включает следующие операции:

get-request Используется для запроса одного или более параметров MIB
get-next-requestИспользуется для последовательного чтения значений. Обычно используется для чтения значений из таблиц. После запроса первой строки при помощи get-request get-next-request используют для чтения оставшихся строк таблицы
set-requestИспользуется для установки значения одной или более переменных MIB
get-responseВозвращает ответ на запрос get-request, get-next-request или set-request
trapУведомительное сообщение о событиях типа cold или warm restart или "падении" некоторого link'а.

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


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

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


Как происходит адресация в MIB к некоторой ее переменной?

По своей структуре MIB представляет из себя дерево, изображенное на рисунке 1.

Каждому элементу соответствует численный и символьный идентификатор. В имя переменной включается полный путь до нее от корневого элемента root.

Например, время работы устройства с момента перезагрузки хранится в переменной, находящейся в разделе system под номером 3 и называется sysUpTime. Соответственно, имя переменной будет включать весь путь: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3); или на языке чисел: 1.3.6.1.2.1.1.3. Следует заметить, что при этом узлы дерева разделяются точками.

Существует стандартная ветвь MIB, относящаяся к разделу управления mgmt, которую обычно поддерживают все сетевые устройства.


Наряду с этим каждый производитель или организация может разработать свой собственный набор переменных и "подвесить" их к дереву MIB. Однако, это делается только в строго определенном ее месте. Если организация разрабатывает свою базу MIB, то на стадии экспериментов переменные могут помещаться в раздел experimental. Однако для официальной регистрации структуры данных некоторой организации ей необходимо получить собственный номер в разделе private-enterprises. Все переменные, адресуемые вниз по ветви данной организации, относятся к продуктам только данного производителя.


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

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

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


Примерами таких программ можно назвать Sun NetManager фирмы Sun Microsystems, ориентированный на операционную систему Solaris, и пакет SNMPc фирмы Castle Rock Computing, разработанный для системы Windows.

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

Так, например, чтобы управлять маршрутизатором cisco, можно войти на него (сделать login пользователем root) и получить on-line доступ к его командам управления. А можно сконфигурировать на данном маршрутизаторе SNMP агента и выполнять все те же команды и получать те же результаты путем работы с переменными его MIB.

Как пример такой операции можно просто перегрузить маршрутизатор путем изменения одной переменной его MIB. При этом существуют отдельные команды для загрузки системы из flash-памяти, NVRAM, или TFTP файла.


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

Так, например, для раздела, относящегося к интерфейсам Ethernet, определен тест TDR (Time-domain reflectometry), позволяющий определять приблизительное расстояние до повреждения в коаксиальном кабеле. Для того, чтобы запустить TDR тест необходимо установить значение переменной ifExtnsTestTypе (1.3.6.1.2.1.12.2.1.4), содержащей тип выполняемого теста, так, чтобы она содержала идентификатор теста TDR в MIB: 1.3.6.1.2.1.10.7.6.1.

Результатом теста будет, во-первых, значение переменной ifExtnsTestResult (1.3.6.1.2.1.12.2.1.5), характеризующей исход теста:

  1. отсутствие результата
  2. успех
  3. выполняется
  4. не поддерживается
  5. невозможно запустить
  6. прекращен
  7. неудачное завершение

И во-вторых, значение переменной ifExtnsTestCode (1.3.6.1.2.1.12.2.1.6) будет содержать идентификатор переменной MIB, содержащей результат теста. Результат теста определен как временной интервал в 100-наносекундных единицах между началом передачи тестового пакета и обнаружением коллизий в несущей. В принципе, на основании данного значения можно определить требуемое расстояние.


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

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


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

  • Отправка и прием пакетов SNMP через протокол IP.
  • Сбор информации о статусе и текущей конфигурации сетевых устройств.
  • Изменение конфигурации сетевых устройств.

В состав DES-3226S входит программа, называемая "агент", которая обрабатывает SNMP-запросы, но пользовательская программа, делающая запросы и собирающая ответы, работает на станции управления (определенный компьютер сети). SNMP-агент и пользовательская программа используют протокол UDP/IP для обмена пакетами.

SNMP Версий 1,2 и 3
DES-3226S поддерживает SNMP версии 3, также как и версии 1 и 2. Главное отличие SNMP v.3 от SNMP v.1 и SNMP v.2 в том, что SNMP v.3 предоставляет в значительной степени более высокий уровень безопасности, чем предыдущие версии.
В SNMP v.1 и SNMP v.2 авторизация пользователя выполняется посредством "строки сообщества" - Community String, которая действуют как пароль. Удаленная пользовательская программа SNMP и агент SNMP должны использовать одни и те же Community Strings. Пакеты SNMP от любой станции, которая не была авторизована, игнорируются (отбрасываются).
SNMP v.3 используют более сложный процесс авторизации, который разделяется на две части. Первая часть используется для поддержания списка пользователей и их атрибутов, которым разрешено управлять по протоколу SNMP. Вторая часть описывает, что каждый пользователь из данного списка может делать при управлении по SNMP.
Коммутатор позволяет указывать и настраивать группы пользователей в данном списке с одинаковым набором привилегий. Для указанных групп может быть установлена версия SNMP. Таким образом, можно создать группу SNMP, которой разрешено просматривать информацию, предназначенную только для чтения, или получать сообщения traps, используя SNMP v.1, в то время как другой группе назначен более высокий уровень безопасности, предоставляющий привилегии чтения/записи, посредством SNMP v.3.
Используя SNMP v.3 можно позволить или запретить индивидуальным пользователям или группам SNMP-менеджеров выполнять конкретные функции SNMP-управления. Разрешенные или запрещенные функции определяются с помощью идентификатора объекта Object Identifier (OID), ассоциированного с конкретной MIB.
Кроме того, в SNMP v.3 доступен уровень безопасности, в котором SNMP-сообщения могут быть зашифрованы (при использовании уровней авторизации HMAC-SHA-96 или HMAC-MDA-96).

Traps
Traps - это сообщения, которые предупреждают о произошедших событиях при работе коммутатора. События могут быть как серьезными типа перезагрузки (кто-то случайно отключил питание коммутатора), так и менее серьезными типа изменения состояния порта. Коммутатор генерирует traps и посылает их станции сетевого управления.
Администраторами traps являются особые пользователи локальной сети, которым представляются некоторые права и доступ к просмотру и поддержке сети. Администраторы получают отправленные коммутатором traps и должны предпринять некоторые действия для предотвращения сбоев в будущем или отключения сети.
Вы можете определить станции управления, которые могут получать traps от коммутатора. Это можно сделать путем ввода списка IP-адресов авторизованных станций сетевого управления. Вы также можете указать версию SNMP, используемую для авторизации. Можно ввести до четырех IP-адресов администраторов traps и четыре соответствующих SNMP Сommunity strings.
Ниже приводятся типы сообщений traps, которые могут получать администраторы:

  • Cold Start Данное сообщение означает, что коммутатор был включен и инициализирован так, что все программные настройки были восстановлены, а аппаратные компоненты были перезагружены. "Холодный" старт отличается сброса коммутатора к заводским установкам тем, что настройки сохраняются в энергонезависимой памяти, используемой для восстановления конфигурации коммутатора.
  • Warm Start Данное сообщение означает, что коммутатор был перезагружен (только программно), но тест по самодиагностике при включении питания (Power-On Self-Test - POST) был пропущен.
  • Authentication Failure Данное сообщение означает, что кто-то пытается подключиться к коммутатору, используя неверную "строку сообщества" SNMP - Community string. Коммутатор автоматически запоминает IP-адрес неавторизированного пользователя.
  • Topology Change Сообщение Topology Change (изменение топологии) посылается коммутатором, когда любой из его сконфигурированных портов переходит из состояния Learning в Forwarding, или из состояния Forwarding в Blocking. Данный trap не генерируется, если при том же изменении состояния порта был послан new root trap.
  • Link Change Event Данное сообщение посылается каждый раз, когда состояние порта меняется с link up на link down или с link down на link up.
  • Port Partition Данное сообщение посылается каждый раз, когда состояние порта изменяется на partition (порт блокируется) в результате возникновения более чем 32 коллизий на нем при работе на скорости 10 МБит/с или более чем 64 коллизий при работе на скорости 100 МБит/с.
  • Broadcast\Multicast Storm Данное сообщение посылается каждый раз, когда на порту преодолевается пороговое значение пакетов широковещательной/групповой рассылки. (количество пакетов в секунду), установленное глобально для коммутатора. На каждом порту поддерживаются раздельные счетчики для широковещательных пакетов и для пакетов групповой рассылки. Пороговое значение по умолчанию равно 128 тысяч пакетов/с как для широковещательной рассылки, и так и для групповой рассылки.

MIB
Управляющая информация и параметры коммутатора хранятся в информационной базе управления (Management Information Base -MIB). Коммутатор использует стандартный модуль информационной базы управления MIB-II. Следовательно, значения входящих в MIB объектов могут быть получены с помощью любых средств сетевого управления, основанных на SNMP. Кроме стандарта MIB-II, коммутатор также поддерживает собственную MIB в виде расширенной информационной базы управления. Объекты этой MIB также могут быть получены путем указания менеджером OID MIB (Object Identifier, идентификатор объекта MIB). Значения объектов MIB могут быть как открытыми только для чтения (read-only), так и для чтения и для записи (read-write).
Объекты read-only MIB могут быть константами, которые запрограммированы в коммутаторе, или переменными, которые изменяются в процессе работы коммутатора. Примерами констант read-only являются количество портов и их типы. Примерами переменных read-only являются статистические значения, такие как количество произошедших ошибок, или сколько Кбайт данных было получено и передано через порт.
Объекты read-write MIB обычно связаны с настройками, осуществляемыми пользователем. Например, ими являются IP-адрес коммутатора, параметры Spanning Tree Algorithm, состояние порта.
Если для управления коммутатором используется система управления SNMP третьих поставщиков, то по запросу можно получить дискету, содержащую MIB коммутатора. Если эта система предоставляет функции просмотра или модификации MIB, то можно получать параметры MIB и изменять их (если атрибуты MIB допустят операцию записи). Тем не менее, процесс получения объектов MIB может быть только последовательным, поскольку нужно знать OID MIB и получать объекты один за другим.


Главная > Технологии > Протокол > SNMP