Системы управления сетью на основе протокола SNMP

Модель «менеджер — агент — управляемый объект» лежит в основе таких популярных стандартов управления, как стандарты Интернета на основе протокола SNMP ( Simple Management Network Protocol — простой протокол сетевого администрирования) и стандартов управления ISO/OSI на основе протокола CMIP ( Common Management Information Protocol — протокол общей управляющей информации).

Нет ничего более постоянного, чем временное. Протокол SNMP может служить еще одним подтверждением этой азбучной истины. Разработанный как временное и очень простое решение для IP-сетей, он настолько понравился разработчикам оборудования и сетевым администраторам, что на долгие годы стал протоколом №1 в системах управления. И это несмотря на то, что уже давно существует гораздо более мощный (и, соответственно, сложный) протокол CMIP, к тому же являющийся международным стандартом ITU-T.

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

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

Далее перечислены элементы, которые стандартизуются в системах управления, построенных на основе протокола SNMP.

Все остальное отдается «на откуп» разработчику системы управления.

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

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

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

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

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

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

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

Структура SNMP MIB

На сегодня существует несколько стандартов на базы данных управляющей информации для протокола SNMP. Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON ( Remote Monitoring) MIB. Кроме того, существуют стандарты для специальных MIB-устройств конкретного типа (например, MIB для концентраторов или MIB для модемов), а также частные базы данных MIB конкретных фирм-производителей оборудования.

Первоначальная спецификация MIB-I определяла только операции чтения значений переменных. Операции изменения или установки значений объекта являются частью спецификаций MIB-II.

Версия MIB-I (RFC 1156) определяет 114 объектов, которые подразделяются на 8 групп.

  1. System — общие данные об устройстве (например, идентификатор поставщика, время последней инициализации системы).
  2. Interfaces — параметры сетевых интерфейсов устройства (например, их количество, типы, скорости обмена, максимальный размер пакета).
  3. Address Translation Table — описание соответствия между сетевыми и физическими адресами (например, по протоколу ARP).
  4. Internet Protocol — данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика о IP-пакетах).
  5. ICMP — данные, относящиеся к протоколу обмена управляющими ICMP-сообщениями.
  6. TCP — данные, относящиеся к протоколу TCP (например, о TCP-соединениях).
  7. UDP — данные, относящиеся к протоколу UDP (число переданных, принятых и ошибочных UPD-дейтаграмм).
  8. EGP — данные, относящиеся к протоколу EGP, используемому в Интернете (число принятых с ошибками и без ошибок сообщений).Из этого перечня групп переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на управление маршрутизаторами, поддерживающими протоколы стека TCP/IP.

В версии MIB-II (RFC 1213), принятой в 1992 году, был существенно (до 185) расширен набор стандартных объектов, а число групп увеличилось до 10.

На рис. 1 приведен пример древовидной структуры базы объектов MIB-II. На нем показаны две из 10 возможных групп объектов — System (имена объектов начинаются с префикса Sys) и Interfaces (префикс if).

Рис. 1. Стандартное дерево MIB-II (фрагмент)

Объект SysUpTime содержит значение продолжительности времени работы системы с момента последней перезагрузки, объект SysObjectID — идентификатор устройства (например, маршрутизатора).

Объект ifNumber определяет количество сетевых интерфейсов устройства, а объект ifEntry является вершиной поддерева, описывающего один из конкретных интерфейсов устройства. Входящие в это поддерево объекты ifType и ifAdminStatus определяют соответственно тип и состояние одного из интерфейсов, в данном случае интерфейса Ethernet.

Далее перечислены объекты, описывающие конкретные интерфейсы устройства.

ifType — тип протокола, который поддерживает интерфейс. Этот объект принимает значения всех стандартных протоколов канального уровня, например rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing и т. д.

ifMtu — максимальный размер пакета сетевого уровня, который можно послать через этот интерфейс.

ifSpeed — пропускная способность интерфейса в битах в секунду (100 для Fast Ethernet).

ifPhysAddress — физический адрес порта, для Fast Ethernet им будет MAC-адрес.

ifAdminStatus — желаемый статус порта:

up — готов передавать пакеты;

down — не готов передавать пакеты;

testing — находится в тестовом режиме.

ifOperStatus — фактический текущий статус порта, имеет те же значения, что и ifAdminStatus.

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

ifInUcastPkts — количество пакетов с индивидуальным адресом интерфейса, доставленных протоколу верхнего уровня.

ifInNUcastPkts — количество пакетов с широковещательным или групповым адресом интерфейса, доставленных протоколу верхнего уровня.

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

ifInErrors — количество пришедших пакетов, которые не были переданы протоколу верхнего уровня из-за обнаружения в них ошибок.

Помимо объектов, описывающих статистику по входным пакетам, имеются аналогичные объекты, но относящиеся к выходным пакетам.

Как видно из описания объектов MIB-II, эта база данных не дает детальной статистики по характерным ошибкам кадров Ethernet, кроме того, она не отражает изменение характеристик во времени, что часто интересует сетевого администратора. Эти ограничения были впоследствии сняты новым стандартом на MIB — RMON MIB, который специально ориентирован на сбор детальной статистики по протоколу Ethernet. Возможности RMON MIB включают также построение временн ых зависимостей значений параметров.

Для именования переменных базы MIB и однозначного определения их форматов используется дополнительная спецификация, называемая SMI (Structure of Management Information — структура управляющей информации). Например, спецификация SMI включает в качестве стандартного имя IpAddress и определяет его формат как строку из 4 байт. Другой пример — имя Counter, для которого определен формат в виде целого числа в диапазоне от 0 до 2 32–1.

Имена переменных MIB могут быть записаны как в символьном, так и в числовом форматах. Символьный формат используется для представления переменных в текстовых документах и на экране дисплея, а числовой — в сообщениях протокола SNMP. Например, символьному имени SysDescr соответствует числовое имя 1.3.6.1.2.1.1.1.

Составное числовое имя объекта базы данных MIB протокола SNMP соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO. Разработчики протокола SNMP не стали использовать традиционный для стандартов Интернета способ фиксации числовых параметров протокола в специальном документе RFC. Вместо этого они зарегистрировали объекты баз данных MIB протокола SNMP во всемирном дереве регистрации стандартов ISO (рис. 2).

Рис. 2. Пространство имен объектов ISO

Как и в любых сложных системах, пространство имен объектов ISO имеет древовидную иерархическую структуру, причем на рисунке показана только его верхняя часть. От корня этого дерева отходят три ветви, соответствующие стандартам, контролируемым ISO, ITU и совместно ISO-ITU. В свою очередь, организация ISO создала ветвь для стандартов, создаваемых национальными и международными организациями (ветвь org). Стандарты Интернета создавались под эгидой Министерства обороны ( Department of Defense, DoD) США, поэтому стандарты MIB попали в поддерево dod-internet, а далее, естественно, в группу стандартов управления сетью — ветвь mgmt. Объекты любых стандартов, создаваемых под эгидой ISO, однозначно идентифицируются составными символьными именами, начинающимися от корня этого дерева. В сообщениях протоколов используются не символьные имена, а однозначно соответствующие им составные числовые имена. Каждая ветвь дерева имен объектов нумеруется в дереве целыми числами слева направо, начиная с единицы, и эти числа и заменяют символьные имена. Поэтому полному символьному имени объекта mib iso.org.dod.internet.mgmt.mib соответствует полное числовое имя — 1.3.6.1.2.1.

Группа объектов private (4) зарезервирована за стандартами, создаваемыми частными компаниями, например Cisco, Hewlett-Packard и т. п. Это же дерево регистрации используется для именования классов объектов CMIP и TMN.

Соответственно, каждая группа объектов MIB-I и MIB-II помимо приведенных кратких символьных имен имеет полные символьные имена и соответствующие им числовые имена.

Формат SNMP-сообщений

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

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

Любое SNMP-сообщение состоит из трех основных частей:

Идентификатор общности (community string) служит для группирования устройств, управляемых определенным менеджером. Идентификатор общности является аналогом пароля, так как для того, чтобы устройства могли взаимодействовать по протоколу SNMP, они должны иметь одно и то же значение этого идентификатора (по умолчанию часто используется строка « public»).

В области данных, собственно, и содержатся описанные ранее команды протокола, имена объектов и их значения. Область данных состоит из одного или более блоков PDU, каждый из которых может относиться к одному из пяти различных типов PDU, соответствующих пяти командам протокола SNMP: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU, Trap-PDU. И, наконец, для каждого типа PDU имеется определение его формата. Например, формат блока GetRequest-PDU включает следующие поля:

На рис. 3 показано сообщение протокола SNMP, которое представляет собой запрос о значении объекта SysDescr (числовое имя 1.3.6.1.2.1.1.1).

Рис. 3. Пример SNMP-сообщения

Как видно из рисунка, сообщение начинается с кода 30 (все коды шестнадцатеричные), который соответствует ключевому слову SEQUENCE (последовательность) и говорит о том, что сообщение состоит из последовательности полей. Длина последовательности указывается в следующем байте (41 байт). Далее следует поле, которое представляет собой целое число ( integer) длиной 1 байт — это версия ( vers) протокола SNMP (в данном случае 0, то есть SNMP v.1, а 1 означала бы SNMP v.2). Поле идентификатора общности community имеет тип string (строка символов) длиной в 6 байт со значением public. Остальную часть сообщения составляет блок данных GetRequest-PDU. То, что это операция Get-request, говорит код A0, а общая длина этого блока данных равна 28 байт. В соответствии со структурой блока данных Getrequest-PDU далее идет поле идентификатора запроса (он определен как целое 4-байтное число и имеет значение 05 AE 56 02). Затем в блоке следуют два однобайтовых целых числа статуса и индекса ошибки, которые в запросе установлены в 0. И, наконец, завершает сообщение список имен объектов, значения которых запрашиваются данной командой. Этот список в примере состоит из одной переменной с именем 1.3.6.1.2.1.1.1.0, которое соответствует символьному имени SysDescr. Признак null (значение 05) говорит о том, что достигнут конец сообщения.

Спецификация RMON базы данных MIB

Добавлением к функциональным возможностям SNMP является спецификация RMON, которая обеспечивает удаленное взаимодействие с базой MIB. До появления RMON протокол SNMP не мог использоваться удаленным образом, он допускал только локальное администрирования устройств. База RMON MIB обладает улучшенным набором свойств для удаленного администрирования, так как содержит агрегированную информацию об устройстве, не требующую передачи по сети больших объемов данных. Объекты RMON MIB включают дополнительные счетчики ошибок в пакетах, более гибкие средства анализа трендов и статистики, более мощные средства фильтрации для захвата и анализа отдельных пакетов, а также более сложные условия установления сигналов предупреждения. Интеллектуальность агентов RMON MIB выше, чем агентов MIB-I или MIB-II, что позволяет им выполнять значительную часть работы по обработке информации об устройстве, которую раньше выполняли менеджеры. Эти агенты могут располагаться внутри различных коммуникационных устройств или выполняться в виде отдельных программных модулей на универсальных персональных компьютерах и ноутбуках.

Объекту RMON присвоен номер 16 в наборе объектов MIB, а сам объект RMON объединяет 10 групп объектов (десятую группу составляют специальные объекты протокола Token Ring).

Данные группы пронумерованы в указанном порядке, поэтому, например, группа Hosts имеет числовое имя 1.3.6.1.2.1.16.4.

Всего стандарт RMON MIB определяет около 200 объектов в 10 группах, зафиксированных в двух документах — RFC 1271 для сетей Ethernet и RFC 1513 для сетей Token Ring.

Отличительной чертой стандарта RMON MIB является его независимость от протокола сетевого уровня (в отличие от стандартов MIB-I и MIB-II, ориентированных на протоколы TCP/IP). Поэтому он удобен для гетерогенных сред, использующих различные протоколы сетевого уровня.

Рассмотрим более подробно группу Statistics, которая определяет, какую информацию о кадрах (называемых в стандарте пакетами) Ethernet может предоставить агент RMON. Группа History основана на объектах группы Statistics, так как ее объекты позволяют просто строить временные ряды для объектов группы Statistics.

В группу Statistics входят наряду с некоторыми другими следующие объекты:

Как видно из описания объектов, с помощью агента RMON, встроенного в повторитель или другое коммуникационное устройство, можно провести очень детальный анализ работы сегмента Ethernet или Fast Ethernet. Сначала можно получить данные о встречающихся в сегменте типах ошибок в кадрах, а затем целесообразно собрать с помощью группы History зависимости интенсивности этих ошибок от времени (в том числе привязав их ко времени). После анализа временн ых зависимостей часто уже можно сделать некоторые предварительные выводы об источнике ошибочных кадров и на этом основании сформулировать более тонкие условия захвата кадров со специфическими признаками (задав условия в группе Filter), соответствующими выдвинутой версии. После этого можно провести еще более детальный анализ путем изучения захваченных из объектов группы Packet Capture кадров.

Позже был принят стандарт RMON 2, который распространяет идеи интеллектуальной базы RMON MIB на протоколы верхних уровней, выполняя часть работы анализаторов протоколов.

Недостатки протокола SNMP

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

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

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

Разработчики платформ администрирования стараются преодолеть эти недостатки. Например, в системе HP OV Telecom DM TMN, являющейся платформой для разработки многоуровневых систем администрирования в соответствии со стандартами ISO, работает новая реализация SNMP, организующая надежный обмен сообщениями между агентами и менеджерами за счет самостоятельной организации повторных передач SNMP-сообщений при их потере.