Протокол snmp

Агентом называется функция программного обеспечения, которая встроена в боль­шинство сетевых устройств (рис. 16.20). Агент отвечает за обработку запросов протокола SNMP, поступающих от менеджера управления сетью. Он также отвечает за выполнение стандартных операций, которые поддерживают значения переменных, определенных в различных поддерживаемых базах MIB.

Взаимодействие между менеджером и агентом облегчается при использовании "протокола вопросов и ответов", т.е. протокола SNMP. Термин "простой" в назва­нии протокола связан с ограниченным количеством типов сообщений, которые яв­ляются частью первоначальной спецификации протокола. При его создании была избрана стратегия облегчения для разработчиков встраивания функций управления в сетевые устройства. Первоначальная спецификация этого протокола получила на­звание SNMPvl (версия 1).

На рис. 16.21 показаны три типа сообщений протокола SNMP, отправляемых станциями управления NMS: GetRequest, GetNextRequest и SetRequest. Агент управ­ления подтверждает получение сообщений этих трех типов в виде сообщения GetResponse. Кроме этого агент может отправить сообщение Trap в виде реакции на событие, которое может оказать влияние на базу MIB и связанные с ней ресурсы.

Быстрое появление второй версии протокола —SNMPv2c (версия 2с) было реакци­ей на заметные ограничения протокола SNMPvl. Наиболее заметными улучшениями были введение нового типа сообщений GetBulk Request и добавление 64-битовых счет­чиков. Получение информации с помощью сообщений GetRequest и GetNextRequest оказалось неэффективным методом сбора информации от структур табличных данных устройств сети. Протокол SNMPvl позволял запросить за один раз значение лишь од­ной переменной. Введение сообщения-запроса GetBulk Request позволило устранить этот недостаток. При его использовании менеджер получает "весь объем" информа­ции с помощью лишь одного запроса. Введение 64-битовых счетчиков в базах MIB бы­ло призвано решить проблемы слишком быстрого переполнения счетчиков, которое было особенно заметно в высокоскоростных каналах, таких как Gigabit Ethernet.

Субъект управления также называется менеджером или станцией NMS, как по­казано на рис. 16.22. Он отвечает за отправку запроса на информацию от агента. Та­кие запросы имеют специфический характер. Менеджер обрабатывает полученную информацию несколькими типичными способами. Эта информация может быть за­писан в журнал для дальнейшего анализа, отображена с помощью какой-либо гра­фической утилиты или соотнесена с заранее заданными значения для выяснения вопроса о превышении некоторых заданных пороговых значений.

Не все функции менеджера связаны с получением данных. Есть также возмож­ность внести изменения в значения переменных на управляемом устройстве. Это позволяет контролировать конфигурацию управляемого устройства.

Взаимодействие между менеджером и управляемым устройством вызывает уве­личение объема передачи данных по сети. Поэтому при установке менеджеров в сети требуется соблюдать определенную осторожность. Энергичные стратегии монито­ринга могут отрицательно повлиять на производительность сети. Интенсивность использования полосы пропускания может возрасти и создать проблемы в среде распределенных сетей WAN. Другой аспект воздействия мониторинга сети на ее ра­боту связан с управляемыми устройствами. Этим устройствам приходится обрабаты­вать запросы менеджера; эти функции не должны оказываться более важными, чем производительные функции устройств.

Общей рекомендацией в данном случае является стремление получать минимум информации и, по возможности, реже. Поэтому следует определить, какие устрой­ства и каналы наиболее важны и какой уровень подробности данных является необ­ходимым.

Протокол SNMP использует в качестве своего транспортного протокола протокол дейтаграмм пользователя (User Datagram Protocol — UDP). Вследствие этого в прото­коле SNMP возможна потеря сообщений. Протокол SNMP не имеет средств, которые бы обеспечивали гарантированную доставку, поэтому проблема утерянных модулей данных протокола (protocol data unit — PDU) должна решаться приложением, исполь­зующим протокол SNMP.

Как показано на рис. 16.23, каждое сообщение протокола SNMP содержит переда­ваемую открытым текстом строку (строку сообщества), такую как пароль, для ограни­чения доступа к управляемым устройствам. Хотя сам такой подход был достаточно плодотворным, поскольку строки сообщества передавались открытым текстом он вме­сте с тем поставил проблему безопасности. Создание версии SNMPv3 (версия 3) по­зволило устранить многие проблемы связанные с обеспечением безопасности.

На рис. 16.24 показано, как выглядят сообщения протокола SNMPv2c. Подроб­ное описание этого протокола можно найти в стандарте Internet RFC 1157.

Тот факт, что строка сообщества передается открытым текстом, не удивит никого, знакомого со стеком протоколов IP. Все поля, указанные в стеке этого протокола пе­редаются открытым текстом, за исключением спецификаций аутентификации и шиф­рования.

Строка сообщества заменяла по существу систему безопасности до тех пор, пока рабочая группа версии SNMPv2 не ратифицировала механизмы безопасности. Эти вопросы были вскоре переданы рабочей группе по версии SNMPv3. Соответственно, все основанные на протоколе SNMP приложения управления сетями требовали со­ответствующего конфигурирования для использования соответствующих строк со­общества. Кроме этого, некоторые организации часто меняют значения строк сооб­щества для уменьшения риска попыток враждебных действий по несанкциониро­ванному доступу и использованию службы SNMP.

Несмотря на недостатки, связанные с использованием аутентификации, осно­ванной на сообществах, стратегии управления по-прежнему базируются на протоко­ле SNMPvl. Устройства Cisco поддерживают типы сообщений протокола SNMPv3 и, соответственно, имеют большую степень безопасности, однако большинство при­ложений по управлению сетью не поддерживают протокол SNMPv3, как показано на рис. 16.25.