Софт-Портал

Snmp Client

Рейтинг: 5.0/5.0 (391 проголосовавших)

Категория: Windows

Описание

Протокол управления SNMP

4.4.13 Протокол управления SNMP

Интернет - гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без единого управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ - сеть сохраняет работоспособность за счет жесткой протокольной регламентации. "Запас прочности" заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол ICMP. Учитывая важность функции управления, для этих целей создано два протокола SNMP (Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089, std-15 разработан в 1988 году) и CMOT (Common Management Information services and protocol over TCP/IP, RFC-1095, в последнее время применение этого протокола ограничено). Обычно управляющая прикладная программа воздействует на сеть по цепочке SNMP-UDP-IP-Ethernet. Наиболее важным объектом управления обычно является внешний порт сети (gateway) или маршрутизатор сети. Каждому управляемому объекту присваивается уникальный идентификатор.

Протокол SNMP работает на базе транспортных возможностей UDP (возможны реализации и на основе ТСР) и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB - management information base, RFC-1213, -1212, std-17 ). Смотри Essential SNMP. Douglas R. Mauro and Kevin J. Schmidt. O’Reilly, Второе издание. 2001. На русском языке книга вышла под название Основы SNMP в 2012 г в изд. Символ, Петербург (перевод Р. Багаутдинова, научным редактором перевода был я).

Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр. Ниже приведена таблица (4.4.13.1) команд (pdu - protocol data unit) SNMP:

Таблица 4.4.13.1 Команды SNMP

Получить значение указанной переменной или информацию о состоянии сетевого элемента;

Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);

Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено;

Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные);

Информация о TRAP содержится в поле специальный код.

Для тип TRAP 0-4 поле специальный код должно быть равно нулю. Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так прерывание coldstart выдается объектом через 200 мс после инициализации.

В последнее время широкое распространение получила идеология распределенного протокольного интерфейса DPI (Distributed Protocol Interface). Для транспортировки snmp-запросов может использоваться не только UDP-, но и TCP-протокол. Это дает возможность применять SNMP-протокол не только в локальных сетях. Форматы SNMP-DPI-запросов (версия 2.0) описаны в документе RFC-1592. Пример заголовка snmp-запроса (изображенные поля образуют единый массив; см. рис. 4.4.13.3):

Поле Флаг =0x30 является признаком ASN.1-заголовка. Коды Ln - представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n - номер поля длины), если не оговорено другое. Так L1 - длина пакета-запроса, начиная с T1 и до конца пакета, а L3 - длина поля пароля. Субполя Tn - поля типа следующего за ними субполя запроса. Так T1=2 означает, что поле характеризуется целым числом, а T2=4 указывает на то, что далее следует пароль (поле community, в приведенном примере = public). Цифры под рисунками означают типовые значения субполей. Код 0xA - является признаком GET-запроса, за ним следует поле кода PDU (=0-4, см. табл. 4.4.13.1) Блок субполей идентификатора запроса служит для тех же целей, что и другие идентификаторы - для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением Lиз. СО - статус ошибки (СО=0 - ошибки нет); ТМ - тип MIB-переменной (в приведенном примере = 0x2B); ИО - индекс ошибки. Цифровой код MIB-переменной отображается последовательностью цифровых субполей, характеризующих переменную, например: переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) характеризуется последовательностью кодов 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.

Начиная с января 1998 года, выпущен набор документов, посвященных SNMPv3. В этой версии существенно расширена функциональность (см. таблицу 1 тип PDU=5-8), разработана система безопасности. В данной версии реализована модель, базирующаяся на процессоре SNMP (SNMP Engene) и содержащая несколько подсистем (дипетчер, система обработки сообщений, безопасности и управления доступом, см. рис. 4.4.13.4). Перечисленные подсистемы служат основой функционирования генератора и обработчика команд, отправителя и обработчика уведомлений и прокси-сервера (Proxy Forwarder), работающих на прикладном уровне. Процессор SNMP идентифицируется с помощью snmpEngineID. Обеспечение безопасности модели работы SNMP упрощается обычно тем, что обмен запросами-откликами осуществляется в локальной сети, а источники запросов-откликов легко идентифицируются.

Компоненты процессора SNMP перечислены в таблице 4.4.13.5 (смотри RFC 2571 и -2573)

Таблица 4.4.13.5. Компоненты процессора SNMP

Позволяет одновременную поддержку нескольких версий SNMP-сообщений в процессоре SNMP. Этот компонент ответственен за прием протокольных блоков данных (PDU), за передачу PDU подсистеме обработки сообщений, за передачу и прием сетевых SNMP-сообщений

Подсистема обработки сообщений

Ответственна за подготовку сообщений для отправки и за извлечение данных из входных сообщений

Предоставляет услуги, обеспечивающие безопасность: аутентификацию и защищенность сообщений от перехвата и искажения. Допускается реализация нескольких моделей безопасности

Подсистема управления доступом

Предоставляет ряд услуг авторизации, которые могут использоваться приложениями для проверки прав доступа.

Инициирует SNMP-запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, которые могут использоваться приложениями для проверки прав доступа.

Воспринимает SNMP-запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, это индицируется тем, что contextEngeneID в полученном запросе равно соответствующему значению в процессоре SNMP. Приложение обработчика команд выполняет соответствующие протокольные операции, генерирует сообщения отклика и посылает их отправителю запроса.

Мониторирует систему на предмет выявления определенных событий или условий и генерирует сообщения Trap или Inform. Источник уведомлений должен иметь механизм определения адресата таких сообщений, а также параметров безопасности

Прослушивает сообщения уведомления и формирует сообщения-отклики, когда приходит сообщение с PDU Inform

Переадресует SNMP-сообщения. Реализация этогог модуля является опционной

На рис. 4.4.13.5 показан формат сообщений SNMPv3, реализующий модель безопасности UBM (User-Based Security Model).

Первые пять полей формируются отправителем в рамках модели обработки сообщений и обрабатываются получателем. Следующие шесть полей несут в себе параметры безопасности. Далее следует PDU (блок поля данных) с contextEngeneID и contextName .

  • msgVersion (для SNMPv3)=3
  • msgID - уникальный идентификатор, используемый SNMP-сущностями для установления соответствия между запросом и откликом. Значение msgID лежит в диапазоне 0 - (2 31 -1)
  • msgMaxSize - определяет максимальный размер сообщения в октетах, поддерживаемый отправителем. Его значение лежит в диапазоне 484 - (2 31 -1) и равно максимальному размеру сегмента, который может воспринять отправитель.
  • msgFlags - 1-октетная строка, содержащая три флага в младших битах: reportableFlag, privFlag, authFlag. Если reportableFlag=1, должно быть прислано сообщение с PDU Report; когда флаг =0, Report посылать не следует. Флаг reportableFlag=1 устанавливается отправителем во всех сообщениях запроса (Get, Set) или Inform. Флаг устанавливается равным нулю в откликах, уведомлениях Trap или сообщениях Report. Флаги privFlag и authFlag устанавливаются отправителем для индикации уровня безопасности для данного сообщения. Для privFlag=1 используется шифрование, а для authFlag=0 - аутентификация. Допустимы любые комбинации значений флагов кроме privFlag=1 AND authFlag=0 (шифрование бех аутентификации).
  • msgSecurityModel - идентификатор со значением в диапазоне 0 - (2 31 -1), который указывает на модель безопасности, использованную при формировании данного сообщения. Зарезервированы значения 1 для SNMPv1,2 и 3 - для SNMPv3.

Модель безопасности USM (User-Based Security Model) использует концепцию авторизованного сервера (authoritative Engene). При любой передаче сообщения одна или две сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP-сервера. Это делается согласно следующим правилам:

  • Когда SNMP-сообщение содержит поле данных, которое предполагает отклик (например, Get, GetNext, GetBulk, Set или Inform), получатель такого сообщения считается авторизованным.
  • Когда SNMP-сообщение содержит поле данных, которое не предполагает посылку отклика (например, SNMPv2-Trap, Response или Report), тогда отправитель такого сообщения считается авторизованным.

Таким образом, сообщения, посланные генератором команд, и сообщения Inform, посланные отправителем уведомлений, получатель является авторизованным. Для сообщений, посланных обработчиком команд или отправителем уведомлений Trap, отправитель является авторизованным. Такой подход имеет две цели:

  • Своевременность сообщения определяется с учетом показания часов авторизованного сервера. Когда авторизованный сервер посылает сообщение (Trap, Response, Report), оно содержит текущее показание часов, так что неавторизованный получатель может синхронизовать свои часы. Когда неавторизованный сервер посылает сообщение (Get, GetNext, GetBulk, Set, Inform), он помещает туда текущую оценку показания часов места назначения, позволяя получателю оценить своевременность прихода сообщения.
  • Процесс локализации ключа, описанный ниже, устанавливает единственного принципала, который может владеть ключом. Ключи могут храниться только в авторизованном сервере, исключая хранение нескольких копий ключа в разных местах.

Когда исходящее сообщение передается процессором сообщений в USM, USM заполняет поля параметров безопасности в заголовке сообщения. Когда входное сообщение передается обработчиком сообщений в USM, обрабатываются значения параметров безопасности, содержащихся в заголовке сообщения. В параметрах безопасности содержатся:

  • msgAuthoritativeEngeneID - snmpEngeneID авторизованного сервера, участвующего в обмене. Таким образом, это значение идентификатора отправителя для Trap, Response или Report или адресата для Get, GetNext, GetBulk, Set или Inform.
  • msgAuthoritativeEngeneBoots - snmpEngeneBoots авторизованного сервера, участвующего в обмене. Объект snmpEngeneBoots является целым в диапазоне 0 - (2 31 -1). Этот код характеризует число раз, которое SNMP-сервер был перезагружен с момента конфигурирования.
  • msgAuthoritativeEngeneTime - nmpEngeneTime авторизованного сервера, участвующего в обмене. Значение этого кода лежит в диапазоне 0 - (2 31 -1). Этот код характеризует число секунд, которое прошло с момента последней перезагрузки. Каждый авторизованный сервер должен инкрементировать этот код один раз в секунду.
  • msgUserName - идентификатор пользователя от имени которого послано сообщение.
  • msgAuthenticationParameters - нуль, если при обмене не используется аутентификация. В противном случае - это аутентификационный параметр.
  • msgPrivacyParameters - нуль - если не требуется соблюдения конфимденциальности. В противном случае - это параметр безопасности. В действующей модели USM используется алгоритм шифрования DES.

Механизм аутентификации в SNMPv3 предполагает, что полученное сообщение действительно послано принципалом, идентификатор которого содержится в заголовке сообщения, и он не был модифицирован по дороге. Для реализации аутентификации каждый из принципалов, участвующих в обмене должен иметь секретный ключ аутентификации, общий для всех участников (определяется на фазе конфигурации системы). В посылаемое сообщение отправитель должен включить код, который является функцией содержимого сообщения и секретного ключа. Одним из принципов USM является проверка своевременности сообщения (смотри выше), что делает маловероятной атаку с использованием копий сообщения.

Система конфигурирования агентов позволяет обеспечить разные уровни доступа к MIB для различных SNMP-менеджеров. Это делается путем ограничения доступа некоторым агентам к определенным частям MIB, а также с помощью ограничения перечня допустимых операций для заданной части MIB. Такая схема управления доступом называется VACM (View-Based Access Control Model). В процессе управления доступом анализируется контекст (vacmContextTable), а также специализированные таблицы vacmSecurityToGroupTable, vacmTreeFamilyTable и vacmAccessTable.

SNMP-протокол служит примером системы управления, где для достижения нужного результата выдается не команда, а осуществляется обмен информацией, решение же принимается "на месте" в соответствии с полученными данными. Внедрены подсистемы аутентификации, информационной безопасности и управления доступом.

Таблица 4.4.13.6. RFC-документы по протоколу SNMP

Snmp client:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    Erlang snmp client - Досрочно завершим!

    Erlang Snmp Client

    Вот понадобилось опрашивать некоторые железные switch через snmp из erlang. Первая попытка понять что для этого нужна (наскоком, по Буденновски) – не удалась. На erlang.org полно документации как писать и управлять snmp сервера, но вот информация по клиентам – разбросана по крупицам.

    Так что пришлось собраться и создать картину у себя в голове, как должен выглядить snmp клиент.

    Общая картина

    Общая идея такая. Нет одной такой командочки типа snmpwalk. Мы вынуждены строить целую систему для того чтобы опросить железку.

    Есть snmp manager, мы его должны настроить и запустить, даже если у нас только клиент. Этот snmp manager содержит список snmp user. Я сначала думал что snmp user – это что-то типа community, оказалось – нет. Snmp user в erlang – это такой модуль. который содержит просто набор callback для приема ответов от устройств.

    Manager должен либо определять этого user-а в свой конфигурации, либо зарегистрировать его с помощью snmpm:register_user(имя, модуль).

    Дальше нам нужны agents. То есть manager каждому такому user назначает (в конфиге, либо с помощью snmpm:register_agent ) набор агентов которых опрашивать. Вот эти агенты как раз и содержат реквизиты опрашиваемых железок. Там, IP, community, port, версию протокола и т.д.

    Когда все это настроено, можно посылать из manager-а запрос. Например с помощью snmpm:ag(). Manager поищет в настройках который это агент(по адресу). Пошлет асинхронный запрос на железку, а когда придет ответ, Manager по привязанным user/agent, сообразит на которого user (ну грубо говоря в какой модуль) его переслать.

    В данном случает придет ответ на handle_pdu(Addr, Port, ReqId, SnmpResponse, UserData) в том user-е к которому привязан агент, куда посылался запрос.

    В следующих постах приведу примеры кода.

    Posted by Alexey Kishkin Mar 11 th. 2008

    Comments Recent Posts Google+

    SNMP - Простой протокол управления сетью

    Простой протокол управления сетью Несмотря на всю критику, SNMP остается сегодня наиболее широко реализованным протоколом управления сетью.

    Типичная сеть состоит из множества устройств различных производителей. Управлять такой сетью возможно только при наличии стандартного, не зависящего от производителя протокола управления. Самым популярным стандартным протоколом управления в современных сетях является простой протокол управления сетью (Simple Network Manage-ment Protocol, SNMP). Широкое распространение он получил в силу своей гибкости и расширяемости — SNMP позволяет описывать объекты для самых разных устройств. Ниже мы рассмотрим основные компоненты SNMP с указанием отличий первой версии протокола от второй.

    МОДЕЛЬ SNMP

    Модель SNMP состоит из четырех компонентов:

    • управляемых узлов;
    • станций управления (менеджеров);
    • управляющей информации;
    • протокола управления.


    Рисунок 1. Структура базы управляющей информации. Как и многие другие иерархические пространства имен, MIB начинается с безымянного корневого узла. В этом дереве узел MIB-2 уникальным образом идентифицируется с помощью идентификатора объекта 1.3.6.1.2.1.

    Управляемыми узлами могут быть компьютеры, маршрутизаторы, коммутаторы, принтеры или любые другие устройства, способные сообщать информацию о своем состоянии. Чтобы им можно было управлять с помощью SNMP, узел должен выполнять управляющий процесс SNMP, иными словами, иметь агента SNMP. Каждый агент ведет собственную локальную базу данных о состоянии устройства и истории событий.

    Управление сетью осуществляется со станций управления, которые представляют собой компьютеры общего назначения со специальным программным обеспечением для управления. Станции управления выполняют один или более процессов, взаимодействующих с агентами по сети. При такой схеме вся сложность (и вся интеллектуальность) сосредоточена на станциях управления, чтобы агенты были как можно более просты и чтобы они потребляли как можно меньшие ресурсы устройств, на которых выполняются.

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

    Станции управления взаимодействуют с агентами с помощью протокола SNMP. Он позволяет станции запрашивать значения локальных переменных агента и при необходимости изменять их.

    Однако иногда в сети могут происходить нежелательные события. Управляемые узлы могут сломаться, линии связи — выйти из строя и т. п. Как только агент замечает какое-либо значительное событие, он немедленно сообщает о нем всем станциям из своего конфигурационного списка. Это сообщение называется прерыванием SNMP. Агент лишь сообщает о событии, а все подробности станция управления должна выяснять самостоятельно. Из-за ненадежности коммуникаций между станцией и агентами (получение сообщений не подтверждается) каждая станция периодически проводит опрос управляемых узлов для выявления необычных событий. Такая модель опроса через длительные интервалы времени с немедленным опросом при получении прерывания называется инициируемым прерываниями опросом.

    СТРУКТУРА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ

    Структура управляющей информации (Structure of Management Information, SMI) определяет допустимые в базе управляющей информации типы данных и способы их представления. Кроме того, она определяет иерархическую структуру имен, чтобы управляемые объекты имели уникальные однозначные имена. SMI представляет своего рода надподмножество ASN.1 — она использует часть типов данных этого стандарта и вводит несколько своих типов данных. (АSN — абстрактное описание синтаксиса — представляет собой стандартный язык описания объектов, принятый в OSI. Как и многие другие протоколы OSI, он сложен, громоздок и неэффективен.)

    Для того чтобы агенты и менеджеры могли управлять объектами в сети со множеством устройств и протоколов разных поставщиков, объекты должны быть описаны, а также стандартным образом закодированы для передачи по сети. Термин "объекты" относится к переменным, описывающим состояние устройства. Он несколько сбивает с толку, так как это далеко не те же объекты, что и в объектно-ориентированных системах, в частности они имеют состояния, но не имеют методов (помимо чтения и записи значений объектов). Однако этот термин используется в официальных стандартах.

    Объекты базы управляющей информации обычно имеют шесть атрибутов. Как правило, это имя, например ifInErrors или tcpAttemptFails; идентификатор объекта в точечно-десятичной нотации вида 1.3.6.1.2.1.2.2.1.1.4; поле синтаксиса для выбора одного из нескольких возможных типов данных — Integer, IPAddress или Counter; поле метода доступа — "недоступен", "только чтение", "чтение—запись" и "только запись"; поле статуса — "обязательный", "необязательный" или "вышедший из употребления", а также текстовое описание объекта.

    SMI задает правила описания объектов. Все эти абстрактные правила и зарезервированные слова позволяют получить машиночитаемые спецификации, понятные человеку. Объекты MIB имеют статичную природу. Они компилируются из текстов файлов с описанием в двоичную форму, которую агенты и управляющие процессы и загружают. Используя SMI, производитель может написать собственное определение объекта управления (например, PacketsContainingWordSpam), пропустить текст через стандартный компилятор MIB и создать таким образом исполнимый код. Этот код можно затем установить на агенты с надлежащим аппаратным и программным обеспечением для подсчета количества содержащих слово spam пакетов.

    БАЗА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ

    Множество объектов, которыми управляет SNMP, составляет базу управляющей информации (Management Information Base, MIB). Для удобства эти объекты объединены в десять групп, каждая из которых представляет собой дочерний для mib-2 узел в дереве имен объектов (см. Рисунок 1). Изначально база управляющей информации содержала восемь групп. Спецификация MIB-2 добавила еще две группы и исключила одну прежнюю. Производители могут определять собственные объекты. Информация по всем десяти группам сведена в Таблицу 1.

    ТАБЛИЦА 1 — Группы объектов в Internet MIB-2

    Статистика о трафике SNMP

    Группа System позволяет определить, как называется устройство, кем оно произведено, какое программное и аппаратное обеспечение оно содержит, где находится и какие функции выполняет. Кроме того, она предоставляет информацию о том, когда последний раз производилась загрузка и каковы имя и координаты ответственного лица. Зная эту информацию, администратор из центрального офиса может, например, без труда установить конфигурацию устройства в удаленном офисе.

    Группа Interface служит для сбора статистики о работе сетевых адаптеров, в том числе о количестве переданных и полученных пакетов и байтов, о числе широковещательных пакетов и текущем размере выходной очереди.

    Присутствовавшая в MIB-1 группа АТ предоставляла данные о соответствии адресов (например, MAC- и IP-адресов). В SNMPv2 эта информация была перемещена в базы управляющей информации для конкретных протоколов.

    Группа IP описывает трафик через узел. Она изобилует счетчиками для подсчета числа отброшенных по каждой из причин кадров (например, кадр был отброшен, потому что его адресат неизвестен). Кроме того, она позволяет получить данные о фрагментации и сборке дейтаграмм. Как нетрудно понять, эта группа особенно полезна для получения статистики о работе маршрутизатора.

    Группа ICMP собирает данные о сообщениях об ошибках в IP. Она имеет счетчики для подсчета количества зафиксированных сообщений каждого возможного типа.

    Группа TCP служит для учета числа открытых соединений, количества переданных и полученных сегментов и различного рода ошибок.

    Группа UDP позволяет фиксировать число переданных и полученных дейтаграмм, а также количество дейтаграмм, потерянных из-за того, что порт неизвестен, или по другим причинам.

    Группа EGP используется маршрутизаторами, поддерживающими Exterior Gate-way Protocol. Она позволяет подсчитывать число полученных из внешней сети кадров, а также сколько из них было передано правильно, а сколько отброшено и т. п.

    Группа Transmission служит родительским узлом для специфичных баз управляющей информации. Например, сюда может быть помещена группа для сбора статистики об Ethernet. Цель включения пустой группы в MIB-2 состоит исключительно в резервировании идентификатора для подобных целей.

    Последняя группа — группа SNMP — предназначена для сбора статистики о функционировании самого протокола SNMP: сколько сообщений было послано, что это за сообщения и т.п.

    ПРОТОКОЛ SNMP

    Собственно SNMP представляет собой протокол по типу запрос—ответ, которыми сетевые станции управления и агенты обмениваются между собой. Первая версия протокола SNMP предусматривает всего пять различных сообщений. Три из них может посылать менеджер агенту, а два других — агент менеджеру.

    Если в сети ничего необычного не происходит, то SNMP используется менеджером для отправки агенту запроса с просьбой передать запрошенную информацию или с приказом изменить свое состояние указанным образом. Агент посылает в ответ требуемую информацию или подтверждает изменение своего состояния. Однако агент может передать сообщение об ошибке, например "нет такой переменной". В чрезвычайных же обстоятельствах, в частности при превышении заданного порога, агент отправляет менеджеру прерывание. Данные передаются с использованием синтаксиса ASN.1.

    Менеджер агенту может послать следующие три сообщения: GetRequest, GetNextRequest и SetRequest. Первые два служат для запроса у агента значений конкретных переменных. Первое из них содержит имя переменной в явном виде. Второе запрашивает значение следующей переменной в алфавитном порядке. Третье позволяет менеджеру изменять значения переменных, если определение объекта это позволяет.

    Агент может отправлять два различных сообщения: одно из них — GetResponse — служит для ответа (и подтверждения) на запрос от менеджера, а второе — Trap — посылается при обнаружении агентом предопределенного чрезвычайного события.

    Протоколом SNMPv2 вводится еще два типа сообщений. GetBulkRequest позволяет запросить целый массив переменных, например таблицу, а InformRequest — одному менеджеру сообщить другому, какими переменными он управляет.

    Все типы сообщений сведены в Таблице 2.

    ТАБЛИЦА 2 — Типы запросов SNMPv2

    Сообщение о прерывании от агента

    НИЖЕЛЕЖАЩИЕ ТРАНСПОРТНЫЕ ПРОТОКОЛЫ

    SNMP предназначался в первую очередь для управления сетями на базе протоколов Internet. Как протокол прикладного уровня он может, однако, использовать в качестве транспортного любой другой протокол, помимо UDP и IP. Например, он может выполняться поверх IPX, отображаться напрямую в кадры Ethernet, инкапсулироваться в ячейки ATM и т. п.

    Протокол SNMP разрабатывался в расчете на то, что обмен сообщениями между агентами и менеджерами будет происходить без установления соединения. В результате SNMP не предоставляет гарантии, что сообщения будут доставлены по назначению. Однако на практике большинство сообщений достигает адресата, а те, что теряются по пути, могут быть переданы повторно. Исходя из этого — и, естественно, ориентации SNMP на протоколы Internet, основным транспортом для SNMP является UDP.

    Благодаря своей простоте и транспорту без установления соединения SNMP оказывается весьма эффективным протоколом. И агенты, и менеджеры могут работать независимо друг от друга. Таким образом, менеджер будет продолжать работать, даже если удаленный агент окажется недоступен. После возобновления функционирования агент отправит менеджеру прерывание, дабы известить его о своей работоспособности.

    Обмен сообщениями при использовании в качестве транспорта протокола UDP осуществляется следующим образом. Агент следит за поступлением дейтаграмм на порт 161. Ответы посылаются запрашивающей сетевой станции управления на динамически назначаемый порт, однако многие агенты используют тот же номер порта — 161. Асинхронные прерывания станция управления принимает на порт 162.

    Максимальная допустимая длина сообщений SNMP ограничивается мак-симальным размером сообщения UDP, т. е. 65 507 байт. Однако спецификация SNMP предусматривает, что все агенты и менеджеры должны принимать пакеты лишь длиной до 484 байт, поэтому некоторые из них могут не уметь обрабатывать пакеты длиной свыше 484 байт.

    UDP более подходит для транспорта SNMP, нежели TCP, в частности, когда сеть сталкивается с проблемами и пакеты передаются каждый раз по новым маршрутам, т. е. когда управление наиболее необходимо. Кроме того, он предъявляет меньшие требования к сетевым ресурсам, нежели TCP, т. е. накладные расходы на управление оказываются меньше. Однако в результате задача обнаружения потерянных и ошибочных пакетов возлагается непосредственно на менеджеров и агентов.

    ЗАЩИТА В SNMP

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

    В SNMPv1 простейшая идентификация отправителя осуществляется посредством включения в сообщения имени группы (community name), причем имя передается открытым текстом. После проверки имени группы агент или менеджер проверяет наличие у отправителя с данным адресом прав на выполнение запрошенной операции. Таким образом, проверка прав осуществляется на основании имени группы и адреса отправителя.

    В SNMPv2 сделана попытка укрепить защиту SNMP за счет использования современных криптографических методов, в частности DES. Однако это еще более усложнило протокол. Кроме того, в такой реализации SNMPv2 оказался обратно несовместим с SNMPv1.

    ЛОЖКА ДЕГТЯ?

    Несмотря на свое название, SNMP оказался далеко не простым для реализации протоколом ввиду сложности правил кодирования информации. Кроме того, SNMP мог бы быть более эффективным, чем он есть. В частности, его сообщения содержат зачастую ненужную информацию, например номер версии SNMP. Из-за принятого в SNMP способа описания переменных сообщения содержат чрезмерно большие дескрипторы данных. Все это ведет к раздуванию объема сообщений. Изначально SNMP предназначался для относительно простых сетей, так что станции управления не могли обмениваться информацией друг с другом. Наконец, самым существенным недостатком SNMP была (и остается) слабая защита. Многие из этих недостатков — но не все — исправлены во второй версии SNMP (SNMPv2).

    Однако SNMP продолжает совершенствоваться, и уже готовится третья версия этого протокола.

    Дмитрий Ганьжа — ответственный редактор LAN. С ним можно связаться по адресу: diga@lanmag.ru.

    With any suggestions or questions please feel free to contact us

    Конфигурирование рабочих станций-клиентов для Desktop SNMP

    Конфигурирование рабочих станций-клиентов для Desktop SNMP Обзор

    В этой главе поясняется, как использовать на рабочих станциях-клиентах сервис Desktop SNMP и модифицировать файл NET.CFG с целью реализации дополнительных опций SNMP.

    Эта глава адресована главным образом сетевым администраторам, которые работают с системами управления сетью, базирующимися на SNMP.

    Введение

    Simple Network Management Protocol (SNMP) - это протокол, представляющий собой промышленный стандарт, определяющий формат для сбора данных сетевого управления.

    При работающем сервисе Novell ® Desktop SNMP рабочие станции-клиенты NetWare могут направлять информацию о состоянии в программу управления SNMP, работающую в сети IPX TM или TCP/IP.

    Сервис Desktop SNMP может обслуживаться программным обеспечением Novell NetWare Managenent System TM (NMS), другими консолями управления промышленного стандарта SNMP или системами управления сторонних фирм.

    Поддержка Desktop SNMP клиентом NetWare должна быть установлена на каждой рабочей станции-клиенте, которой Вы будете управлять с помощью системы управления, основанной на SNMP.

    Инсталляция консоли управления SNMP

    Поставляемый с клиентом NetWare для DOS и MS Windows сервис Desktop SNMP поддерживает программное обеспечение Novell NetWare Management System (NMS), другие консоли управления промышленного стандарта SNMP и системы управления сторонних фирм.

    Для получения дополнительной информации о процессе инсталляции и настройке смотрите документацию, поставляемую с этими системами управления.

    Инсталляция программного обеспечения Desktop SNMP

    Программное обеспечение Desktop SNMP состоит из набора файлов, поддерживающих Simple Network Management Protocol (SNMP) с помощью технологии NetWare Virtual Loadable Module TM (VLM).

    Также обеспечивается поддержка транспортных протоколов Internet Packet Exchange TM (IPX) и User Datagram Protocol (UDP).
    • Desktop SNMP и файлы поддержки Management Information Base (MIB).
      Программы-VLM TM Desktop SNMP позволяют системам удаленного управления сетью наблюдать за протокольными стеками IPX или UDP/IP, работающими на рабочих станциях-клиентах.
      Desktop SNMP также позволяет удаленным и локальным рабочим станциям-клиентам SNMP обращаться к Management Information Base (MIB) для управления ресурсами рабочей станции.
      Desktop SNMP поддерживает следующие группы MIB-II:
      • Системные группы и группы SNMP.
      • Группы интерфейсов.
      • Группы TCP/IP.

      На каждой рабочей станции в каталоге клиента NetWare должны находиться следующие файлы: Чтобы распаковать файл, введите Например, чтобы распаковать файл WSSNMP.VLM, введите
    • Повторяйте действие 1 до тех пор, пока файлы Desktop SNMP и другие файлы клиента NetWare не окажутся в каталоге клиента NetWare.
    • Модификация системных файлов DOS и файлов конфигурации клиента NetWare

      Для модификации системных файлов DOS и файлов конфигурации клиента NetWare требуется редактирование файлов CONFIG.SYS, STARTNET.BAT и NET.CFG с помощью текстового (ASCII) редактора.

      Модификация файла CONFIG.SYS

      Модифицируйте файл CONFIG.SYS с помощью текстового (ASCII) редактора, чтобы установить для программного обеспечения NetWare DOS Requester TM значение переменной LASTDRIVE в Z.

      Процедура
      1. Откройте файл CONFIG.SYS с помощью текстового редактора.
      Например, для редактирования файла CONFIG.SYS в корневом каталоге с помощью системного редактора Novell DOS TM 7 введите
    • Установите значение переменной LASTDRIVE в Z, добавив в файл следующую строку:
    • Сохраните выполненные изменения и выйдите из редактора.
    • Модификация файла STARTNET.BAT Для загрузки программного обеспечения Desktop SNMP на рабочей станции-клиенте необходимо с помощью текстового редактора сделать следующие изменения в файле STARTNET.BAT.
      • Изменить файл STARTNET.BAT для загрузки одного из файлов STPIPX.COM или STPUDP.COM.
      • Изменить файл STARTNET.BAT для загрузки файла HRMIB.EXE.

      IMPORTANT: Для поддержки транспортных модулей в Вашей системе должен быть инсталлирован либо протокол IPX, либо UDP/IP. На одной рабочей станции-клиенте можно использовать оба типа транспортных протоколов.

    По умолчанию после инсталляции программного обеспечения клиента NetWare сервис Desktop SNMP не включен. Для его включения выполните следующую процедуру.

    Процедура
    1. Модифицируйте файл C:\NWCLIENT\STARTNET.BAT для загрузки транспортных модулей Desktop SNMP.
    Добавьте следующие строки в файл STARTNET.BAT после строки загрузки VLM.EXE:
    • Если используется транспортный протокол IPX, добавьте:
    • Если используется транспортный протокол UDP/IP, добавьте:

    NOTE: Если Вы используете как протокол IPX, так и UDP/IP, можете добавить обе команды.

  • Модифицируйте файл C:\NWCLIENT\STARTNET.BAT для загрузки файла MIB.
    Добавьте следующую команду в файл STARTNET.BAT после строки загрузки VLM.EXE:
  • Убедитесь, что файл HRMIB.INI находится в том же каталоге, что и файл HRMIB.EXE.

    NOTE: Если Вы работаете с LAN Workplace, убедитесь, что Вы не загрузили файл SNMP.EXE, поставляемый вместе с LAN Workplace.

    Программа инсталляции LAN Workplace создает файл LANWP.BAT, который загружает программное обеспечение LAN Workplace. Проверьте его на наличие строки SNMP. Она должна находиться сразу за строкой TCPIP.

    Если Вы обнаружили строку SNMP. удалите ее или пометьте символом комментария.

  • Для установки часового пояса для Вашей местности добавьте в файл STARTNET.BAT команду DOS SET: Правильное значение переменной смотрите в руководстве по DOS.

    Если в среде Вашей рабочей станции не установлен часовой пояс, файл ловушки SNMP может выдать неверное время.

  • Сохраните изменения и выйдите из редактора.
  • Модификация файла NET.CFG Для загрузки программного обеспечения Desktop SNMP Вы должны на каждой рабочей станции-клиенте внести изменения в файл NET.CFG.
    • Добавьте необходимые строки в файл NET.CFG для загрузки и поддержки программного обеспечения Desktop SNMP.
    • Установите адрес "TRAP TARGET" консолей NetWare Services Management (NSM) или других систем управления, основанных на SNMP.

    По умолчанию после инсталляции программного обеспечения клиента NetWare сервис Desktop SNMP не включен. Для его включения выполните следующую процедуру.

    Процедура
    1. Убедитесь, что файлы Desktop SNMP скопированы в каталог клиента NetWare (по умолчанию C:\NWCLIENT).
    2. Модифицируйте файл NET.CFG для загрузки файлов .VLM Desktop SNMP.
    Для загрузки файла .VLM Desktop SNMP модифицируйте файл NET.CFG на Вашей рабочей станции-клиенте одним из следующих способов:
    • Для загрузки программного обеспечения Desktop SNMP и запросчика NetWare для DOS добавьте в файл NET.CFG в указанном порядке следующие строки:
    • Для загрузки только программного обеспечения Desktop SNMP без файлов запросчика NetWare для DOS добавьте в файл NET.CFG в указанном порядке следующие строки:

    Подробнее о том, как конфигурировать Desktop SNMP, смотрите в следующих подразделах главы 2 "Секция NetWare DOS Requester" руководства NetWare Client для DOS и Windows. Технический справочник.

    После выполнения начальной конфигурации агента Desktop SNMP Вы можете далее изменять секцию Desktop SNMP в файле NET.CFG. добиваясь соответствия конкретным требованиям сети.

    Пример файла NET.CFG для Desktop SNMP

    Следующий пример показывает файл NET.CFG для Desktop SNMP:

    Конфигурирование файла HRMIB.INI

    Host Resources MIB не возвращает информацию об устройствах, подключенных к рабочим станциям (например, принтерах, модемах и накопителях на магнитной ленте).

    Если консоль управления сетью предназначается для детального просмотра таких устройств, Вы должны перечислить их в файле HRMIB.INI. Для краткого описания каждого из устройств используйте текстовый (ASCII) редактор.

    Файл HRMIB.INI располагается в каталоге клиента NetWare (по умолчанию C:\NWCLIENT).

    Пример файла конфигурации (HRMIB.INI) для HRMIB.EXE

    В следующем примере приведено содержание файла конфигурации HRMIB.INI для файла HRMIB.EXE:

    Загрузка программного обеспечения Desktop SNMP

    Для загрузки программного обеспечения Desktop SNMP нужно выполнить следующую процедуру.

    Процедура
    1. Убедитесь, что система управления SNMP настроена и запущена.
      Подробнее об этом смотрите в подразделе "Инсталляция консоли управления SNMP".
    2. Убедитесь, что на каждой рабочей станции-клиенте, которой Вы хотите управлять с консоли управления, инсталлировано программное обеспечение Desktop SNMP.
      Подробнее об этом смотрите в подразделе "Инсталляция программного обеспечения Desktop SNMP".
    3. Убедитесь, что в файлах конфигурации рабочей станции-клиента выполнены необходимые изменения.
      Подробнее об этом смотрите в подразделе "Модификация системных файлов DOS и файлов конфигурации клиента NetWare".
    4. Убедитесь, что файл HRMIB.INI правильно сконфигурирован для каждой рабочей станции-клиента с включением всех устройств, которыми Вы хотите управлять.
      Подробнее об этом смотрите в подразделе "Конфигурирование файла HRMIB.INI".
    5. Перезагрузите каждую рабочую станцию-клиент.
      Менеджер VLM загрузит файлы .VLM для Desktop SNMP вместе с другими файлами .VLM, сконфигурированными для загрузки на рабочей станции-клиенте.
    Выгрузка программного обеспечения Desktop SNMP
    1. (При необходимости) Если загружена поддержка UDP/IP, введите следующую строку для выгрузки STPUDP:
    2. (По необходимости) Если загружена поддержка IPX, введите следующую строку для выгрузки STPIPX:
    3. Для выгрузки всех VLM введите:

    Команда VLM /U выгружает все файлы .VLM, а не только файлы Desktop SNMP.

    NOTE: Выгружайте модули всегда в порядке, обратном порядку загрузки. Выгрузить модули в другом порядке невозможно. Конфигурирование рабочей станции-клиента для улучшения производительности

    Для улучшения производительности программного обеспечения Desktop SNMP Вы можете загружать на рабочей станции-клиенте один или несколько файлов .VLM в основную память.

    Для загрузки в основную память всех файлов .VLM при запуске менеджера LVM используйте переключатель VLM /MC. Подробнее об этом смотрите в главе 2 "Секция NetWare DOS Requester" руководства NetWare Client для DOS и Windows* Технический справочник.

    Для загрузки файлов Desktop SNMP в основную память добавьте строки следующего формата в файл NET.CFG:

    Например, для загрузки в основную память файлов Desktop SNMP WSASN1.VLM и WSREG.VLM добавьте в файл NET.CFG следующие строки:

    Дополнительная информация