Подписаться  на наше издание быстро и дешевле чем где-либо Вы можете прямо сейчас! Подписаться!

 


В нелегкой работе сисадмина часто (и это еще мягко сказано) всплывают самые различные вопросы по отладке сети для задач удаленного мониторинга. Естественно, имея под рукой документацию, компилятор C++ и неограниченное количество ночного времени, можно решить любую задачу apriori. Однако не будем так напрягаться. Оказывается, существует уже готовый инструмент — Simple Network Management Protocol.


Куда катится мир


Как известно, один из прогнозов развития нашей Вселенной предусматривает тепловой коллапс — материя вырождается, энтропия растет, и мы скатываемся в энергетическую яму бесконечного упрощения. Увы! находятся любители форсировать процесс симплификации. Так, разработчиками SNMP еще в далеком 1988 году была поставлена цель, закрепленная документально в RFC 1052: создание элементов Простого сетевого управления (больше об истории создания SNMP можно прочитать на врезке). В результате их стараний мы имеем SNMP — стандартный интернет-протокол (из стека TCP/IP, хотя есть реализации и для IPX), обеспечивающий обмен управляющей информацией между различными элементами сети, такими как хосты, маршрутизаторы, мосты, хабы, X-терминалы и т.п.


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


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

 


Возможные схемы взаимодействия агентов и менеджеров SNMP

 


Информационная база менеджмента SNMP

 


Иерархическая структура объектов менеджмента SNMP

 

Одним из основных преимуществ протокола, на мой взгляд, является иерархическая структура представления объектов менеджмента SNMP. Информационная база менеджмента (MIB, Management Information Base) описывает набор управляемых объектов. Запись для каждого объекта имеет свой уникальный идентификатор (OID). Она содержит также описание типа объекта (например, счетчик, строка или адрес), тип доступа к объекту (чтение или чтение/запись), ограничения на размер и информацию о диапазоне возможных значений. MIB описывается с помощью языка определений Abstract Syntax Notation и, как правило, представляет собой файл с расширением .MIB, либо “зашита” в программные файлы агента.

Информация, содержащаяся в MIB, может описывать неограниченное количество объектов. Это обеспечено самой архитектурой, поскольку все объекты SNMP в мире объединены в одно большое дерево. У дерева есть множество поддеревьев и ветвей, которые, по сути, являются объектами, включающими множества других объектов (которые тоже могут содержать объекты — и так ad infinitum). Поддеревья в дереве назначаются IETF, чтобы гарантировать уникальность каждой ветви дерева. Каждая ветвь имеет имя и номер, связанные с ним. Соответственно, все объекты SNMP имеют примерно такое имя: iso.org.dod.internet, которое соответствует числу 1.3.6.1.


Но и это еще не все. Ответственность за часть пространства имен MIB может быть предоставлена отдельным организациям для создания их собственной иерархии поддеревьев. Например, пространство имен Microsoft имеет OID 1.3.6.1.4.1.311. Базируясь на этой ветви, они могут строить дальнейшую иерархию без предварительного согласования с интернет-сообществом.


На сегодня существует несколько стандартов на базы данных управляющей информации для протокола SNMP. Основными являются MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB. Кроме того, существуют стандарты для специальных устройств MIB конкретного типа (например, MIB для концентраторов или MIB для модемов); LMMIB2 (для менеджмента LAN; содержит приблизительно 150 объектов, в которые входит информация о статистике работы сети, share-ресурсах, сессии, пользователе, логоне и т.п.); частные MIB конкретных фирм-производителей оборудования. Существует еще ряд MIB, описывающих различные протоколы и технологии работы Internet, например DHCP, WINS, FTP, HTTP, Gopher и др.


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


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

  • System — общие данные об устройстве;
  • Interfaces — параметры сетевых интерфейсов устройства (их количество, типы, скорости обмена, максимальный размер пакета);
  • Address Translation Table — описание соответствия между сетевыми и физическими адресами (например, по протоколу ARP);
  • Internet Protocol — данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика о IP-пакетах);
  • ICMP — данные, относящиеся к протоколу обмена управляющими сообщениями ICMP;
  • TCP — данные, относящиеся к протоколу TCP;
  • UDP — данные, относящиеся к протоколу UDP (число переданных, принятых и ошибочных UPD-дейтаграмм);
  • EGP — данные, относящиеся к протоколу обмена маршрутной информацией Exterior Gateway Protocol, используемому в интернете (число принятых с ошибками и без ошибок сообщений).

В версии MIB-II (RFC 1213), принятой в 1992 году, был существенно (до 185-ти) расширен набор стандартных объектов, а число групп увеличилось до 10-ти. На рисунке ниже приведен пример древовидной структуры базы объектов MIB-II. На нем показаны две из десяти возможных групп объектов: System (имена объектов начинаются с префикса sys) и Interfaces (префикс if). Объект sysUpTime содержит значение продолжительности времени работы системы с момента последней перезагрузки, объект sysObjectID — идентификатор устройства.


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


В число объектов, описывающих каждый конкретный интерфейс устройства, включены следующие:

  • IfType — тип протокола, который поддерживает интерфейс; этот объект принимает значения всех стандартных протоколов канального уровня, например rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing и т.д.;
  • fMtu — максимальный размер пакета сетевого уровня, который можно послать через этот интерфейс;
  • ifSpeed — пропускная способность интерфейса в битах в секунду;
  • ifPhysAddress — физический адрес порта; для Fast Ethernet им будет МАС-адрес;
  • ifAdminStatus — желаемый статус порта (- up — готов передавать пакеты; - down — не готов передавать пакеты; - testing — находится в тестовом режиме);
  • ifOperStatus — фактический текущий статус порта (имеет те же значения, что и ifAdminStatus);
  • ifInOctets — общее количество байт, принятое данным портом, включая служебные, с момента последней инициализации SNMP-агента;
  • ifInUcastPkts — количество пакетов с индивидуальным адресом интерфейса, доставленных протоколу верхнего уровня;
  • ifInNUcastPkts — количество пакетов с широковещательным или мультивещательным адресом интерфейса, доставленных протоколу верхнего уровня;
  • ifInDiscards — количество пакетов, которые были приняты интерфейсом, оказались корректными, но не были доставлены протоколу верхнего уровня (скорее всего из-за переполнения буфера пакетов или же по иной причине);
  • ifInErrors — количество пришедших пакетов, которые не были переданы протоколу верхнего уровня из-за обнаружения в них ошибок.

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


Эти ограничения были впоследствии сняты новым стандартом на MIB — RMON MIB, который специально ориентирован на сбор детальной статистики по протоколу Ethernet (к тому же с поддержкой такой важной функции, как построение агентом зависимостей статистических характеристик от времени).

 

В создание SNMP внесли свой вклад разработки по трем направлениям:

  • High-level Entity Management System (HEMS).
    Система управления объектами высшего уровня. Определяет систему управления с рядом интересных технических характеристик. К сожалению, HEMS использовалась только в местах ее разработки, что в конечном итоге привело к прекращению ее действия.
  • Simple Gateway Monitoring Protocol (SGMP).
    Протокол управления простым роутером. Разработка была начата группой сетевых инженеров для решения проблем, связанных с управлением быстрорастущей сети Интернет. Результатом их усилий стал протокол, предназначенный для управления интернет-роутерами. SGMP был реализован во многих региональных ветвях интернета.
  • CMIP over TCP (CMOT).
    CMIP над ТСР. Пропагандирует сетевое управление, базирующееся на OSI, в частности применение Common Management Information Protocol (CMIP, протокол информации общего управления) для облегчения управления объединенных сетей, базирующихся на ТСР.

Достоинства и недостатки этих методов (HEMS, SGMP и CMOT) часто и горячо обсуждались в течение второй половины 1987 г. К началу 1988 года стало ясно, что необходим некоторый общий набор средств управления сетевыми устройствами различных производителей, которые до сих пор создавали собственные продукты мониторинга и конфигурирования для своих же сетевых устройств, поддерживающие уникальные механизмы взаимодействия с ними.


В мае 1991 года была закончена работа по созданию первой версии протокола SNMP, которая нашла свое отражение в своде следующих документов: RFC 1155, RFC 1212, RFC 1213, RFC 1157 (см. таблицу).

 

 

Ближе к телу


И, наконец, рассмотрим примеры построения OID и базовый алгоритм получения информации от агента SNMP (звучит как Джеймс Бонд:) ).


Я долгое время не мог определиться, где бы найти удобочитаемую MIB — и, к немалому своему удивлению, обнаружил список баз, а также сами базы, у себя на машине в директории с ПХП (php/extras/mibs). Вот пример записи объектов MIB из файла SNMPv2-MIB.txt:

 

system   OBJECT IDENTIFIER ::= { mib-2 1 }

sysDescr OBJECT-TYPE
    SYNTAX      DisplayString (SIZE (0..255))
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "A textual description of the entity.  This value should include the full name and version identification of the
            system's hardware type, software operating-system, and networking software."
    ::= { system 1 }

 

В этом примере определяется объект system, являющийся ветвью 1 дерева mib-2. Следующий объект — sysDescr — принадлежит строковому типу, может достигать 255 символов в длину, “подчинен” system и является для него также первой ветвью. Следовательно, чтобы получить доступ к системной информации, содержащей “полное имя и идентификаторы версий железа, операционки и сетевых опций” (как указано в поле DESCRIPTION), мы должны ссылаться на следующий OID: iso.org.dod.internet.mgmt.mib-2.system.sysDescr (либо 1.3.6.1.2.1.1.1 в числовом представлении). Кроме того, для прочтения скалярного значения в конце OID ставится 0: 1.3.6.1.2.1.1.1.0.


Пример номер два. Чтобы получить текущий IP-адрес localhost, часто используют связку функций WinSock gethostname и gethostbyname. Но что делать, если у нашего хоста несколько сетевых интерфейсов с разными IP? Спокойно, агент 007 справится и с этим. Стоит лишь выполнить несколько последовательных запросов на OID iso.org.dod.internet.mgmt.mib-2.ip.ipAddrTable.ipAddrEntry.ipAddress (т.е. 1.3.6.1.2.1.4.20.1.1). Но для начала опишем модель запросов SNMP. Она предельно проста:

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

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


Первый запрос выполняем с помощью Get, последующие — с помощью GetNext. Если мы имеем 3 IP-адреса: 205.5.3.1, 205.5.3.3 и 205.5.3.6, то первый раз мы получим обратно 1.3.6.1.2.1.4.20.1.1.205.5.3.1. Второй — 1.3.6.1.2.1.4.20.1.1.205.5.3.3 и третий — 1.3.6.1.2.1.4.20.1.1.205.5.3.6. И, наконец, четвертый раз возвращаемое значение будет выглядеть как 1.3.6.1.2.1.4.20.1.2 или как 1.3.6.1.2.1.4.2.1.3, что будет сигнализировать о том, что функция больше не может получить IP-адресов.


Дальнейшие подробности зависят от конкретного воплощения агента и менеджера, поэтому подведем итог: SNMP — мощный, надежный, универсальный и хорошо структурированный инструмент для организации сетевых взаимодействий любого уровня сложности. Единствнным “сомнительным местом” SNMP является безопасность сетей на его основе. Но про безопасность — не в этот раз.

2006.06.21
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".