Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Сообщения trap в версии 1 были более сложными, чем следовало бы. Такое положение было исправлено в версии 2. Рассмотрим сначала сообщения trap версии 1. В них имеется общее поле (generic trap), значение которого определяет тип прерывания в соответствии со следующим списком:

На рис. 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 она была проще.

Следующие свойства SNMP версии 1 были не слишком удачны:

■ Если одна из переменных в запросе get или get-next была некорректна, то отбрасывалось все сообщение.

■ Если запрашивались значения нескольких переменных и агент не мог разместить ответ в самом большом по размеру сообщении, отбрасывалось все сообщение.

■ Сообщения trap реализовывали простые функции, но имели сложную структуру.

Все эти проблемы были решены в версии 2. Теперь агент может помещать код ошибки в поле значения переменной, которая не может быть обработана. Появился новый запрос get-bulk, требующий от агента возврата максимально возможного объема информации. Сообщения trap стали иметь такой же простой формат, как и все другие сообщения.

В версии 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.