Администрирование_в_информационных_системах_Беленькая_М_Н_

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

Рассмотрим набор операций (запросов), инициируемых менеджером.

M-CREATE — запрос, который требует от агента создать новый экземпляр объекта определенного класса или новый атрибут внутри экземпляра объекта. Необходимость в данной услуге и соответствующей операции возникает при подключении к сети нового устройства. С помощью данной услуги можно сообщить другим приложениям того же уровня модели OSI о появлении в сети нового объекта. В ответ на запрос M-CREATE может быть создан только один объект управления. Здесь могут использоваться различные методы создания имени нового управляемого объекта и присвоения значений атрибутов. Новый управляемый объект может быть создан как копия существующего объекта, но с другим именем.

M-DELETE — запрос, который требует от агента удалить некоторый экземпляр объекта определенного класса или атрибут внутри экземпляра объекта. Запрос M-DELETE по характеру действия противоположен операции M-CREATE. Обязательными параметрами в запросе являются последовательный номер запроса и обозначение управляемого объекта. Если удаляется множество объектов, то подтверждения об удалении генерируются отдельно для каждого объекта.

M-GET — запрос агенту о возвращении значения некоторого атрибута определенного экземпляра объекта. Используется, чтобы найти, восстановить или собрать информацию для управления объектами. Это услуга с подтверждением выполнения, она дает возможность данной открытой системе восстановить или найти значение атрибута/атрибутов одного или множества управляемых объектов, находящихся в другой открытой системе. Обязательными параметрами запроса являются последовательный номер запроса и наименование управляемого объекта.

M-CANCEL-GET — используется для отмены запроса M- GET. Отмена M-GET может быть необходима, если для запроса было выбрано слишком много объектов, и приложение управления не может обработать ответы от многих объектов. Также отмену M-GET можно использовать в случае, когда запрос выполняется слишком долго. Услуга M-CANCEL-GET предоставляется с выдачей подтверждения. Если операция M- GET была завершена прежде, чем получен запрос M-CANCEL- GET, то выдается сообщение об ошибке. Если отмена услуги произошла успешно, то для M-CANCEL-GET выдается положительное подтверждение, а для предыдущей услуги M-GET — сообщение об ошибке. При формировании M-CANCEL-GET обязательными параметрами являются последовательный номер данного запроса и последовательный номер запроса, который должен быть отменен.

M-SET — требует от агента изменить значения некоторого атрибута определенного экземпляра объекта. Эта услуга используется приложением управления, чтобы запросить изменение значения атрибута или атрибутов одного или нескольких управляемых объектов в другой открытой системе. Обязательными параметрами являются последовательный номер запроса услуги, обозначение объекта управления и оператор модификации, который описывает, как изменяются данные управляемого объекта.

Использование оператора модификации позволяет изменить значения атрибута объекта управления, добавить новое значение или удалить существующие значения для набора атрибутов.

M-ACTION — запрос, который требует от агента выполнить определенные действия над одним или несколькими экземплярами объектов.

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

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

Оказание услуги M-ACTION при выполнении действий на нескольких объектах аналогично действиям, определенным для M-SET. Руководство по выбору модели управления объектом между операцией SET для атрибутов и операцией ACTION для управления поведением приводится в Рек. ISO/IEC 10165-1 Management Information Model (информационная модель управления). Например, услуга M-ACTION используется, когда информация при запросе не входит в состав атрибутов объекта или когда требуется определить сложные операции типа «установить и протестировать».

M-EVENT REPORT — отправка уведомления агентом менеджеру.

Для реализации своих услуг служба CMISE должна использовать службы прикладного уровня стека OSI — ACSE, ROSE. Запросы M-GET, M-SET, M-ACTION и M-DELETE могут применяться к более чем одному объекту. Для этого стандарты CMIP/CMIS вводят такие понятия, как обзор (scoping), фильтрация (filtering) и синхронизация (synchronization).

Обзор. Запрос CMISE может использовать обзор, чтобы опросить одновременно несколько объектов.

Фильтрация заключается в применении булевого выражения к запросу менеджера. Запрос применяется только к тем объектам и их атрибутам, для которых данное булево выражение верно. Булевы выражения могут содержать операторы отношения =, m, l, <, > или определенные атрибуты. Возможно построение сложных фильтров на основе объединения нескольких фильтров в один составной.

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

12.1.2.Протокол SNMP (модель ONC)

Кконцу 1980-х гг. сеть Интернет стала достаточно большой

ипотребовала стандартов управления. Однако группа ISO OSI была далека от завершения работ над протоколом CMIP. Поэтому в 1987 году технической комиссией IETF было принято решение временно создать набор упрощенных стандартов управления в сети Интернет на основе наработок группы ISO OSI. Данные стандарты получили название SNMP (Simple Network Management Protocol — простой протокол управления сетью). В дальнейшем предполагалось переключиться на стандарты ISO по мере их готовности.

Таким образом, многие идеи и часть терминологии SNMP были взяты из стандартов ISO CMIP, а именно:

—концепция «менеджер-агент»;

—идея баз управляющей информации (Management Information Base — MIB);

—использование синтаксиса ASN.1.

Стандарты SNMP продолжали развиваться на протяжении 1990-х гг. Основным направлением развития было совершенствование вопросов безопасности. Были разработаны версии SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u и SNMPv3.

Рассмотрим основные концепции протокола SNMP, базы данных MIB и типы сообщений [8, 9].

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

В системах управления, построенных на основе протокола SNMP, стандартизируются следующие элементы:

—протокол взаимодействия агента и менеджера;

—язык описания моделей MIB и сообщений SNMP;

—несколько конкретных моделей MIB (MIB-I, MIB-II, RMON, RMON 2), имена объектов которых регистрируются в дереве стандартов ISO.

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

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

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

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

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

База данных MIB. В настоящее время существует несколько стандартов на базы данных управляющей информации для протокола SNMP. Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB [8, 9, 62]. Кроме этого существуют стандарты MIB для специальных устройств (например, MIB для концентраторов или MIB для модемов), а также частные MIB конкретных фирм-производителей оборудования.

Первоначальная спецификация MIB-I определяла только операции чтения значений переменных. Операции изменения или установки значений объекта являются частью спецификаций MIB-II.

Версия MIB-I, описанная в RFC 1156, определяет 114 объектов, которые подразделяются на 8 групп:

—System — общие данные об устройстве (например, идентификатор поставщика, время последней инициализации системы);

—Interfaces — параметры сетевых интерфейсов устройства (например, их число, типы, скорости обмена, максимальный размер пакета);

—Address Translation Table — описание соответствия между сетевыми и физическими адресами (например, по протоколу ARP);

—Internet Protocol — данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика об IP-пакетах);

—ICMP — данные, относящиеся к протоколу обмена управляющими сообщениями ICMP (Internet Control Message Protocol — межсетевой протокол управляющих сообщений);

—TCP — данные, относящиеся к протоколу TCP (Transmission Control Protocol — протокол управления передачей);

—UDP — данные, относящиеся к протоколу UDP (User Datagram Protocol — протокол пользовательских дейтаграмм), например, число переданных, принятых и ошибочных UPD-дейтаграмм;

—EGP — данные, относящиеся к протоколу обмена маршрутной информацией EGP (Exterior Gateway Protocol — протокол внешнего шлюза), например число сообщений, принятых с ошибками и без ошибок.

Вверсии MIB-II (RFC 1213), принятой в 1992 г., существенно расширен набор стандартных объектов (до 185), а число групп увеличилось до 10.

На рис. 12.1 приведен пример древовидной структуры базы объектов MIB-II. На нем показаны две из 10 возможных групп объектов — System (имена объектов начинаются с префикса Sys) и Interfaces (используется префикс if). Объект SysUpTime содержит значение продолжительности времени работы системы с момента последней перезагрузки, объект SysObjectID — идентификатор устройства (например, маршрутизатора).

Объект ifNumber определяет число сетевых интерфейсов устройства. Объект ifEntry является вершиной поддерева, опи-

Рис. 12.1. Стандартное дерево MIB-II (фрагмент)

сывающего один из конкретных интерфейсов устройства. Входящие в это поддерево объекты ifType и ifAdminStatus определяют соответственно тип и состояние одного из интерфейсов,

вданном случае интерфейса Ethernet.

Вчисло объектов, описывающих каждый конкретный интерфейс устройства, включены следующие:

—ifType — это объект, который указывает тип протокола, который поддерживает интерфейс; объект принимает значения всех стандартных протоколов канального уровня, например, rfc877-x25, ethernet-csmacd, iso88025Тoken Ring;

—ifMtu — максимальный размер пакета сетевого уровня, который можно послать через этот интерфейс;

—ifSpeed — пропускная способность интерфейса в Бит/с;

—ifPhysAddress — физический адрес порта; например, для Fast Ethernet — это МАС-адрес;

—ifAdminStatus — желаемый статус порта: up — готов передавать пакеты, down — не готов передавать пакеты, testing — находится в тестовом режиме;

—ifOperStatus — фактический текущий статус порта, имеет те же значения, что и ifAdminStatus;

—ifInOctets — общее число байтов (включая служебные байты), принятое данным портом с момента последней инициализации SNMP-агента;

—ifInUcastPkts — число пакетов — unicast, доставленных протоколу верхнего уровня;

—ifInNUcastPkts — число пакетов — broadcast или multicast, доставленных протоколу верхнего уровня;

—ifInDiscards — число пакетов, которые были приняты интерфейсом, оказались корректными, но не были доставлены протоколу верхнего уровня, скорее всего из-за переполнения буфера или по иной причине;

—ifInErrors — число принятых пакетов, которые не были переданы протоколу верхнего уровня из-за обнаруженных в них ошибок.

Кроме объектов, описывающих статистику по принятым пакетам, имеются аналогичные объекты, но относящиеся к переданным пакетам.

Как следует из описания объектов MIB-II, эта база данных не дает детальной статистики по характерным ошибкам фреймов Ethernet и не отражает изменение характеристик во времени, что часто интересует сетевого администратора. Эти ограничения были впоследствии сняты новым стандартом на MIB — RMON MIB, который специально ориентирован на сбор детальной статистики по технологии Ethernet. К тому же этот стандарт поддерживает такую важную функцию, как построение агентом зависимостей статистических характеристик от времени.

Для именования переменных базы MIB и однозначного определения их форматов используется дополнительная спецификация, называемая SMI (Structure of Management Information — структура управляющей информации).

При описании переменных MIB и форматов протокола SNMP спецификация SMI опирается на формальный язык ASN.1.

Имена переменных MIB могут быть записаны как в символьном формате, так и в числовом. Символьный формат используется для представления переменных в текстовых документах и на экране дисплея, а числовые имена — в сообщени-

Рис. 12.2. Пространство имен объектов ISO

ях протокола SNMP. Например, символьному имени SysDescr соответствует числовое имя 1, а более точно 1.3.6.1.2.1.1.1. Составное числовое имя объекта SNMP MIB соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO.

Разработчики протокола SNMP не стали использовать фиксацию численных параметров протокола в специальном RFC, называемом Assigned Numbers, где описываются, например, численные значения, которые может принимать поле Protocol пакета IP, и т. п. Вместо этого они зарегистрировали объекты баз MIB SNMP во всемирном дереве регистрации стандартов ISO, показанном на рис. 12.2.

Как и в любых сложных системах, пространство имен объектов ISO имеет иерархическую древовидную структуру, причем на рисунке 12.2 показана только верхняя часть дерева. От корня дерева отходят три ветви, соответствующие стандартам, контролируемым ISO, ITU и совместно ISO-ITU. В свою очередь, организация ISO создала ветвь для стандартов, создавае-

мых национальными и международными организациями (ветвь org). Стандарты Internet создавались под эгидой Министерства обороны США (Departament of Defence — DoD), поэтому стандарты MIB попали в поддерево dod-internet, а далее в группу стандартов управления сетью — ветвь mgmt. Объекты любых стандартов, создаваемых под эгидой ISO, однозначно идентифицируются составными символьными именами, начинающимися от корня этого дерева. В сообщениях протоколов символьные имена не используются, а применяются однозначно соответствующие им составные числовые имена. Каждая ветвь дерева имен объектов нумеруется в дереве целыми числами слева направо, начиная с единицы, Эти числа заменяют символьные имена. Поэтому полное символьное имя объекта MIB имеет вид: iso.org.dod.internet.mgmt.mib, a полное числовое имя — 1.3.6.1.2.1.

Группа объектов private (4) зарезервирована за стандартами, создаваемыми частными компаниями, например Cisco, Hewlett-Packard. Это же дерево регистрации используется для именования классов объектов CMIP и TMN.

Соответственно, каждая группа объектов MIB-I и MIB-II имеет кроме кратких символьных имен, приведенных выше, полные символьные имена и соответствующие им числовые имена. Например, краткое символьное имя группы System имеет полную форму iso.org.dod.internet.mgmt.mib.system, а ее соответствующее числовое имя — 1.3.6.1.2.1.1. Часть дерева имен ISO, включающая группы объектов MIB, показана на рис. 12.3.

Типы команд. Протокол SNMP — это протокол типа «запрос-ответ», т. е. на каждый запрос, поступивший от менеджера, агент должен передать ответ (рис. 12.4). Особенностью протокола является его простота, он включает в себя всего несколько команд:

—Get-Request — команда используется менеджером для получения от агента значения какого-либо объекта по его имени;

—GetNext-Request — команда используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов;

—Get-Response — с помощью этой команды агент передает менеджеру ответ на команды Get-Request или GetNextRequest;