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

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

Отметить Добавить цитату