На рис. 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), определяющее фактические минимальные требования для модуля