• 20.1 Введение
  • 20.1.1 Результат одобрения SNMP в IAB
  • 20.2 Модель SNMP
  • 20.2.1 Логическая база данных
  • 20.2.2 Агенты
  • 20.2.3 Диспетчеры
  • 20.2.4 Управляющая информационная база
  • 20.3 Назначение диспетчера и агента
  • 20.3.1 Прокси-агенты
  • 20.4 Сущность управляющей информации
  • 20.5 Структура управляющей информации
  • 20.5.1 Дерево SMI
  • 20.6 Имена идентификаторов объектов
  • 20.6.1 Идентификация значений в базе данных MIB
  • 20.6.2 Лексикографический порядок
  • 20.7 Наиболее важные модули MIB
  • 20.7.1 MIB-II
  • 20.7.2 Модули пересылки
  • 20.7.3 RMON MIB
  • 20.7.4 Реализация MIB от разработчиков оборудования
  • 20.8 Протокол сообщений SNMP
  • 20.8.1 Типы сообщений SNMP версии 1
  • 20.8.2 Транспортные протоколы
  • 20.9 Форматы сообщений SNMP
  • 20.9.1 Формат сообщений gets, sets и responses в версии 1
  • 20.9.2 Запрос get и ответ на него
  • 20.9.3 Запрос get-next и ответ на него
  • 20.9.4 Запрос set
  • 20.9.5 Сообщения trap
  • 20.9.6 Проблемы версии 1, исправленные в версии 2
  • 20.9.7 Сообщение get-bulk версии 2
  • 20.9.8 Сообщение trap в версии 2
  • 20.9.9 Сообщение inform версии 2
  • 20.9.10 Другие усовершенствования в версии 2
  • 20.10 Документы MIB
  • 20.10.1 Управляемые объекты
  • 20.10.2 Первая абстрактная синтаксическая нотация (ASN.1)
  • 20.10.3 Типы данных MIB
  • 20.10.4 Целые числа
  • 20.10.5 Счетчики
  • 20.10.6 Масштаб
  • 20.10.7 TimeTicks
  • 20.10.8 Строки октетов
  • 20.10.9 Текстовые соглашения
  • 20.10.10 Копирование типов данных в BER
  • 20.11 Что дальше?
  • 20.12 Дополнительная литература
  • Глава 20

    SNMP

    20.1 Введение

    Сетевое управление далеко отстало по своим возможностям от других сетевых средств. Очень большие сети TCP/IP прекрасно работают, однако их администрирование и обслуживание требуют много времени и наличия квалифицированного технического персонала.

    Особенно это справедливо для сети Интернет, которая быстро разрастается и усложняется. В конце 80-х гг. Совет по архитектуре Интернета (Internet Architecture Board — IAB) столкнулся с необходимостью определения технической политики Интернета, наиболее критичной частью которой являлось установление основ управления сетью и создание набора стандартов для соответствующих рабочих инструментов. Сделать это нужно было как можно быстрее.

    Хотя большая часть работы уже была выполнена комитетом по созданию стандартов сетевого управления OSI, предстояло разработать реальные стандарты для инструментов управления сетями TCP/IP.

    Рабочая группа Интернета создала простой протокол сетевого управления (Simple Network Management Protocol — SNMP), который решал сиюминутные потребности TCP/IP. Архитектура SNMP разрабатывалась в соответствии с моделью OSI. Была надежда, что стандарт сетевого управления OSI — общая информационная служба управления/общий протокол управляющей информации (Common Management Information Services/Common Management Information Protocol — CMIS/CMIP) — просуществует долго. Однако за несколько месяцев стало ясно, что SNMP требует независимой разработки и должен помочь в создании средств для управления сетями.

    20.1.1 Результат одобрения SNMP в IAB

    Первая спецификация SNMP стала начальной точкой. Эксперты из IAB быстро внесли необходимые изменения. Как указано в RFC 1052 (рекомендации по разработке стандартов сетевого управления для Интернета), служба сетевого управления должна:

    (a) поддерживать сети максимально большого размера

    (b) как можно полнее охватывать реализации

    (c) работать поверх наибольшего количества протоколов различного уровня

    (d) охватывать как можно больший круг задач администрирования

    Результаты политики IAB превзошли все первоначальные ожидания. Как только была опубликована спецификация SNMP и в Интернете появились первые примеры исходных кодов, протокол был реализован в сотнях продуктов, начиная от сложных хостов на больших ЭВМ — до простейших коммуникационных устройств, и этот процесс расширялся и углублялся.

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

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

    В 1996 г. была опубликована вторая версия SNMP. Некоторые ее возможности рассматриваются в этой главе.

    20.2 Модель SNMP

    20.2.1 Логическая база данных

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

    20.2.2 Агенты

    Для обеспечения доступа к информации управляемая система должна иметь программный агент, который отвечает на запросы, выполняет изменения и выводит отчет о возникших проблемах. Одна или несколько станций управления (management station) посылают запросы и сообщения об изменениях к агентам, получая от них ответы и сообщения об ошибках.

    20.2.3 Диспетчеры

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

    Рис. 20.1. Модель SNMP

    20.2.4 Управляющая информационная база

    Управляющая информационная база (Management Information Base — MIB) является логическим описанием всех управляющих данных. Существует много документов RFC, присваивающих набор соответствующих переменных. Каждый из этих документов описывает модуль MIB. Кроме того, имеются документы MIB, разработанные производителями оборудования и определяющие переменные, специфичные для данного типа продуктов.

    Описание переменных MIB не связано со способом хранения этих переменных в устройстве, но определяет:

    ■ Смысл переменной

    ■ Способ измерения переменной

    ■ Имя для доступа к значению переменной при чтении или изменении содержимого базы данных

    Хотя MIB формально состоит только из набора определений, этого достаточно для запроса необходимых данных, хранящихся в базе данных MIB определенного устройства (иногда говорят: в MIB устройства). Типичная база данных MIB содержит:

    ■ Информацию о системе и ее состоянии

    ■ Статистику производительности

    ■ Конфигурационные параметры

    MIB устройства хранит только те переменные, которые необходимы для данного устройства. Например, простейшему мосту локальной сети нет смысла хранить переменные для оценки статистики TCP.

    20.3 Назначение диспетчера и агента

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

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

    Диспетчер управляет системой, запрашивая у агента изменение состояния MIB или конфигурационных параметров из этой базы данных. Изменение параметра может быть связано с выполнением определенной операции. Например, можно отключить один из сетевых интерфейсов устройства, установив переменную статуса в состояние "выключено".

    Новые возможности по управлению и обслуживанию сети реализуются через введение новых переменных в MIВ.

    Современные системы мониторинга позволяют отслеживать работу многих разнообразных устройств. Существуют программные мониторы для работы на различных платформах: от больших ЭВМ до персональных компьютеров. В следующих разделах этой главы будут приведены примеры экранов систем мониторинга HP Open View for Windows Workgroup Node Manager, работающего в среде Windows.

    20.3.1 Прокси-агенты

    В основе модели SNMP лежит принцип сосуществования агента и базы данных MIB в одном устройстве, которое может управляться и контролироваться из удаленной точки сети. Прокси-агент несколько расширяет эту модель, разрешая косвенный доступ к устройству. Станция управления будет взаимодействовать с прокси, когда станет необходим доступ или изменение информации. Прокси-агент обменивается информацией с устройством с помощью отдельного соединения (см. рис. 20.2).

    В версии 2 SNMP прокси служат для пересылки информации между окружениями версий 1 и 2.

    Рис. 20.2. Прокси-агент

    20.4 Сущность управляющей информации

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

    Описание переменных возложено на комиссии экспертов по каждой из сетевых технологий. Отдельные комиссии разрабатывают MIB для мостов, хостов, телефонных интерфейсов и т.д.

    Главным документом MIB является спецификация управления в сетях TCP/IP, которая содержит следующие сведения:

    ■ Тип данной системы

    ■ Имя и физическое размещение системы

    ■ Типы сетевых интерфейсов системы

    ■ Число полученных и отправленных кадров, сегментов или датаграмм TCP.

    На рис. 20.3 показана системная информация маршрутизатора, извлеченная в HP Openview.

    Рис. 20.3. Извлеченной из устройства системной информация

    20.5 Структура управляющей информации

    Для описания переменных сетевого управления необходимы:

    ■ Административная структура. Работа по описанию переменных MIB для различных типов сетевых устройств возложена на специалистов в данной области. Административная структура необходима для описания и отслеживания разделения работ и делегирования полномочий на их проведение.

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

    ■ Структура именования. Существуют сотни переменных, описывающих управление в сети. Необходим единый метод описания, определения и именования этих переменных.

    Всем этим требованиям удовлетворяет древовидная структура, называемая структурой управляющей информации (Structure of Management Information — SMI).

    20.5.1 Дерево SMI

    Вспомним, что первоначально SNMP предполагался как временное решение до выпуска стандартов управления ISO. На рис. 20.4 дерево администрирования/именования отражает первичные попытки согласования с ISO.

    Рис. 20.4. Дерево администрирования и именования SMI

    Узлы вверху этого дерева предполагают ответственность определенных организаций за разработку требований для нижестоящих узлов (см. таблицу 20.1). Однако многое в этом дереве уже устарело. Стандарты SNMP уже давно не координируются ISO (в дереве — iso), а Министерство обороны США не управляет работой Интернета (в дереве — dod).


    Таблица 20.1 Узлы дерева SMI

    Метка Описание
    iso(1) Международная организация по стандартизации (ISO)
    org(3) Национальные и международные организации
    dod(6) Министерство обороны США (DOD)
    internet(1) IAB

    Однако дерево продолжает выполнять свою основную функцию — определение имен MIB. Древовидная структура очень полезна: как только в сетевом окружении возникает новая технология, создается специальный комитет, а на дереве появляется новый узел. Комитет ведет разработку переменных и добавляет их к общему дереву в виде поддерева.

    20.6 Имена идентификаторов объектов

    На рис. 20.5 показаны наиболее важные части дерева SMI, которые применяются для присвоения управляющим переменным имен, называемых идентификаторами объектов (object identifiers).

    Рис. 20.5. Дерево именования объектов MIB

    Идентификаторы объектов создаются путем приписывания числовых идентификаторов каждому узлу, начиная с вершины дерева. Каждый узел имеет и текстовую метку, помогающую пользователям и разработчикам понять назначение переменной. Например:

    Идентификатор объекта 1.3.6.1.2.1.1.1
    Текстовое имя iso.org.dod.internet.mgmt.system.sysDescr

    20.6.1 Идентификация значений в базе данных MIB

    Для описания реального значения в базе данных устройства в конец идентификатора объекта добавляется еще одно число. Например, если информация обо всех интерфейсах устройства хранится в таблице, а идентификатор объекта для таблицы ifType имеет значение 1.3.6.1.2.1.2.2.1.3, то для указания на четвертый интерфейс данного маршрутизатора нужно использовать идентификатор:

    1.3.6.1.2.1.2.2.1.3.4

    Соглашение по добавлению индексов применяется и для переменных с единственным значением, например sysDescr или sysUpTime. В этом случае в конец идентификатора добавляется 0. Например, полное описание переменной sysDescr.

    1.3.6.1.2.1.1.1.0

    20.6.2 Лексикографический порядок

    Переменные в MIB упорядочены лексикографически. Для сравнения двух идентификаторов:

    1.3.6.1.2.1.2.2.1.19.3

    1.3.6.1.2.1.2.2.1.21.2

    нужно выполнить:

    ■ Начать слева.

    ■ Сравнивать значения, пока не будет найдено первое отличие.

    ■ Число с большим значением определяет больший элемент.

    В приведенном примере второй идентификатор больше первого. Однако что делать в следующем случае:

    1.3.6.1.2.1.2.2.1

    1.3.6.1.2.1.2.2.1.21.2

    Большим будет более длинный идентификатор.

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

    Рис. 20.6. Лексикографический порядок для таблиц

    20.7 Наиболее важные модули MIB

    Разработаны десятки модулей MIB, описывающих все: от интерфейса RS-232 до серверов электронной почты. В этом разделе мы рассмотрим наиболее важные модули MIB.

    20.7.1 MIB-II

    Данная группа переменных изображена на рис. 20.5 (system, interfaces и т.д.). Все эти переменные были определены в первом документе MIB, описывающем переменные сетей TCP/IP. После проверки и исследования модуль был переработан и получил название MIВ-II. В последней версии модуля описываются определения переменных для SNMP версии 1. Затем были опубликованы небольшие изменения, связанные с версией 2.

    20.7.2 Модули пересылки

    Создано множество модулей, описывающих технологии локальных и региональных сетей. Несколько поддеревьев создано от узла transmission (см. рис. 20.7). Полный их список приведен в документе Assigned Numbers.

    Рис. 20.7. Модули пересылки MIB

    20.7.3 RMON MIB

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

    Удаленный мониторинг сети MIB (Remote Network Monitoring MIB — RMON MIB) интегрирует ценную информацию, собранную мониторами из структур SNMP. Это дает существенное расширение возможностей станций управления SNMP.

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


    Таблица 20.2 Группы переменных RMON MIB

    Переменная Описание
    statistics Статистика работы определенного типа интерфейса, например для Ethernet — коллизии или ошибки, а для Token-Ring — сигналы ошибок или потерянные маркеры.
    history Статистические оценки за указанный временной интервал выборки значений.
    alarm Генерация события при превышении переменной заданного граничного значения.
    host Отчет хоста монитору, содержащий сопутствующую статистическую информацию, например число переданных кадров.
    hostTopN Статистический отчет хоста, содержащий список отсортированных значений о производительности или количестве ошибок.
    matrix Статистический отчет об обмене между двумя сетевыми адресами.
    filter Определение критерия для выделения набора кадров с целью более подробного анализа.
    packet capture Позволяет регистрировать кадры, соответствующие установленному критерию.
    event Управление генерацией и выводом сведений о событиях. Событие может иметь локальную природу, например превышение граничного значения переменной. Оно позволяет переключиться на выполнение локальной операции, например на запись сообщения в файл регистрации, инициализацию захвата пакетов или на вывод сообщения trap на станцию управления.

    20.7.4 Реализация MIB от разработчиков оборудования

    С самого начала на дереве объектов MIB было отведено место для объектов от разработчиков. Для получения ветви дерева разработчик (компания, организация или правительственное агентство) регистрируется в IANA. На рис. 20.8 показана часть дерева MIВ компании Cabletron, которой был присвоен идентификатор объекта:

    1.3.6.1.4.1.52.

    Рис. 20.8. Часть дерева MIB компании Cabletron

    20.8 Протокол сообщений SNMP

    Рассмотрим протокол сообщений, обеспечивающий взаимодействие диспетчеров с агентами. SNMP основан на двух принципах:

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

    ■ Используется очень мало типов сообщений.

    20.8.1 Типы сообщений SNMP версии 1

    Диспетчеры и агенты взаимодействуют друг с другом, обмениваясь сообщениями SNMP. Как показано на рис. 20.9, для версии 1 протокола SNMP существует только пять типов сообщений:

    get-request Запрос значений одной или нескольких переменных из системы управления MIB
    get-next-request Разрешение диспетчеру на последовательное извлечение значений переменных (используется для просмотра таблиц или всей базы данных MIB)
    set-request Разрешение диспетчеру изменить значения переменных
    get-response Получить ответ на сообщения get, get-next и set (в версии 2 называется response)
    trap Разрешение агенту на отчет о важных событиях или проблемах

    Рис. 20.9. Типы сообщений SNMP версии 1

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

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

    Сообщение trap используется для отчета о наиболее общих событиях:

    ■ Самостоятельная переинициализация

    ■ Локальный отказ связи

    ■ Восстановление связи

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

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

    20.8.2 Транспортные протоколы

    В качестве наиболее предпочтительного транспорта был выбран протокол UDP. Это объясняется его простотой и реализацией с помощью очень небольшого кода. Такой выбор особенно подходит для работы устройств в режиме перегрузки или при неисправности. Однако для SNMP могут использоваться и другие транспортные протоколы. Например, в окружении NetWare протокол SNMP может работать поверх IPX.

    Когда используется UDP, каждое сообщение SNMP вкладывается в одну датаграмму UDP и доставляется через IP. Как показано на рис. 20.9, запросы направляются на порт 161 от любого удобного порта UDP. Ответы возвращаются на запрашивающий порт. Сообщения trap исходят из любого удобного порта UDP и направляются на порт 162.

    Все реализации версии 1 должны быть способны обрабатывать сообщения длиной, по крайней мере, в 484 октета.

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

    Сообщение SNMP версии 1 состоит из некоторого вводного материала — "обертки",— сопровождаемого сообщением Protocol Data Unit одного из пяти типов: get-request, get-next-request, get-response, set-request или trap. Вводный материал содержит:

    Версию протокола 0 для SNMP версии 1 и 1 для версии 2
    Имя сообщества используется как пароль

    Агент конфигурируется на ограничение (по имени сообщества) доступа к информации по чтению или записи. Кроме того, можно указать IP-адрес станции управления, которой разрешен доступ по чтению или записи информации MIB.

    К сожалению, имя сообщества в сообщении можно легко подглядеть с помощью любого сетевого анализатора, а IP-адрес иногда можно сфальсифицировать. Одним из решений является доступ к важным устройствам (например, маршрутизаторам) через отдельную, безопасную линию связи, особенно при изменении конфигурации или статуса системы.

    20.9.1 Формат сообщений gets, sets и responses в версии 1

    Главное информационное содержимое во всех этих сообщениях одинаково. Оно состоит из списка (пары этого списка обычно называют "связыванием переменной"):

    Имя переменной Значение
    Имя переменной Значение

    Идентификатор объекта используются как имя переменной. В сообщениях get и get-next поля значений пустые. В них агент разместит необходимые значения.

    Элемент данных протокола (Protocol Data Unit) для сообщений get-request, get-next-request, set-request или response включает:

    Идентификатор запроса Служит для согласования запроса и ответа на него.
    Поле статуса ошибки 0 в запросах. Ненулевые значения в ответах означают различные ошибки.
    Поле индекса ошибки 0 в запросах. В ответах указывает переменную, создавшую ошибку.
    Список идентификаторов объектов и значений В get или get-next — пустые, но заполнены в set или response.

    20.9.2 Запрос get и ответ на него

    На рис. 20.10 показаны запрос get-request и ответ на него (response), полученные в анализаторе Sniffer компании Network General. Запрос содержит список из пяти переменных, значения которых нужно получить. После каждого идентификатора переменной стоит заполнитель NULL. Чтобы создать ответ, агент должен только заполнять пробелы и заменять пустые поля фактическими значениями.

    SNMP: Version = 0

    SNMP: Community = public

    SNMP: Command = Get request

    SNMP: Request ID = 112

    SNMP: Error status = 0 (No error)

    SNMP: Error index = 0

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.1.3.0} (sysUpTime.0)

    SNMP: Value = NULL

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.5.1.0} (icmpInMsgs.0)

    SNMP: Value = NULL

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.5.2.0} (icmpInErrors.0)

    SNMP: Value = NULL

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.5.3.0} (icmpInDestUnreachs.0)

    SMMP: Value = NULL

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.5.4.0} (icmpInTimeExcds.0)

    SNMP: Value = NULL


    SNMP: Version = 0

    SNMP: Community = public

    SNMP: Command = Get response

    SNMP: Request ID = 112

    SNMP: Error status = 0 (No error)

    SNMP: Error index = 0

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.1.3.0} (sysUpTime.0)

    SNMP: Value = 1037388 hundredths of a second SNMP:

    SNMP: Object = {1.3.6.1.2.1.5.1.0} (icmpInMsgs.0)

    SNMP: Value = 1 messages

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.5.2.0} (icmpInErrors.0)

    SNMP: Value = 0 messages

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.5.3.0} (icmpInDestUnreachs.0)

    SNMP: Value = 0 messages

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.5.4.0} (icmpInTimeExcds.0)

    SNMP: Value = 0 message

    Рис. 20. 1. Пример get-request и response

    20.9.3 Запрос get-next и ответ на него

    Сообщение get-next работает по-другому. Когда отсылается идентификатор объекта, возвращается значение следующего объекта. Например, если послать запрос:

    SNMP: Object = {1.3.6.1.2.1.5.1.0} (icmpInMsgs.0)

    SNMP: Value = NULL

    ответ будет содержать имя и значение для следующей переменной:

    SNMP: Object = {1.3.6.1.2.1.5.2.0} (icmpInErrors.0)

    SNMP: Value = 0 messages

    Такой запрос позволяет просматривать значения MIB или перемещаться на следующую строку таблицы.

    20.9.4 Запрос set

    Запрос set позволяет записывать информацию в базу данных агента. Формат сообщения очень прост, он выглядит как get-request, но приводит к изменению указанных в запросе переменных. На рис. 20.11 показано отслеживание запроса set.

    SNMP: Version = 0

    SNMP: Community = xyz

    SNMP: Command = Set request

    SNMP: Request ID = 0

    SNMP: Error status = 0 (No error)

    SNMP: Error index = 0

    SNMP:

    SNMP: Object = {1.3.6.1.2.1.4.1.0} {ipForwarding.0}

    SNMP: Value = 2

    SNMP: Object = {1.3.6.1.2.1.4.2.0} (ipDefaultTTL.0)

    SNMP: Value = 70

    Рис. 20.11. Изменение значений MIB запросом set

    Успешными должны быть все изменения запроса, иначе будет отклонен весь запрос. Поскольку часто нужно изменять одновременно несколько переменных, либо ни одну из них. Это бескомпромиссное правило для set сохраняется и в версии 2.

    Ответ на set выглядит как запрос, за исключением того, что при возникновении проблем заполняются поля статуса ошибки и индекса ошибки.

    20.9.5 Сообщения trap

    Агент использует сообщения trap для указания диспетчеру на серьезные проблемы.

    В стандарте SNMP определено очень немного таких сообщений. Описание trap оставлено в ведении комитетов по технологическим стандартам и разработчиков — с предупреждением о снижении количества таких сообщений. Когда сеть перегружена, нежелательно получать десятки сообщений от каждого из сетевых устройств с указаниями на их проблемы.

    Сообщения trap в версии 1 были более сложными, чем следовало бы. Такое положение было исправлено в версии 2. Рассмотрим сначала сообщения trap версии 1. В них имеется общее поле (generic trap), значение которого определяет тип прерывания в соответствии со следующим списком:

    соldStart(0) Отправитель проводит переинициализацию, и его конфигурационные параметры могут измениться.
    warmStart(1) Отправитель проводит переинициализацию, и его конфигурационные параметры не будут изменяться.
    linkDown(2) Смежная связь нарушена.
    linkUp(3) Смежная связь восстановлена.
    autentication Failure(4) Кто-то послал агенту запрос, который не был аутентифицирован (например, в сообщении было использовано неправильное имя сообщества).
    egpNeighbor Loss(5) Сосед по протоколу Exterior Gateway Protocol выключен.
    enterprise Specific(6) Другие запросы, определенные комитетом стандартов, разработчиком или иным заинтересованным лицом.

    На рис. 20.12 показано очень простое сообщение trap, указывающее на выполнение холодного старта (перезапуска с выключением питания. — Прим. пер.).

    ■ Поле Enterprise указывает, что это сообщение отправлено системой, выполняющей программный продукт FTP для TCP/IP.

    ■ Поскольку значение общего поля trap равно 0, это сообщение свидетельствует о холодном старте.

    ■ Поле счетчика времени (time ticks) содержит sysUpTime, которое равно 0, поскольку система только что выполнила инициализацию по холодному старту.

    SNMP: Version = 0

    SNMP: Comunity = public

    SNMP: Command = Trap

    SNMP: Enterprise = {1.3.6.1.4.1.121.1.1}

    SNMP: Network address = [198.207.177.10]

    SNMP: Generic trap = 0 (Cold start)

    SNMP: Specific trap = 0

    SNMP: Time ticks = 0

    Рис. 20.12. Сообщение trap версии 1 протокола SNMP

    Любые сообщения trap, определенные комитетом MIB или разработчиком, имеют в общем поле значение 6. В данном случае поле enterprise комбинируется с полем specific trap (специальное прерывание), определяющим смысл сообщения.

    Как видим, структура сообщения достаточно сложна. В версии 2 она была проще.

    20.9.6 Проблемы версии 1, исправленные в версии 2

    Следующие свойства SNMP версии 1 были не слишком удачны:

    ■ Если одна из переменных в запросе get или get-next была некорректна, то отбрасывалось все сообщение.

    ■ Если запрашивались значения нескольких переменных и агент не мог разместить ответ в самом большом по размеру сообщении, отбрасывалось все сообщение.

    ■ Сообщения trap реализовывали простые функции, но имели сложную структуру.

    Все эти проблемы были решены в версии 2. Теперь агент может помещать код ошибки в поле значения переменной, которая не может быть обработана. Появился новый запрос get-bulk, требующий от агента возврата максимально возможного объема информации. Сообщения trap стали иметь такой же простой формат, как и все другие сообщения.

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

    20.9.7 Сообщение get-bulk версии 2

    Сообщение get-bulk ведет себя подобно get-next. Агент возвратит переменные, чьи идентификаторы объектов следуют за идентификаторами объектов, указанными в запросе. Сообщение get-bulk имеет параметры, указывающие:

    ■ Количество начальных автономных неповторяющихся (nonrepeater) запрошенных переменных

    ■ Количество требуемых повторений для оставшихся повторяющихся (repeater) переменных

    Например, можно запросить две неповторяющиеся автономные переменные:

    sysDescr

    sysUpTime

    и затем еще десять строк табличных переменных: ifIndex, ifDescr, ifTyре, ifMTU и ifSpeed. В этом случае:

    ■ В списке будет 7 переменных

    ■ 2 неповторяющиеся переменные

    ■ Максимальное число повторений будет равно 10

    В ответе будет упаковано столько затребованной информации, сколько возможно. Приложение легко сможет послать еще один запрос get-bulk за данными, не поместившимися в сообщении ответа.

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

    20.9.8 Сообщение trap в версии 2

    В версии 2 сообщение trap имеет тот же самый формат, что и ответ на него. Сообщение начинается стандартной информацией заголовка, далее следует список переменных:

    Идентификатор объекта Значение

    В начале списка переменных размещается SysUpTime и уникальный идентификатор trap. Могут быть включены дополнительные переменные, помогающие определить причину возникновения проблемы.

    20.9.9 Сообщение inform версии 2

    В версии 2 реализована идея информационного сообщения, подтверждающего получение trap. Такие сообщения полезны при взаимодействии диспетчеров, когда отправителю нужно точно знать о получении сообщения в принимающем диспетчере. Для подтверждения приема информационного сообщения (inform) используется обычный ответ.

    20.9.10 Другие усовершенствования в версии 2

    Насколько точно реализация модуля должна соответствовать определению MIB от разработчика для обеспечения требований совместимости? И как разработчик может объявить о несоответствии спецификации, которое, скорее всего, было необходимо из-за некоторых ограничений в возможностях оборудования?

    Решить эти вопросы в версии 2 помогают следующие средства:

    ■ Описание совместимости (compliance statement), определяющее фактические минимальные требования для модуля

    ■ Описание возможностей (capability statement), предоставляемое разработчиком для пояснения реальных возможностей агента

    Эти описания позволяют клиенту при выборе узнать о продукте немного больше, чем "мы поддерживаем SNMP".

    20.10 Документы MIB

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

    В следующих разделах мы обсудим некоторые концепции, знание которых будет полезно при чтении документов MIB.

    20.10.1 Управляемые объекты

    До сих пор мы использовали неформальный термин "переменная MIВ". Но стандарты MIB реально определяют управляемые объекты (managed objects). Переменная имеет название и значение, а определение управляемого объекта включает:

    ■ Имя — идентификатор объекта

    ■ Набор атрибутов, в частности:

    ■ Тип данных

    ■ Описание деталей реализации

    ■ Информацию о статусе

    ■ Набор операций, которые могут быть выполнены над объектом

    Рассмотрим типичное определение MIB:

    sysDescr OBJECT-TYPE

     SYNTAX DisplayString (SIZE (0..255))

     ACCESS read-only

     STATUS mandatory

     DESCRIPTION

      "Текстовое описание элемента, которое должно содержать полное имя и

      номер версии, типа аппаратного обеспечения системы, операционной

      системы и сетевых средств. Подтверждается (mandatory), что вся

      информация содержит только воспроизводимые символы ASCII."

     :: = { system 1 }

    Определение начинается с обозначения текстовой метки объекта — sysDescr — и заканчивается {system 1}, что означает "поместить этот узел ниже узла system и присвоить ему номер 1". Такая запись позволяет построить полный идентификатор объекта, который будет выглядеть как:

    1.3.6.1.2.1.1.1

    Остальная часть определения состоит из ряда конструкций (clauses) — SYNTAX (синтаксис), ACCESS (доступ), STATUS (статус) и DESCRIPTION (описание).

    В данном случае SYNTAX (datatype) — это выводимая строка, т.е. ряд символов не длиннее 255 знаков.

    ACCESS определяет действие(я), которое может быть выполнено. В данном случае ACCESS задан как "чтение/запись", а диспетчер может читать или изменять значения переменных.

    В ранних документах MIB условие STATUS могло иметь значения: mandatory (обязательно), optional (необязательно), obsolete (устарело) или deprecated (отменено). Однако значения mandatory и optional были бесполезны. Более новые MIB не включают переменных, значение которых столь мало, что нет смысла помечать их специальным значением. STATUS теперь может указать на current (текущее значение), deprecated (отменено) или obsolete (устарело).

    20.10.2 Первая абстрактная синтаксическая нотация (ASN.1)

    Определения MIB написаны на стандартном языке первой абстрактной синтаксической нотации (Abstract Syntax Notation 1 — ASN.1), разработанном в ISO. ASN.1 похож на компьютерные языки. Существуют и основные правила кодирования (Basic Encoding Rules — BER), также от ISO, определяющие формат пересылки значений, определенных с помощью ASN.1.

    Станция управления анализирует переменные MIB, компилируя определения MIB в записи ASN.1. Хорошие станции управления позволяют компилировать столько MIB, сколько нужно.

    После компиляции станция управления готова посылать и получить сообщения SNMP, содержащие любую из скомпилированных переменных. Хорошие станции могут также выводить описания переменных. На рис. 20.13 показан вывод в HP Open View условия DESCRIPTION описания sysDescr.

    Рис. 20.13. Вывод описаний переменных на экране диспетчера SNMP

    20.10.3 Типы данных MIB

    Причиной широкого распространения SNMP стало то, что проектировщики придерживались правила "Будь проще!"

    ■ Все данные MIB состоят из простых скалярных переменных, хотя отдельные части MIB могут быть логически организованы в таблицы.

    ■ Только небольшое число типов данных (например, целые числа или строки октетов) используется выражения значений всех переменных MIB.

    Фактически основные типы данных — это INTEGER (целое), OCTET STRING (строка октетов) и OBJECT IDENTIFIER (идентификатор объекта).

    20.10.4 Целые числа

    Целые числа используются в двух случаях:

    ■ Для ответа на вопрос "сколько?"

    ■ Для перечисления списка вариантов, например 1 = включено, 2 = выключено, 3 = тестирование.

    Ниже приведено определение, иллюстрирующее использование различных типов данных. Заметьте, что в первом определении формулировка SYNTAX ограничивает амплитуду значений.

    tcpConnLocalPort OBJECT-TYPE

     SYNTAX INTEGER (0..65535)

     ACCESS read-only

     STATUS mandatory

     DESCRIPTION

      "Номер локального порта для данного

      соединения TCP."

     :: = { tcpConnEntry 3 }


    ifAdminStatus OBJECT-TYPE

     SYNTAX INTEGER {

      up (1), - готов к пересылке пакета

      down (2),

      testing (3) - режим тестирования

     }


     ACCESS read-write

     STATUS mandatory

     DESCRIPTION

      "Требуемое состояние интерфейса. Тестирование (3) указывает

       на отмену пересылки пакетов."

     ::= { ifEntry 7 }

    20.10.5 Счетчики

    Счетчик — это положительное целое число, которое увеличивается до максимального значения и затем сбрасывается в ноль. Известно, что 32-разрядный счетчик может увеличиваться до 2³²-1 (4 294 967 295) и затем сбрасывается в 0. В версии 2 добавлен 64-разрядный счетчик, который может увеличиваться до 18 446 744 073 709 551 615.

    Значение счетчика само по себе не используется. Регистрируется текущее значение счетчика, а затем сравнивается с его предыдущим значением. Смысл имеет разность этих значений. Пример переменной со счетчиком:

    ifInOctets OBJECT-TYPE

     SYNTAX Counter

     ACCESS read-only

     STATUS mandatory

     DESCRIPTION

      "Общее количество полученных интерфейсом октетов,

       включая символы обрамления кадров."

     :: = { ifEntry 10 }

    20.10.6 Масштаб

    Масштаб (gauge) — это целое число, которое ведет себя по-разному. Значения масштаба увеличиваются и уменьшаются. Масштабы используются для количественного описания, например длины очереди. Иногда значение масштаба растет, а иногда уменьшается.

    32-разрядный масштаб может увеличиваться до 2³²-1 (4 294 967 295). Если измеряемая величина превышает масштаб, то она фиксируется в этом максимуме, пока значение снова не уменьшится (см. рис. 20.14).

    Рис. 20.14. Поведение значения масштаба

    Пример переменной масштаба:

    ifOutQLen OBJECT-TYPE

     SYNTAX Gauge

     ACCESS read-only

     STATUS mandatory

     DESCRIPTION

      "Длина выходной очереди пакетов

      (в пакетах)."

     ::= { ifEntry 21 }

    20.10.7 TimeTicks

    Интервалы времени измеряются в Time Ticks, размер которого выражается в сотых долях секунды. Значение TimeTick — неотрицательное целое число в пределах от 1 до 2³²-1. Для переполнения счетчика TimeTick потребуется 497 дней.

    SysUptime, измеряющая время от инициализации программного обеспечения агента,— это наиболее часто используемая переменная TimeTick.

    sysUpTime OBJECT-TYPE

     SYNTAX TimeTicks

     ACCESS read-only

     STATUS mandatory

     DESCRIPTION

      "Время (в сотых долях секунды) от последней инициализации

      части системы для сетевого управления."

     :: = { system 3 }

    20.10.8 Строки октетов

    OCTET STRING (строки октетов) — это последовательность байт. Почти любые данные можно представить строкой октетов.

    20.10.9 Текстовые соглашения

    Вместо определения новых типов данных в определении MIB применяются текстовые соглашения (textual conventions), позволяющие указать, что информация пакетирована в строки октетов, и описать способ ее вывода пользователям.

    Тип данных, определенный через текстовые соглашения, представляется для пересылки неформатированными значениями строки октетов. Однако реальный смысл типа данных определен в описании текстового соглашения. Существуют шаблоны MIB, используемые для создания текстовых соглашений. Приведем пример описания Display String.

    DisplayString ::= TEXTUAL-CONVENTION

     DISPLAY-HINT "255a"

     STATUS current

     DESCRIPTION

      "Представление текстовой информации, заимствованное из набора

       символов NVT ASCII, как определено на стр. 4 и 10-11 документа RFC 854."

    Следует помнить, что в сообщении значению всегда предшествует идентификатор объекта. Приложение станции управления могло бы использовать определение MIB, которое соответствует такому идентификатору, и применять описание текстового соглашения для выбора варианта отображения, хранения и использования полученного значения строки октетов.

    20.10.10 Копирование типов данных в BER

    Наряду с языком описания типов данных ASN.1 ISO специфицировала базовые правила кодирования (Basic Encoding Rules — BER), которые используются для кодирования значения данных SNMP при пересылке. Кодирование BER для значений данных имеет вид:

    [Идентификатор] [длина содержания] [содержание]

    Например, идентификатор X'02 используется для INTEGER, X'04 — для строки октетов, а X'06 — для идентификаторов объектов.

    Фактически все сообщение SNMP представляет собой последовательность значений ASN.1, и каждое сообщение полностью кодируется по BER

    20.11 Что дальше?

    Наиболее важная часть работы, которая не была реализована в текущей версии SNMP, — это определение новой административной структуры и спецификация условий аутентификации и стандартов шифрования для безопасного удаленного конфигурирования устройств. Однако уже предложены механизмы аутентификации и шифрования трафика на уровне IP (см. главу 24).

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

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

    Интеллектуальные системы, подобные маршрутизаторам и хостам, наиболее подходят для самоконтроля. Некоторые интересные результаты были получены при встраивании в системы управляющих приложений и общения с ними через браузеры WWW и протокол HTTP.

    20.12 Дополнительная литература

    Существует длинный и все разрастающийся список RFC, относящихся к SNMP и MIB. Архив RFC в InterNIC содержит самые последние версии этих документов.

    Наша другая книга — SNMP: Guide to Network Management — содержит описание концепции и структуры SNMP и детальный разбор некоторых модулей MIB.








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх