Шрифт:
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 должно быть относительно невелико. Сетевые администраторы часто сталкиваются с ситуацией, когда одна проблема приводит к появлению других. Наводнение сети потоком сообщений о проблемах может препятствовать выполнению операций по восстановлению нормальной работы.