Несмотря на всю критику, SNMP остается сегодня наиболее широко реализованным протоколом управления сетью.
Типичная сеть состоит из множества устройств различных производителей. Управлять такой сетью возможно только при наличии стандартного, не зависящего от производителя протокола управления. Самым популярным стандартным протоколом управления в современных сетях является простой протокол управления сетью (Simple Network Manage-ment Protocol, SNMP). Широкое распространение он получил в силу своей гибкости и расширяемости — SNMP позволяет описывать объекты для самых разных устройств. Ниже мы рассмотрим основные компоненты SNMP с указанием отличий первой версии протокола от второй.
МОДЕЛЬ SNMP
Модель SNMP состоит из четырех компонентов:
- управляемых узлов;
- станций управления (менеджеров);
- управляющей информации;
- протокола управления.
 Рисунок 1. Структура базы управляющей информации. Как и многие другие иерархические пространства имен, MIB начинается с безымянного корневого узла. В этом дереве узел MIB-2 уникальным образом идентифицируется с помощью идентификатора объекта 1.3.6.1.2.1. |
Управление сетью осуществляется со станций управления, которые представляют собой компьютеры общего назначения со специальным программным обеспечением для управления. Станции управления выполняют один или более процессов, взаимодействующих с агентами по сети. При такой схеме вся сложность (и вся интеллектуальность) сосредоточена на станциях управления, чтобы агенты были как можно более просты и чтобы они потребляли как можно меньшие ресурсы устройств, на которых выполняются.
Спрашивать, например, у маршрутизатора, сколько пакетов было потеряно, бессмысленно, если он не ведет их учет или не понимает запроса. Поэтому SNMP самым тщательным образом описывает, какую информацию агент должен собирать и в каком формате ее следует предоставлять. Таким образом, каждое устройство поддерживает несколько переменных с описанием своего состояния. Все возможные переменные объединены в такую структуру, как база управляющей информации.
Станции управления взаимодействуют с агентами с помощью протокола SNMP. Он позволяет станции запрашивать значения локальных переменных агента и при необходимости изменять их.
Однако иногда в сети могут происходить нежелательные события. Управляемые узлы могут сломаться, линии связи — выйти из строя и т. п. Как только агент замечает какое-либо значительное событие, он немедленно сообщает о нем всем станциям из своего конфигурационного списка. Это сообщение называется прерыванием SNMP. Агент лишь сообщает о событии, а все подробности станция управления должна выяснять самостоятельно. Из-за ненадежности коммуникаций между станцией и агентами (получение сообщений не подтверждается) каждая станция периодически проводит опрос управляемых узлов для выявления необычных событий. Такая модель опроса через длительные интервалы времени с немедленным опросом при получении прерывания называется инициируемым прерываниями опросом.
СТРУКТУРА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ
Структура управляющей информации (Structure of Management Information, SMI) определяет допустимые в базе управляющей информации типы данных и способы их представления. Кроме того, она определяет иерархическую структуру имен, чтобы управляемые объекты имели уникальные однозначные имена. SMI представляет своего рода надподмножество ASN.1 — она использует часть типов данных этого стандарта и вводит несколько своих типов данных. (АSN — абстрактное описание синтаксиса — представляет собой стандартный язык описания объектов, принятый в OSI. Как и многие другие протоколы OSI, он сложен, громоздок и неэффективен.)
Для того чтобы агенты и менеджеры могли управлять объектами в сети со множеством устройств и протоколов разных поставщиков, объекты должны быть описаны, а также стандартным образом закодированы для передачи по сети. Термин "объекты" относится к переменным, описывающим состояние устройства. Он несколько сбивает с толку, так как это далеко не те же объекты, что и в объектно-ориентированных системах, в частности они имеют состояния, но не имеют методов (помимо чтения и записи значений объектов). Однако этот термин используется в официальных стандартах.
Объекты базы управляющей информации обычно имеют шесть атрибутов. Как правило, это имя, например ifInErrors или tcpAttemptFails; идентификатор объекта в точечно-десятичной нотации вида 1.3.6.1.2.1.2.2.1.1.4; поле синтаксиса для выбора одного из нескольких возможных типов данных — Integer, IPAddress или Counter; поле метода доступа — "недоступен", "только чтение", "чтение—запись" и "только запись"; поле статуса — "обязательный", "необязательный" или "вышедший из употребления", а также текстовое описание объекта.
SMI задает правила описания объектов. Все эти абстрактные правила и зарезервированные слова позволяют получить машиночитаемые спецификации, понятные человеку. Объекты MIB имеют статичную природу. Они компилируются из текстов файлов с описанием в двоичную форму, которую агенты и управляющие процессы и загружают. Используя SMI, производитель может написать собственное определение объекта управления (например, PacketsContainingWordSpam), пропустить текст через стандартный компилятор MIB и создать таким образом исполнимый код. Этот код можно затем установить на агенты с надлежащим аппаратным и программным обеспечением для подсчета количества содержащих слово spam пакетов.
БАЗА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ
Множество объектов, которыми управляет SNMP, составляет базу управляющей информации (Management Information Base, MIB). Для удобства эти объекты объединены в десять групп, каждая из которых представляет собой дочерний для mib-2 узел в дереве имен объектов (см. Рисунок 1). Изначально база управляющей информации содержала восемь групп. Спецификация MIB-2 добавила еще две группы и исключила одну прежнюю. Производители могут определять собственные объекты. Информация по всем десяти группам сведена в Таблицу 1.
| Группа | Количество объектов | Описание |
| System | 7 | Имя, местонахождение и описание оборудования |
| Interfaces | 23 | Сетевые интерфейсы и трафик через них |
| AT | 3 | Трансляция адресов (вышла из употребления) |
| IP | 42 | Статистика по IP-пакетам |
| ICMP | 26 | Статистика по полученным сообщениям ICMP |
| TCP | 19 | Алгоритмы, параметры и статистика TCP |
| UDP | 6 | Статистика трафика UDP |
| EGP | 20 | Статистика трафика для Exterior Gateway Protocol |
| Transmission | 0 | Зарезервирована для специфических MIB |
| SNMP | 29 | Статистика о трафике SNMP |
Группа System позволяет определить, как называется устройство, кем оно произведено, какое программное и аппаратное обеспечение оно содержит, где находится и какие функции выполняет. Кроме того, она предоставляет информацию о том, когда последний раз производилась загрузка и каковы имя и координаты ответственного лица. Зная эту информацию, администратор из центрального офиса может, например, без труда установить конфигурацию устройства в удаленном офисе.
Группа Interface служит для сбора статистики о работе сетевых адаптеров, в том числе о количестве переданных и полученных пакетов и байтов, о числе широковещательных пакетов и текущем размере выходной очереди.
Присутствовавшая в MIB-1 группа АТ предоставляла данные о соответствии адресов (например, MAC- и IP-адресов). В SNMPv2 эта информация была перемещена в базы управляющей информации для конкретных протоколов.
Группа IP описывает трафик через узел. Она изобилует счетчиками для подсчета числа отброшенных по каждой из причин кадров (например, кадр был отброшен, потому что его адресат неизвестен). Кроме того, она позволяет получить данные о фрагментации и сборке дейтаграмм. Как нетрудно понять, эта группа особенно полезна для получения статистики о работе маршрутизатора.
Группа ICMP собирает данные о сообщениях об ошибках в IP. Она имеет счетчики для подсчета количества зафиксированных сообщений каждого возможного типа.
Группа TCP служит для учета числа открытых соединений, количества переданных и полученных сегментов и различного рода ошибок.
Группа UDP позволяет фиксировать число переданных и полученных дейтаграмм, а также количество дейтаграмм, потерянных из-за того, что порт неизвестен, или по другим причинам.
Группа EGP используется маршрутизаторами, поддерживающими Exterior Gate-way Protocol. Она позволяет подсчитывать число полученных из внешней сети кадров, а также сколько из них было передано правильно, а сколько отброшено и т. п.
Группа Transmission служит родительским узлом для специфичных баз управляющей информации. Например, сюда может быть помещена группа для сбора статистики об Ethernet. Цель включения пустой группы в MIB-2 состоит исключительно в резервировании идентификатора для подобных целей.
Последняя группа — группа SNMP — предназначена для сбора статистики о функционировании самого протокола SNMP: сколько сообщений было послано, что это за сообщения и т.п.
ПРОТОКОЛ SNMP
Собственно SNMP представляет собой протокол по типу запрос—ответ, которыми сетевые станции управления и агенты обмениваются между собой. Первая версия протокола SNMP предусматривает всего пять различных сообщений. Три из них может посылать менеджер агенту, а два других — агент менеджеру.
Если в сети ничего необычного не происходит, то SNMP используется менеджером для отправки агенту запроса с просьбой передать запрошенную информацию или с приказом изменить свое состояние указанным образом. Агент посылает в ответ требуемую информацию или подтверждает изменение своего состояния. Однако агент может передать сообщение об ошибке, например "нет такой переменной". В чрезвычайных же обстоятельствах, в частности при превышении заданного порога, агент отправляет менеджеру прерывание. Данные передаются с использованием синтаксиса ASN.1.
Менеджер агенту может послать следующие три сообщения: GetRequest, GetNextRequest и SetRequest. Первые два служат для запроса у агента значений конкретных переменных. Первое из них содержит имя переменной в явном виде. Второе запрашивает значение следующей переменной в алфавитном порядке. Третье позволяет менеджеру изменять значения переменных, если определение объекта это позволяет.
Агент может отправлять два различных сообщения: одно из них — GetResponse — служит для ответа (и подтверждения) на запрос от менеджера, а второе — Trap — посылается при обнаружении агентом предопределенного чрезвычайного события.
Протоколом SNMPv2 вводится еще два типа сообщений. GetBulkRequest позволяет запросить целый массив переменных, например таблицу, а InformRequest — одному менеджеру сообщить другому, какими переменными он управляет.
Все типы сообщений сведены в Таблице 2.
| Сообщение | Описание |
| GetRequest | Запрос для получения значения одной или более переменных |
| GetNextRequest | Запрос следующей переменной |
| GetBulkRequest | Запрос большой таблицы |
| SetRequest | Изменение значения одной или более переменных |
| InformRequest | Сообщение менеджером другому менеджеру описания своей локальной MIB |
| Snmpv2Trap | Сообщение о прерывании от агента |
НИЖЕЛЕЖАЩИЕ ТРАНСПОРТНЫЕ ПРОТОКОЛЫ
SNMP предназначался в первую очередь для управления сетями на базе протоколов Internet. Как протокол прикладного уровня он может, однако, использовать в качестве транспортного любой другой протокол, помимо UDP и IP. Например, он может выполняться поверх IPX, отображаться напрямую в кадры Ethernet, инкапсулироваться в ячейки ATM и т. п.
Протокол SNMP разрабатывался в расчете на то, что обмен сообщениями между агентами и менеджерами будет происходить без установления соединения. В результате SNMP не предоставляет гарантии, что сообщения будут доставлены по назначению. Однако на практике большинство сообщений достигает адресата, а те, что теряются по пути, могут быть переданы повторно. Исходя из этого — и, естественно, ориентации SNMP на протоколы Internet, основным транспортом для SNMP является UDP.
Благодаря своей простоте и транспорту без установления соединения SNMP оказывается весьма эффективным протоколом. И агенты, и менеджеры могут работать независимо друг от друга. Таким образом, менеджер будет продолжать работать, даже если удаленный агент окажется недоступен. После возобновления функционирования агент отправит менеджеру прерывание, дабы известить его о своей работоспособности.
Обмен сообщениями при использовании в качестве транспорта протокола UDP осуществляется следующим образом. Агент следит за поступлением дейтаграмм на порт 161. Ответы посылаются запрашивающей сетевой станции управления на динамически назначаемый порт, однако многие агенты используют тот же номер порта — 161. Асинхронные прерывания станция управления принимает на порт 162.
Максимальная допустимая длина сообщений SNMP ограничивается мак-симальным размером сообщения UDP, т. е. 65 507 байт. Однако спецификация SNMP предусматривает, что все агенты и менеджеры должны принимать пакеты лишь длиной до 484 байт, поэтому некоторые из них могут не уметь обрабатывать пакеты длиной свыше 484 байт.
UDP более подходит для транспорта SNMP, нежели TCP, в частности, когда сеть сталкивается с проблемами и пакеты передаются каждый раз по новым маршрутам, т. е. когда управление наиболее необходимо. Кроме того, он предъявляет меньшие требования к сетевым ресурсам, нежели TCP, т. е. накладные расходы на управление оказываются меньше. Однако в результате задача обнаружения потерянных и ошибочных пакетов возлагается непосредственно на менеджеров и агентов.
ЗАЩИТА В SNMP
Одно из самых слабых (и критикуемых) мест SNMP — реализация защиты. Так, станция управления может не только узнать практически все о находящихся в сфере ее контроля узлах, но и остановить их. Поэтому агенты должны быть уверены, что полученный ими запрос действительно исходит от станции управления.
В SNMPv1 простейшая идентификация отправителя осуществляется посредством включения в сообщения имени группы (community name), причем имя передается открытым текстом. После проверки имени группы агент или менеджер проверяет наличие у отправителя с данным адресом прав на выполнение запрошенной операции. Таким образом, проверка прав осуществляется на основании имени группы и адреса отправителя.
В SNMPv2 сделана попытка укрепить защиту SNMP за счет использования современных криптографических методов, в частности DES. Однако это еще более усложнило протокол. Кроме того, в такой реализации SNMPv2 оказался обратно несовместим с SNMPv1.
ЛОЖКА ДЕГТЯ?
Несмотря на свое название, SNMP оказался далеко не простым для реализации протоколом ввиду сложности правил кодирования информации. Кроме того, SNMP мог бы быть более эффективным, чем он есть. В частности, его сообщения содержат зачастую ненужную информацию, например номер версии SNMP. Из-за принятого в SNMP способа описания переменных сообщения содержат чрезмерно большие дескрипторы данных. Все это ведет к раздуванию объема сообщений. Изначально SNMP предназначался для относительно простых сетей, так что станции управления не могли обмениваться информацией друг с другом. Наконец, самым существенным недостатком SNMP была (и остается) слабая защита. Многие из этих недостатков — но не все — исправлены во второй версии SNMP (SNMPv2).
Однако SNMP продолжает совершенствоваться, и уже готовится третья версия этого протокола.
Дмитрий Ганьжа — ответственный редактор LAN. С ним можно связаться по адресу: diga@lanmag.ru.