Сети

Протокол SNMP: это очено просто

С появлением протокола SNMP (Simple Network Management Protocol) пользователи получили возможность осуществлять контроль за функционированием взаимодействующих ЛС на таком уровне, о котором раньше они не могли и мечтать. Некоторые аналитики предсказывают, что когда-нибудь SNMP будет использоваться в домашних условиях для управления работой таких устройств, как тостеры и проигрыватели компакт-дисков.

Недавно SNMP подвергся пластической операции: группа ведущих фирм внесла усовершенствования в данный протокол сетевого администрирования, в частности, включив в него функции защиты, разработав более рациональный способ сбора больших объемов данных, а также обеспечив совместное использование информации программами- менеджерами SNMP различных типов. Короче говоря, продукты, поддерживающие SNMP версии 2, должны продемонстрировать гораздо более высокую производительность в сетях с самой разной архитектурой, возможности обеспечения надежной защиты сообщений SNMP. Эти и другие усовершенствования означают, что администратору сети следует внимательно изучить преимущества SNMPv2. И даже если эти преимущества действительно окажутся неоспоримыми, пользователям рекомендуется подумать о наилучшей стратегии поддержки смешанной среды управления, где SNMPv1 все еще играет решающую роль.
Четко и ясно Для тех, кто не знаком с данной технологией, поясним: SNMP - это группа протоколов сетевого администрирования, используемых программными менеджерами и агентами (посредниками) для передачи данных. SNMP берет за основу модель, включающую станции администрирования, которые осуществляют мониторинг и контроль за определенными элементами. Стремясь сохранить приверженность своему основному принципу - простоте, протокол возлагает почти весь объем работ на станции администрирования, называемые менеджерами; в итоге на долю процесса-агента в контролируемом устройстве остается совсем немного. Добившись снижения удельного веса посреднической обработки, фирмы-производители SNMP-продуктов намерены включить ПО агента в свои системы, чтобы обеспечить возможность управления работой своих мостов, маршрутизаторов и других межсетевых устройств. Однако SNMP - это только часть так называемой системы межсетевого администрирования (Internet Network Management framework), в которую, помимо SNMP, входят описание структуры управляющей информации (SMI) и административные базы данных (MIB). SMI определяет, какие механизмы используются для описания и идентификации контролируемых объектов, представляющих собой специфическую совокупность данных, относящихся к контролируемому элементу. Например, скорость передачи, физический адрес, число поступающих пакетов с ошибками - все это уникальные контролируемые объекты в интерфейсе маршрутизатора ЛС.
Для определения конкретных контролируемых объектов протокол SNMP использует подмножество языка Abstract Syntax Notation One, зарегистрированного Международной организацией по стандартизации (ISO). MIB формирует из контролируемых объектов базу данных. Помимо базы данных MIB, выполненной по стандартам Internet, известны и другие MIB - уникальные для устройств типа моста или для продуктов конкретных фирм. Поэтому усовершенствование протокола SNMP затронуло все три области системы межсетевого администрирования, т.е. сам протокол, SMI и MIB.
По словам Джеффри Кейза (Jeffrey Case), президента компании SNMP Research (Ноксвилл, шт. Теннесси) и одного из четырех исследователей, выполнивших основную часть работ по SNMPv2, это была нелегкая задача. Три других участника проекта - Кит Макклори (Keith McCloghrie), один из авторов первоначальной версии SNMP, а ныне директор по проектированию фирмы Hughes LAN Systems, Маршалл Роуз (Marshall Rose) из компании Dover Beach Consulting (Маунтин-Вью, шт. Калифорния) и Стивен Уолдбассер (Steven Waldbusser), менеджер по сетевым разработкам университета Карнеги-Меллона в Питтсбурге сконструировали версию SNMPv2, объединив разработанный ими же протокол SMP (Simple Management Protocol) с новыми функциями защиты SNMP.
юМы не могли удовлетвориться уровнем защиты, обеспеченным в 1992- 1993 гг. Первоначально предполагалось изменить протокол в 1993-1994 гг., модернизировать SMI в 1994-1995 гг. и разобраться с MIB в 1995-1996 гг., - говорит Кейз. - Но такие сроки были бы неприемлемы, и нам пришлось сделать все разом. И вот вы получили 400 страниц новых спецификаций, включая справочный материал.ю Новые средства Многие новшества, описанные на этих 400 страницах, содержатся в документах по SMI и MIB - частям системы администрирования, которые в итоге будут оформлены в виде пересмотренных версий кода для разработчиков ПО. Например, определены новые типы данных для 64-разрядных счетчиков (вместо ранее имевшихся 32-разрядных), предназначенные для применения в высокоскоростных сетях. Предусмотрена возможность использования адресов протоколов OSI. Внесены улучшения в протокольные операции, благодаря которым конечным пользователям будет легче осуществлять повседневное управление работой сети. Сообщение SNMP в общем виде состоит из маркера защиты (wrapper) и протокольного блока данных (ПБД) формата SNMPv2 (см. рис. 1). В версии SNMPv1 использовались две структуры: одна для ПБД GetRequest, GetNextRequest, GetResponse и SetRequest, а другая - для ПБД Trap. В версии SNMPv2 формат всех этих сообщений имеет идентичный синтаксис, что значительно облегчает разработку кода. Кроме того, введены два новых ПБД: InformRequest и GetBulkRequest. Первый из них используется для передачи информации между двумя управляющими системами. Например, с помощью такого ПБД программа-менеджер может информировать другого менеджера об определенном состоянии сети.
Групповая обработка Блок GetBulkRequest применяется для получения административной информации большого объема с помощью одного запроса; данный ПБД считается одним из ключевых нововведений в SNMPv2 наряду с системой защиты и многопротокольным обменом.
С введением GetBulk (таково общепринятое название этого ПБД) пользователям достаточно будет выдать только один запрос в отношении целой строки данных, которая, например, может являться частью таблицы. Запрос такого типа должен способствовать смягчению требований к полосе пропускания сети благодаря использованию сигнального запроса на порцию данных вместо цепочки запросов GET или GetNext.
юВероятно, первое, что заметит конечный пользователь, - это увеличение производительности в результате появления блока GetBulk, - говорит Уолдбассер. - Это весьма существенное улучшение, особенно для тех, кто испытывал проблемы с обработкой больших объемов данных, поступающих, например, из крупных таблиц маршрутизации или таблиц моста в базе данных MIB удаленного мониторинга.ю Мультипротокольные возможности SNMP как протокол прикладного уровня формирует инфраструктуру связи с помощью нижележащих уровней - транспортного и сетевого. Инфраструктура SNMPv1 предназначалась для работы в сетях с протоколами TCP/IP и UDP/IP.
В SNMPv2 добавлены функции обеспечения трафика SNMP в сетях на базе AppleTalk, OSI и IPX (рис. 2). По словам Кейза, поддержка дополнительного транспортного протокола дает возможность пользователю, имеющему управляющую станцию администрирования в Чикаго, работать с локальной сетью в Цинциннати, в которой тип протокола отличен от TCP/IP. Административный запрос посылается в Цинциннати в формате TCP/IP, затем ювстраиваетсяю в формат IPX для локальной передачи. Ответ поступает в формате IPX, ювынимаетсяю из оболочки IPX и отправляется назад посредством TCP/IP. Дополнительная нагрузка на сеть будет связана с выполнением отображения адресов IP и IPX. Впрочем, эту операцию можно осуществить при помощи табличной функции.
юРаньше вы не могли бы общаться с другой сетью, тип протоколов в которой отличен от TCP/IPю, - говорит Кейз. Расширенная поддержка передачи, несомненно, понравится пользователям, равно как и более богатый набор кодов ошибок, которые не только указывают на ту или иную проблему, но и подсказывают пользователю возможное ее происхождение. Это очень важно, например, если программа- менеджер с помощью ПБД SET требует, чтобы программа-агент записала значение объекта. При неудачном завершении такой операции в случае SNMPv1 возвращается ПБД GetResponse с кодом ошибки badValue. Версия же SNMPv2 отреагирует более детально: будет возвращен один из нескольких кодов ошибок - wrongType, wrongLength, wrongEncoding или wrongValue, что поможет пользователю определить источник ошибки. Защита в SNMP Один из наиболее заметных недостатков SNMPv1 - отсутствие развитой системы защиты данных на уровне, необходимом для сетей масштаба предприятия.
В SNMPv1 защита административной информации трактовалась слишком упрощенно: она базировалась на использовании коллективного имени (Community Name), которое, находясь в заголовке SNMP, несло в себе все возможности защиты сообщений. Данное средство (известное под названием ютривиальный протоколю) требовало, чтобы программа-агент и менеджер опознали одно и то же коллективное имя, прежде чем продолжить выполнение операций сетевого администрирования. В результате многие администраторы сетей ограничивались в своей работе только функциями мониторинга, запрещая выдачу команды SET, способной изменять параметры конфигурации удаленного устройства. Это привело к тому, что пользователи избегали команд SET: такое примитивное средство защиты, как коллективное имя, могло дать возможность лицам, не наделенным соответствующими полномочиями, изменять параметры, о чем пользователи могли даже и не узнать. В связи с этим были разработаны предложения по совершенствованию защиты в рамках SNMPv1, представленные в июле 1992 г.; они составили основу структуры защиты для SNMPv2.
Стандартами защиты SNMPv2 определяются методы аутентификации и обеспечения конфиденциальности (с помощью шифрования) информации административного характера. Аутентификация позволяет гарантированно идентифицировать источник сообщения, а конфиденциальность дает возможность защитить сообщение от несанкционированного чтения.
Защита связи требует описания взаимоотношений между различными объектами SNMPv2. В основе модели таких отношений лежит концепция юучастникаю (party) - уникального набора параметров защиты, который может включать местоположение сети, протоколы аутентификации и обеспечения конфиденциальности, используемые между агентом и менеджером, и т.д. Например, участник может определять протоколы аутентификации, тип шифрования, максимальный размер сообщения и даже используемый секретный ключ.
Затем защищенные сообщения SNMP передаются между двумя участниками. Впрочем, для объекта SNMPv2 можно определить несколько участников, каждого со своими параметрами. Например, для разных участников могли применяться различные протоколы аутентификации или обеспечения конфиденциальности, и менеджер SNMP мог воспользоваться одним ключом для связи с первым агентом и другим ключом - для связи со вторым. Чтобы наладить связь, все параметры участника, а также соответствующие параметры протоколов, такие как ключи шифрования, должны пройти проверку на достоверность. При использовании средств защиты информация, относящаяся к аутентификации и конфиденциальности, помещается в маркер сообщения, предшествующий ПБД.
Фирмы-производители систем с SNMPv2 для обеспечения защиты пользуются двумя протоколами: аутентификации (Digest Authentication Protocol) и обеспечения конфиденциальности (Symmetric Privacy Protocol). Первый проверяет целостность сообщения (полученное сообщение должно в точности совпадать с посланным) и его источник. Второй протокол используется для обеспечения конфиденциальности сообщений и основан на методе шифрования сообщения с помощью секретного ключа, известного только отправителю и получателю. Помимо этого, зашифрованное сообщение должно пройти аутентификацию, как описано выше. В данном алгоритме применяется стандарт шифрования данных (DES), на который накладываются экспортные и лицензионные ограничения. В каком объеме фирмы-производители будут реализовывать средства защиты - вопрос пока открытый. юПо-видимому, 95% компаний предоставят средства аутентификации, - говорит Макклори. - Шифрование по стандарту DES не будет обязательным компонентом; я думаю, одни компании реализуют его, а другие - нет.ю По словам Макклори, одна из задач, стоящих перед производителями, - обеспечить возможности защиты с помощью простых интерфейсов пользователя, которые должны скрыть истинную сложность систем защиты и повысить вероятность их применения.
Производители считают, что введение дополнительных уровней защиты заставит пользователей пересмотреть стратегию внедрения средств SNMP в своих сетях. юГибкость и надежность функций защиты SNMPv2 могут повлечь за собой изменение пользователями своей политики в области операционных сред и рабочих процедур, - полагает Джо Мэтибэг (Joe Matibag), старший менеджер по продуктам компании SunConnect (Маунтин-Вью, шт. Калифорния). - Теперь администраторам сетей придется определять и отслеживать, кто и к какому компоненту административной информации имеет доступ. Чтобы свести к минимуму воздействие таких изменений и сделать их возможно более дешевыми, компании-поставщики платформ и устройств администрирования должны будут изыскать простой способ инициализации, настройки конфигурации и инсталляции разнообразных средств защиты протокола SNMPv2, возможно, с помощью объектно-ориентированных технологий.ю Как менеджер менеджеру Получив столь желанные возможности защиты в SNMP, пользователи вместе с тем приобрели наконец и еще одно долгожданное средство - связь между программными менеджерами.
Фундаментальным новшеством в SNMPv2 является то, что элемент администрирования сети может работать в качестве менеджера, агента или менеджера и агента одновременно. Данная концепция дает возможность пользователям применять SNMP в иерархической структуре, в которой локальные менеджеры отчитываются перед менеджерами среднего звена, которые, в свою очередь, контролируются менеджером высшего уровня. Например, в каждом локальном сегменте может функционировать менеджер SNMP, действующиий как агент по отношению к менеджеру более глобального плана. Такая возможность называется дуализмом элементов SNMPv2. При получении административного запроса такой объект ведет себя как агент. Когда запрошенный сервис предоставлен, объект опять становится менеджером. Предусмотрена новая административная база данных MIB под названием Manager-to-Manager MIB, определяющая механизм, с помощью которого менеджер может направлять запрос на услуги по администрированию другому менеджеру, и призванная, в конечном счете, обеспечить взаимодействие менеджеров различных типов между собой. Джон Сапириа (Jon Saperia), консультант по сетевым технологиям корпорации Digital Equipment, рассматривает системы иерархического управления как механизм разделения нагрузки в крупномасштабных сетях: юСтанция администрирования может быть предназначена для контроля за группой сетевых объектов, обеспечивая совместное использование требуемой информации с другими управляющими платформами по мере необходимостию. По его мнению, это поможет сократить ненужный сетевой трафик. При таком подходе за ключевыми ресурсами сети можно следить с помощью одной системы администрирования. Другие менеджеры будут оповещаться предупреждающими сигналами, выдаваемыми только в случае возникновения критической ситуации, например при недоступности аппаратных или программных ресурсов. Переход на новую версию Усовершенствования, внесенные в SNMP, выглядят чрезвычайно привлекательно. Несомненно, пользователи захотят иметь продукты на базе SNMPv2. Но дело в том, что многие уже вложили слишком большие средства в версию SNMPv1, чтобы просто выбросить ее и начать все с нуля. Авторы SNMPv2 предвидели это и исходили из постепенности перехода на новую технологию. Предусмотрены два способа сохранения SNMPv1: использование уполномоченных агентов и двуязычных менеджеров. Уполномоченный агент выполняет преобразование форматов SNMPv1 в сообщения SNMPv2 и обратно.
Когда происходит преобразование из SNMPv2 в SNMPv1, ПБД GetRequest, GetNextRequest и SetRequest передаются со станции менеджера непосредственно в программу-агент SNMPv1, которая затем преобразует ПБД GetBulkRequest в ПБД GetNext. При преобразовании из SNMPv1 в SNMPv2 ПБД GetResponse передается менеджеру без изменений, а ПБД Trap версии SNMPv1 отображается в ПБД Trap версии SNMPv2 с небольшими модификациями.
Другой вариант - двуязычный менеджер, который одновременно поддерживает оба протокола (SNMPv1 и SNMPv2) и не требует преобразований. Двуязычный менеджер SNMP определяет, с каким форматом работает агент - версии 1 или версии 2, и общается на соответствующем диалекте. Таким образом, выбор версии протокола должен быть прозрачен для принимающих устройств. На каком из двух вариантов остановиться - зависит от приложения.
Например, уполномоченный агент подходит в следующем случае: у пользователей есть менеджер SNMPv2 в Чикаго, и они хотят контролировать защищенную локальную сеть в Канзас-Сити, но каналы связи между Чикаго и Канзас-Сити не защищены. юВ данной ситуации, - предлагает Кейз, - пользователи могут запустить SNMPv2 между Канзас-Сити и Чикаго, разместить программу уполномоченного агента в Канзас-Сити и осуществлять там преобразование из формата SNMPv2 в SNMPv1.ю Следует помнить, что уполномоченный агент - это всего лишь еще один элемент конфигурации, который может дать сбой. Фирма SNMP Research реализовала оба средства: программу уполномоченного агента и вариант с двуязычным менеджером.
Время покажет Протокол SNMPv2 представляется значительно усовершенствованным вариантом своего предшественника, который, как известно, снискал изрядную популярность среди пользователей. С точки зрения логики, SNMPv2 юобреченю на такой же успех.
Но как и в случае любой другой технологии, главное - доступность, а здесь музыку заказывают фирмы- производители. Безусловно, многие фирмы будут поддерживать SNMPv2. Вопрос в том, в каком объеме реализуется эта поддержка.
SNMPv2 сулит выгоды в плане защиты и производительности, что немаловажно для пользователей. Но некоторые компании наверняка предложат свои собственные идеи, особенно в части защиты и связей между менеджерами. Кроме того, фирмы, расширившие функциональные возможности своих баз данных MIB в средах с SNMPv1, вряд ли будут спешить с выпуском продуктов под SNMPv2. Так или иначе, Кейз предсказывает, что ряд компаний в ближайшее время представит свои продукты на основе SNMPv2. По его мнению, фирмы, опоздавшие с их анонсированием, сильно рискуют. Что ж, время покажет.
Производители осваивают SNMP Если выбрать наугад несколько фирм-производителей, то окажется, что большинство из них уже приступило к выпуску средств поддержки последней редакции протокола SNMP, хотя некоторые поставщики еще не приняли на вооружение данную технологию.
Как следует из заявления Марка Финкернагеля (Mark Finkernagel), старшего менеджера по продуктам компании NCR, отделение сетевого и системного администрирования NCR, которое отвечает за разработку продуктов StarSentry, намерено предложить реализацию версии SNMPv2. Выпуск средств поддержки SNMPv2 намечен на начало 1994 г., вслед за поставками системы сетевого администрирования OverLord.
По словам Роджера Дева (Roger Dev), директора по вопросам проектирования и производства компании Cabletron, средства для SNMPv2 появятся не позднее первого квартала 1994 г., причем по прежним ценам. Корпорация Chipcom намерена предложить поддержку протокола SNMPv2 по первому требованию со стороны заказчиков. Фирма IBM также собирается заняться продуктами для SNMPv2 в этом году. Все компании единодушны в том, что самые нужные для пользователей возможности SNMPv2 - это средства защиты. Существует область - связь между менеджерами, - где некоторые фирмы менее склонны обеспечивать полную поддержку SNMPv2, поскольку появление SNMPv2 еще не означает, что нужно похоронить протокол Common Management Infomation Protocol (CMIP). Финкернагель рисует красочные картины мирного сосуществования SNMP и менеджеров CMIP. юНаша точка зрения такова, что CMIP будет отвечать за административную информацию, совместно используемую несколькими платформами, а SNMPv2 - за данные, передаваемые между платформой и программой-агентомю, - говорит Финкернагель.
Дев считает, что протокол SNMPv2 помешает развертыванию CMIP, если будет развиваться такими же бурными темпами: юSNMPv2 пока остается примитивным протоколом низкого уровня, который требует серьезного усовершенствованияю. Рик Силетти (Rick Silletti), менеджер корпорации IBM по вопросам поддержки средств администрирования сетей масштаба предприятий, утверждает, что SNMPv2 - это не похоронный марш для CMIP. юЗаказчикам нужны оба протоколаю, - говорит он.
N09_94 c.16-18 p.154-94 - 156-94