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

Библиографическая справка

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

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

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

После многих заседаний IAB (Internet Architecture Board) опубликовал в апреле 1988 года эпохальный RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в котором призвал к скорейшему созданию элементов Простого Сетевого Управления (Simple Network Management). Работа по созданию SNMP закипела. Многие идеи, лежащие сегодня в основе SNMP были заимствованы из предыдущих исследований по мониторингу Internet- маршрутизаторов (исторически называемых шлюзами - gateways), явивших на свет Simple Gateway Monitoring Protocol (SMGP). И уже в августе 1988 появились три основополагающих документа:

Впоследствии эти документы были переизданы и дополнены до определения следующего поколения SNMP: RFC 1155, 1156 и 1157, которые в свою очередь, также подверглись переработкам.


В конце концов, в мае 1991 года была закончена работа по созданию первой версии протокола SNMP, которая нашла свое отражение в своде следующих документов: О дальнейшем развитии протокола SNMP см. в главе Проблемы безопасности протокола SNMP v1/2

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

Концепции SNMP-управления

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

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

Примитивы протокола SNMP

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

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

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

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

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

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

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

Структура SNMP MIВ

На сегодня существует несколько стандартов на базы данных управляющей информации для протокола SNMP. Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB. Кроме этого существуют стандарты для специальных устройств MIB конкретного типа (например, MIB для концентраторов или MIB для модемов), а также частные MIB конкретных фирм-производителей оборудования.
Первоначальная спецификация 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, используемому в Internet (число принятых с ошибками и без ошибок сообщений).

Из этого перечня групп переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на управление маршрутизаторами, поддерживающими протоколы стека TCP/IP.
В версии MIB-II (RFC 1213), принятой в 1992 году, был существенно (до 185) расширен набор стандартных объектов, а число групп увеличилось до 10.
На рис. 5 приведен пример древовидной структуры базы объектов MIB-II. На нем показаны две из 10 возможных групп объектов — System (имена объектов начинаются с префикса Sys) и Interfaces (префикс if). Объект SysUpTime содержит значение продолжительности времени работы системы с момента последней перезагрузки, объект SysObjectID — идентификатор устройства (например, маршрутизатора).

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

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

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

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

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

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

ifPhysAddress
Физический адрес порта, для Fast Ethernet им будет МАС-адрес.

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

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

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

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

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

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

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

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



Hosted by uCoz