Удаленный монитор может самостоятельно собирать локальные данные, проводить диагностику оборудования и обнаруживать опасные состояния. Так как о проблемах становится известно при их возникновении, сетевые станции управления могут регулировать частоту запросов данных 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 и ответ на него
