Шрифт:
20.8.2 Транспортные протоколы
В качестве наиболее предпочтительного транспорта был выбран протокол UDP. Это объясняется его простотой и реализацией с помощью очень небольшого кода. Такой выбор особенно подходит для работы устройств в режиме перегрузки или при неисправности. Однако для SNMP могут использоваться и другие транспортные протоколы. Например, в окружении NetWare протокол SNMP может работать поверх IPX.
Когда используется UDP, каждое сообщение SNMP вкладывается в одну датаграмму UDP и доставляется через IP. Как показано на рис. 20.9, запросы направляются на порт 161 от любого удобного порта UDP. Ответы возвращаются на запрашивающий порт. Сообщения trap исходят из любого удобного порта UDP и направляются на порт 162.
Все реализации версии 1 должны быть способны обрабатывать сообщения длиной, по крайней мере, в 484 октета.
20.9 Форматы сообщений SNMP
Сообщение SNMP версии 1 состоит из некоторого вводного материала — "обертки",— сопровождаемого сообщением Protocol Data Unit одного из пяти типов: get-request, get-next-request, get-response, set-request или trap. Вводный материал содержит:
| Версию протокола | 0 для SNMP версии 1 и 1 для версии 2 |
| Имя сообщества | используется как пароль |
Агент конфигурируется на ограничение (по имени сообщества) доступа к информации по чтению или записи. Кроме того, можно указать IP-адрес станции управления, которой разрешен доступ по чтению или записи информации MIB.
К сожалению, имя сообщества в сообщении можно легко подглядеть с помощью любого сетевого анализатора, а IP-адрес иногда можно сфальсифицировать. Одним из решений является доступ к важным устройствам (например, маршрутизаторам) через отдельную, безопасную линию связи, особенно при изменении конфигурации или статуса системы.
20.9.1 Формат сообщений gets, sets и responses в версии 1
Главное информационное содержимое во всех этих сообщениях одинаково. Оно состоит из списка (пары этого списка обычно называют "связыванием переменной"):
| Имя переменной | Значение |
| Имя переменной | Значение |
| … | … |
Идентификатор объекта используются как имя переменной. В сообщениях get и get-next поля значений пустые. В них агент разместит необходимые значения.
Элемент данных протокола (Protocol Data Unit) для сообщений get-request, get-next-request, set-request или response включает:
| Идентификатор запроса | Служит для согласования запроса и ответа на него. |
| Поле статуса ошибки | 0 в запросах. Ненулевые значения в ответах означают различные ошибки. |
| Поле индекса ошибки | 0 в запросах. В ответах указывает переменную, создавшую ошибку. |
| Список идентификаторов объектов и значений | В get или get-next — пустые, но заполнены в set или response. |
20.9.2 Запрос get и ответ на него
На рис. 20.10 показаны запрос get-request и ответ на него (response), полученные в анализаторе Sniffer компании Network General. Запрос содержит список из пяти переменных, значения которых нужно получить. После каждого идентификатора переменной стоит заполнитель NULL. Чтобы создать ответ, агент должен только заполнять пробелы и заменять пустые поля фактическими значениями.