TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
Рис. 20.9. Типы сообщений SNMP версии 1
Ограничение обмена пятью типами сообщений сохранило простоту реализации и при этом обеспечило множество функциональных возможностей.
Обычно сетевые администраторы конфигурируют станцию управления на чтение статистики через регулярные интервалы, например через каждые 15 мин. Полученные значения могут быть сохранены и проанализированы, чтобы обнаружить пиковые нагрузки и определить необычные состояния.
Сообщение trap используется для отчета
■ Самостоятельная переинициализация
■ Локальный отказ связи
■ Восстановление связи
Комитеты стандартов MIB определили дополнительные сообщения trap для данных коммуникационных технологий. Кроме того, разработчики определяют trap для вывода информации о критических проблемах, связанных с работой их оборудования.
Частью концепции SNMP является то, что число пересылаемых сообщений trap должно быть относительно невелико. Сетевые администраторы часто сталкиваются с ситуацией, когда одна проблема приводит к появлению других. Наводнение сети потоком сообщений о проблемах может препятствовать выполнению операций по восстановлению нормальной работы.
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. Чтобы создать ответ, агент должен только заполнять пробелы и заменять пустые поля фактическими значениями.