Протокол SNMP работает на базе транспортных возможностей UDP (возможны реализации и на основе ТСР) и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB - management information base, RFC-1213, -1212, std-17).
Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица (3) команд (pdu - protocol data unit) SNMP:
Таблица 3 - Команды SNMP
Команда SNMP | Тип PDU | Назначение |
GET-request | 0 | Получить значение указанной переменной или информацию о состоянии сетевого элемента; |
GET_next_request | 1 | Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB); |
SET-request | 2 | Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено; |
GET response | 3 | Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные); |
TRAP | 4 | Отклик сетевого объекта на событие или на изменение состояния. |
GetBulkRequest | 5 | Запрос пересылки больших объемов данных, например, таблиц. |
InformRequest | 6 | Менеджер обращает внимание партнера на определенную информацию в MIB. |
SNMPv3-Trap | 7 | Отклик на событие (расширение по отношению v1 и v2). |
Report | 8 | Отчет (функция пока не задана). |
Рис. 2 - Схема запросов/откликов SNMP
Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид (рис. 4.4.13.2):
Рис. 3 - Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы
Поле версия содержит значение, равное номеру версии SNMP минус один. Поле пароль (community - определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления:
Таблица 4. Номера и назначения используемых портов
Назначение | Порт | Пояснение |
SNMP | 161/TCP | Simple Network Management Protocol |
SNMP | 162/TCP | Trap |
SMUX | 199/TCP | SNMP Unix Multiplexer |
SMUX | 199/UDP | SNMP Unix Multiplexer |
synoptics-relay | 391/TCP | SynOptics SNMP Relay Port |
synoptics-relay | 391/UDP | SynOptics SNMP Relay Port |
Agentx | 705/TCP | AgentX |
snmp-tcp-port | 1993/TCP | cisco SNMP TCP port |
snmp-tcp-port | 1993/UDP | cisco SNMP TCP port |
Таблица 5 - Коды ошибок
Статус ошибки | Имя ошибки | Описание |
0 | Noerror | Все в порядке; |
1 | Toobig | Объект не может уложить отклик в одно сообщение; |
2 | Nosuchname | В операции указана неизвестная переменная; |
3 | badvalue | В команде set использована недопустимая величина или неправильный синтаксис; |
4 | Readonly | Менеджер попытался изменить константу; |
5 | Generr | Прочие ошибки. |
Таблица 6 - Коды TRAP
Тип TRAP | Имя TRAP | Описание |
0 | Coldstart | Установка начального состояния объекта. |
1 | Warmstart | Восстановление начального состояния объекта. |
2 | Linkdown | Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс. |
3 | Linkup | Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс. |
4 | Authenticationfailure | От менеджера получено snmp-сообщение с неверным паролем (community). |
5 | EGPneighborloss | R$GP-партнер отключился. Первая переменная в сообщении определяет IP-адрес партнера. |
6 | Entrprisespecific | Информация о TRAP содержится в поле специальный код. |
Для тип TRAP 0-4 поле специальный код должно быть равно нулю. Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так прерывание coldstart выдается объектом через 200 мс после инициализации.
В последнее время широкое распространение получила идеология распределенного протокольного интерфейса DPI (Distributed Protocol Interface). Для транспортировки snmp-запросов может использоваться не только UDP-, но и TCP-протокол. Это дает возможность применять SNMP-протокол не только в локальных сетях. Форматы SNMP-DPI-запросов (версия 2.0) описаны в документе RFC-1592. Пример заголовка snmp-запроса (изображенные поля образуют единый массив; см. рис. 4.4.13.3):
Рис. 4 - Формат заголовка SNMP-запроса
Поле Флаг=0x30 является признаком ASN.1-заголовка. Коды Ln - представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n - номер поля длины), если не оговорено другое. Так L1 - длина пакета-запроса, начиная с T1 и до конца пакета, а L3 - длина поля пароля. Субполя Tn - поля типа следующего за ними субполя запроса. Так T1=2 означает, что поле характеризуется целым числом, а T2=4 указывает на то, что далее следует пароль (поле community, в приведенном примере = public). Цифры под рисунками означают типовые значения субполей. Код 0xA - является признаком GET-запроса, за ним следует поле кода PDU (=0-4, см. табл. 4.4.13.1)
Блок субполей идентификатора запроса служит для тех же целей, что и другие идентификаторы - для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением Lиз. СО - статус ошибки (СО=0 - ошибки нет); ТМ - тип MIB-переменной (в приведенном примере = 0x2B); ИО - индекс ошибки. Цифровой код MIB-переменной отображается последовательностью цифровых субполей, характеризующих переменную, например: переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) характеризуется последовательностью кодов 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.
Начиная с января 1998 года, выпущен набор документов, посвященных SNMPv3. В этой версии существенно расширена функциональность (см. таблицу 1 тип PDU=5-8), разработана система безопасности.
В данной версии реализована модель, базирующаяся на процессоре SNMP (SNMP Engene) и содержащая несколько подсистем (дипетчер, система обработки сообщений, безопасности и управления доступом, см. рис. 4.4.13.4).
Перечисленные подсистемы служат основой функционирования генератора и обработчика команд, отправителя и обработчика уведомлений и прокси-сервера (Proxy Forwarder), работающих на прикладном уровне. Процессор SNMP идентифицируется с помощью snmpEngineID.
Обеспечение безопасности модели работы SNMP упрощается обычно тем, что обмен запросами-откликами осуществляется в локальной сети, а источники запросов-откликов легко идентифицируются.
Рис. 5 - Архитектура сущности SNMP (SNMP-entity)
Компоненты процессора SNMP перечислены в таблице 4.4.13.5 (смотри RFC 2571 и -2573)
Таблица 7 - Компоненты процессора SNMP
Название компонента | Функция компонента |
Диспетчер | Позволяет одновременную поддержку нескольких версий SNMP-сообщений в процессоре SNMP. Этот компонент ответственен за прием протокольных блоков данных (PDU), за передачу PDU подсистеме обработки сообщений, за передачу и прием сетевых SNMP-сообщений |
Подсистема обработки сообщений | Ответственна за подготовку сообщений для отправки и за извлечение данных из входных сообщений |
Подсистема безопасности | Предоставляет услуги, обеспечивающие безопасность: аутентификацию и защищенность сообщений от перехвата и искажения. Допускается реализация нескольких моджелей безопасности |
Подсистема управления доступом | Предоставляет ряд услуг авторизации, которые могут использоваться приложениями для проверки прав доступа. |
Генератор команд | Инициирует SNMP-запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, которые могут использоваться приложениями для проверки прав доступа. |
Обработчик команд | Воспринимает SNMP-запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, это индицируется тем, что contextEngeneID в полученном запросе равно соответствующему значению в процессоре SNMP. Приложение обработчика команд выполняет соответствующие протокольные операции, генерирует сообщения отклика и посылает их откправителю запроса. |
Отправитель уведомлений | Мониторирует систему на предмет выявления определенных событий или условий и генерирует сообщения Trap или Inform. Источник уведомлений должен иметь механизм определения адресата таких сообщений, а также параметров безопасности |
Получатель уведомлений | Прослушивает сообщения уведомления и формирует сообщения-отклики, когда приходит сообщение с PDU Inform |
Прокси-сервер | Переадресует SNMP-сообщения. Реализация этогог модуля является опционной |
На рис. 6 показан формат сообщений SNMPv3, реализующий модель безопасности UBM (User-Based Security Model).