Management Information Base

Материал из свободной русской энциклопедии «Традиция»
Перейти к навигации Перейти к поиску

MIB (Management Information Base) — база данных информации управления, используемая в процессе управления сетью в качестве модели управляемого объекта в архитектуре агент-менеджер. В частности используется протоколом SNMP.

Структура MIB[править | править код]

Существует несколько стандартов на базы данных управляющей информации для протокола SNMP. Основные — стандарты MIB-I и MIB-II, и версия базы данных для удаленного управления RMON MIB. Кроме этого существуют стандарты для специальных устройств 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.
  • TCP — данные протокола TCP (например, о TCP-соединениях).
  • UDP — данные протокола UDP (число переданных, принятых и ошибочных UDP-дейтаграмм).
  • EGP — данные протокола обмена маршрутной информацией Exterior Gateway Protocol (число принятых с ошибками и без ошибок сообщений).

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

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

  • ifType — тип протокола, который поддерживает интерфейс. Этот объект принимает значения всех стандартных протоколов канального уровня, например, rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRmg и т. д.
  • ifMtu — максимальный размер пакета сетевого уровня, который можно послать через этот интерфейс.
  • ifSpeed — пропускная способность интерфейса в битах в секунду (100 для Fast Ethernet).
  • ifPhysAddress — физический адрес порта, для Fast Ethernet им будет МАС-адрес.
  • ifAdminStatus — желаемый статус порта:
 up — готов передавать пакеты;
 down — не готов передавать пакеты;
 testing — находится в тестовом режиме.
  • ifOperStatus — фактический текущий статус порта, имеет те же значения, что и ifAdminStatus.
  • ifInOctets — общее количество байт, принятое данным портом, включая служебные, с момента последней инициализации SNMP-агента.
  • ifInUcastPkts — количество пакетов с индивидуальным адресом интерфейса, доставленных протоколу верхнего уровня.
  • ifInNUcastPkts — количество пакетов с широковещательным или мультивещательным адресом интерфейса, доставленных протоколу верхнего уровня.
  • ifInDiscards — количество пакетов, которые были приняты интерфейсом, оказались корректными, но не были доставлены протоколу верхнего уровня, скорее всего из-за переполнения буфера пакетов или же по иной причине.
  • ifInErrors — количество пришедших пакетов, которые не были переданы протоколу верхнего уровня из-за обнаружения в них ошибок.

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

Форматы и имена объектов SNMP MIB[править | править код]

Для именования переменных базы MIB и однозначного определения их форматов используется дополнительная спецификация, называемая SMI — Structure of Management Information. Например, спецификация SMI включает в качестве стандартного имя IpAddress и определяет его формат как строку из 4 байт. Другой пример — имя Counter, для которого определён формат в виде целого числа в диапазоне от 0 до 232-1.

При описании переменных MIB и форматов протокола SNMP спецификация SMI опирается на формальный язык ASN.1, принятый ISO в качестве нотации для описания терминов коммуникационных протоколов . Нотация ASN.1 служит для установления однозначного соответствия между терминами, взятыми из стандартов, предназначенных для человеческого использования, и теми данными, которые передаются в коммуникационных протоколах аппаратурой. Достигаемая однозначность очень важна для гетерогенной среды, характерной для корпоративных сетей. Так, вместо того чтобы указать, что некоторая переменная протокола представляет собой целое число, разработчик протокола, использующий нотацию ASN.1, должен точно определить формат и допустимый диапазон переменной. В результате документация на MIB, написанная с помощью нотации ASN.1, может точно и механически транслироваться в форму кодов, характерных для сообщений протоколов.

Нотация ASN.1 похожа на другие метаязыки, например нормальную Бэкусову форму, используемую при описании языков программирования, в частности Алгола. Нотация ASN.1 поддерживает базовый набор различных типов данных, таких как целое число, строка и т. п., а также позволяет конструировать из этих базовых типов составные данные — массивы, перечисления, структуры. Существуют правила трансляции структур данных, описанных на ASN.1, в структуры данных языков программирования, например C++. Соответственно, имеются трансляторы, выполняющие эту работу. Примеры описаний данных с помощью ASN.1 приведены ниже при описании протокольных блоков данных SNMP.

Нотация ASN.1 часто используется при описании многих стандартов OSI, в частности моделей управляемых объектов и структуры сообщений протокола СMIР.

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

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

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

Пространство имён объектов ISO имеет древовидную иерархическую структуру, (на рис. показана только его верхняя часть. От корня этого дерева отходят три ветви, соответствующие стандартам, контролируемым ISO, ITU и совместно ISO-ITU. В свою очередь, организация ISO создала ветвь для стандартов, создаваемых национальными и международными организациями (ветвь оrg). Стандарты Internet создавались под эгидой Министерства обороны США (Departament of Defence, DoD), поэтому стандарты MIB попали в поддерево dod-internet, а далее, естественно, в группу стандартов управления сетью — ветвь mgmt. Объекты любых стандартов, создаваемых под эгидой ISO, однозначно идентифицируются составными символьными именами, начинающимися от корня этого дерева. В сообщениях протоколов символьные имена не используются, а применяются однозначно соответствующие им составные числовые имена. Каждая ветвь дерева имён объектов нумеруется в дереве целыми числами слева направо, начиная с единицы, и эти числа и заменяют символьные имена. Поэтому полное символьное имя объекта MIB имеет вид: iso.org.dod.intemet.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. Часть дерева имен ISO, включающая группы объектов MIB, показана на рисунке.

Общий формат сообщения SNMP в нотации ASN.1 выглядит следующим образом:

Область данных может содержать 5 различных типов PDU, соответствующих пяти командам протокола SNMP:

Для каждого типа PDU имеется определение его формата. Например, формат блока GetRequest-PDU описан следующим образом:

GetRequest-PDU ::- [0]
             IMPLICIT SEQUENCE {
               request-id
                 RequestID,
               error-status    -- всегда 0
                 ErrorStatus,
               error-index     -- всегда 0
                 ErrorIndex,
               variable-bindings
                 VarBindList }

Далее стандарт SNMP определяет соответственно формат переменных блока GetRequest-PDU. Переменная Request ID — это 4-байтовое целое число (используется для установления соответствия ответов запросам), ErrorStatus и ErrorIndex — это однобайтовые целые, которые в запросе должны быть установлены в 0. VarBindList — это список числовых имён объектов, значениями которых интересуется менеджер. В нотации ASN.1 этот список состоит из пар «имя — значение». При запросе значение переменной должно быть установлено в nut 1.

Вот пример сообщения протокола SNMP, которое представляет собой запрос о значении объекта SysDescr (числовое имя 1.3.6.1.2.1.1.1).

Спецификация RMON MIB обеспечивает удалённое взаимодействие с базой MIB. База RMON MIB обладает улучшенным набором свойств для удалённого управления, так как содержит агрегированную информацию об устройстве, не требующую передачи по сети больших объёмов информации. Объекты RMON MIB включают дополнительные счётчики ошибок в пакетах, более гибкие средства анализа трендов и статистики, более мощные средства фильтрации для захвата и анализа отдельных пакетов, а также более сложные условия установления сигналов предупреждения. Агенты RMON MIB более интеллектуальны по сравнению с агентами MIB-I или MIB-II и выполняют значительную часть работы по обработке информации об устройстве, которую раньше выполняли менеджеры. Эти агенты могут располагаться внутри различных коммуникационных устройств, а также быть выполнены в виде отдельных программных модулей, работающих на универсальных персональных компьютерах и ноутбуках.

Объект RMON объединяет 10 групп следующих объектов:

  • Statistics — текущие накопленные статистические данные о характеристиках пакетов, количестве коллизий и т. п.
  • History — статистические данные, сохранённые через определённые промежутки времени для последующего анализа тенденций их изменений.
  • Alarms — пороговые значения статистических показателей, при превышении которых агент RMON посылает сообщение менеджеру.
  • Hosts — данные о хостах сети, в том числе и о их МАС-адресах.
  • HostTopN — таблица наиболее загруженных хостов сети.
  • Traffic Matrix — статистика интенсивности трафика между каждой парой хостов сети, упорядоченная в виде матрицы.
  • Filter — условия фильтрации пакетов.
  • Packet Capture — условия захвата пакетов.
  • Event — условия регистрации и генерации событий.

Данные группы пронумерованы в указанном порядке, поэтому, например, группа Hosts имеет числовое имя 1.3.6.1.2.1.16.4.

Десятую группу составляют специальные объекты протокола Token Ring. Всего стандарт RMON MIB определяет около 200 объектов в 10 группах, зафиксированных в двух документах — RFC 1271 для сетей Ethernet и RFC 1513 для сетей Token Ring.

Стандарт RMON MIВ не зависит от протокола сетевого уровня (в отличие от стандартов MIB-I и MIB-II, ориентированных на протоколы TCP/IP). Поэтому он удобен для гетерогенных сред, использующих различные протоколы сетевого уровня.

С помощью агента RMON, встроенного в повторитель или другое коммуникационное устройство, можно провести очень детальный анализ работы сегмента Ethernet или Fast Ethernet. Сначала можно получить данные о встречающихся в сегменте типах ошибок в кадрах, а затем целесообразно собрать с помощью группы History зависимости интенсивности этих ошибок от времени (в том числе и привязав их ко времени). После анализа временных зависимостей часто уже можно сделать некоторые предварительные выводы об источнике ошибочных кадров и на этом основании сформулировать более тонкие условия захвата кадров со специфическими признаками (задав условия в группе Filter), соответствующими выдвинутой версии. После этого можно провести ещё более детальный анализ за счёт изучения захваченных кадров, извлекая их из объектов группы Packet Capture.

Позже был принят стандарт RMON 2, который распространяет идеи интеллектуальной RMON MIB на протоколы верхних уровней, выполняя часть работы анализаторов протоколов.

Внешние Cсылки[править | править код]