Компания HP
Опубликован: 22.09.2006 | Доступ: свободный | Студентов: 675 / 67 | Оценка: 4.22 / 3.72 | Длительность: 22:59:00
ISBN: 978-5-9556-0042-6
Лекция 8:

Управление событиями с использованием NNM

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >

Прерывания от ожидаемых и неожиданных источников

SNMP-прерывания по умолчанию передаются на порт UDP 162. В число источников SNMP-прерываний входят NNM и сетевые устройства. NNM генерирует внутренние прерывания (часто свободно именуемые событиями), называемые прерываниями, специфичными для предприятия (enterprise-specific). NNM также может генерировать специальные SNMP-прерывания в ответ на действия, запрограммированные в ovevent.

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

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

Таблица 8.1. Типы прерываний SNMP
Номер прерывания Описание
0 Прерывание coldStart посылается при первом запуске агента SNMP, что обычно происходит во время начальной загрузки
1 Прерывание warmStart посылается, когда перезапускается агент SNMP, ранее уже бывший активным. Часто это делается, чтобы заставить агента прочитать его конфигурационный файл, который изменился
2 Прерывание linkDown посылается, когда агент SNMP устанавливает, что один из интерфейсов отключен в эксплуатационном режиме. Прерывание посылается на дублирующий интерфейс, если он доступен; иначе оно теряется
3 Прерывание linkUp посылается, когда агент SNMP выявляет, что ранее отключенный в эксплуатационном режиме интерфейс теперь функционирует. Для отражения этого события NNM изменяет состояние управляемого устройства
4 Прерывание authenticationFailure посылается, когда агент SNMP получает запрос с неправильной строкой сообщества. Запрос игнорируется
5 Прерывание egpNeighborLoss посылается маршрутизатором, сконфигурированным с ориентацией на протокол EGP (Exterior Gateway Protocol), когда он теряет контакт со своим соседом
6 В специальном прерывании NCC-1701 используется второй параметр, номер специального прерывания, определенного поставщиком для обозначения особой проблемы. Например, маршрутизатор мог бы генерировать прерывание "отказ вентилятора", а коммутатор мог бы генерировать прерывание "порт 2 сегментирован"

Чтобы получить самую последнюю версию файла MIB, можно попробовать поискать его на инсталляционном CD NNM, обратиться к компании-поставщику, в которой был произведен файл MIB, или поискать в web (ftp://ftp.isi.edu/mib/). Следует убедиться, что определение MIB, загруженное в базу данных MIB системы NNM, соответствует версии MIB, которая используется на самом устройстве. Для удобства пользователей инсталляционный CD NNM содержит сотни определенных поставщиками MIB. Нужно просто загрузить те MIB, которые подходят для конкретной сетевой конфигурации.

Иногда события бывают настолько интересными, что администратор NNM будет конфигурировать автоматическую реакцию посредством GUI конфигурирования событий. Например, если бы вышел из строя критический интерфейс маршрутизатора, соответствующая автоматическая реакция могла бы заключаться в посылке короткого сообщения по e-mail на пейджер дежурного менеджера сети.

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

Потоки syslog от устройств и ovevent

Сетевое оборудование часто конфигурируется таким образом, чтобы консольные сообщения передавались по сети на некоторый узел и журнализировались с использованием его службы syslog. Во всех UNIX системах имеется демон с именем syslogd, который слушает UDP-порт 514 и журнализирует полученные сообщения в файле, имя которого указывается в файле /etc/syslog.conf. (см. пример на рис. 8.1).

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

Как можно следить за этим файлом? Данные в файлах syslog не отслеживаются непосредственно NNM, и информация в нем может быть не видна, если смотреть "глазами" SNMP.

Если используется демон HP OV Operations, он может быть сконфигурирован для исследования этого файла при увеличении его размера, поиска специальных текстовых строк со специальным смыслом и генерации сигнала HP OV Operations. Возможно, в этом случае HP OV Operations нельзя считать подходящим инструментом, поскольку управляющее приложение выполняется где-то в другом месте.

Альтернативное и, возможно, предпочтительное решение состоит в том, чтобы для отслеживания файла syslog маршрутизаторов запустить небольшой UNIX-скрипт в фоновом режиме. Скрипт может выполнять следующие шаги:

  • tail –f /var/log/routerlog, чтобы следить за файлом и отбирать новые данные;
  • проверить каждую строку на наличие специального текста;
  • переформатировать строку, чтобы удалить метасимволы;
  • идентифицировать устройство, которое послало сообщение syslog ;
  • назначить код серьезности (зависит от содержания сообщения);
  • назначить категорию события (возможно, специальную);
  • послать сообщение в поток событий NNM с помощью ovevent.
Файл syslog.conf

увеличить изображение
Рис. 8.1. Файл syslog.conf

В среде UNIX демон syslogd журнализирует входящие UDP-сообщения в одном из перечисленных регистрационных файлов. Например, маршрутизаторы можно сконфигурировать для отсылки их консольных сообщений в систему NNM. Они будут журнализироваться в отдельном файле /var/log/routerlog.

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >