Добавлен: 06.12.2023
Просмотров: 22
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации
Сибирский государственный университет телекоммуникаций и информатики
Кафедра ФТ
Реферат
По дисциплине «Управление сетями связи»
По теме «Принцип формирования базы данных MIB»
Выполнил: студент
Фролов С.Е.
гр. МО-96
Проверила: ст. преподаватель
Барабанщикова Е.А.
Новосибирск 2023
Содержание
Содержание 2
SNMP менеджер и SNMP агент 7
Введение
Management Information Base (MIB, база управляющей информации) - виртуальная база данных, используемая для управления объектами в сети связи. Наиболее часто это понятие связывают с Simple Network Management Protocol (SNMP), но также оно используется в более широком смысле - в контексте модели управления сети OSI/ISO. Хотя термин MIB предназначен для обозначения всей доступной информации об объекте, он также часто используется для обозначения конкретного подмножества, которое правильнее называть MIB-модулем.
1.MIB – Набор управляющей информации
MIB - это Management information base, то есть база набор управляющей информации. Каждый сетевой узел, имеющий на своем борту SNMP агента (читай - поддерживающий протокол SNMP) предоставляет свой набор данных, тот, который в него «вложили» программисты \ разработчики при проектировании железки \ программы. То есть в каждом сетевом устройстве с поддержкой SNMP имеется своя база MIB со строго обозначенным набором переменных. Каждая база MIB имеет древовидную структуру, каждый объект в которой характеризуется уникальным идентификатором объекта (Object Identifier, OID).
Каждый сетевой узел, имеющий на своем борту SNMP агента (читай – поддерживающий протокол SNMP) предоставляет свой набор данных, тот, который в него «вложили» программисты\разработчики при проектировании железки\программы. То есть в каждом сетевом устройстве с поддержкой SNMP имеется своя база MIB со строго обозначенным набором переменных. Каждая база MIB имеет древовидную структуру, каждый объект в которой характеризуется уникальным идентификатором объекта (Object Identifier, OID).
Каждая ветка MIB-иерархии оканчивается некоторой переменной (так же имеющей свой OID), содержащей в себе определенное значение, которое записывается в переменную SNMP агентом, работающем на хосте. Данное значение неким образом характеризует данный хост (например, содержит информацию об аптайме, загрузке сетевого интерфейса и мн.др. параметры).
Имеется некая единая общая структура дерева MIB, а так же, имеются единые стандарты и принципы дальнейшего формирования данного дерева, его переменных, др. параметров, за эти правила отвечает некий разработанный стандарт под названием Структура Информации Управления (SMI, Structure of Management Information). Так же, имеется некий стандарт, называемый абстрактный синтаксис нотаций - ASN.1. Который тоже участвует в описании протокола SNMP и базы MIB. А еще имеется базовые правила кодирования BER (Basic Encoding Rules), определяющие кодирование сущностей, применяемых в SNMP.
Кроме того, существует всемирное дерево регистрации стандартов ISO, содержащее базовую структура дерева MIB (точнее этих структур существует несколько, они формировались вместе с совершенствованием версий SNMP). Составное числовое имя объекта SNMP MIB соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO. За данную древовидную структуру отвечает и контролирует организация IANA (и некоторые другие)
Каждая ветка MIB-иерархии оканчивается некоторой переменной (так же имеющей свой OID), содержащей в себе определенное значение, которое записывается в переменную SNMP агентом, работающем на хосте. Данное значение неким образом характеризует данный хост (например, содержит информацию об аптайме, загрузке сетевого интерфейса и мн.др. параметры).
Имеется некая единая общая структура дерева MIB, а так же, имеются единые стандарты и принципы дальнейшего формирования данного дерева, его переменных, др. параметров, за эти правила отвечает некий разработанный стандарт под названием Структура Информации Управления (SMI, Structure of Management Information). Так же, имеется некий стандарт, называемый абстрактный синтаксис нотаций - ASN.1, который тоже участвует в описании протокола SNMP и базы MIB. А еще имеется базовые правила кодирования BER (Basic Encoding Rules), определяющие кодирование сущностей, применяемых в SNMP.
Кроме того, существует всемирное дерево регистрации стандартов ISO, содержащее базовую структуру дерева MIB (точнее этих структур существует несколько, они формировались вместе с совершенствованием версий SNMP). Составное числовое имя объекта SNMP MIB соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO. За данную древовидную структуру отвечает и контролирует организация IANA (и некоторые другие).
Дерево объектов MIB подобно системе DNS (Domain Name System). Тут аналогично имеются символьные имена (аналогично NS имени) и называемые ASN.1 нотацией, и соответствующие им числовые значения (аналогично IP адресам), называемые dot нотацией. Каждый объект в MIB состоит из нескольких чисел, разделенных точками. Числам соответствуют текстовые наименования. При этом, в отличие от DNS - нет какого-то единого централизованного сервера, отвечающего за разолвинг имен. Все разрешения имен из символов в числа происходят силами SNMP менеджера (в зависимости от того, какие MIB загружены в менеджер). Весь обмен между узлами SNMP происходит только в числовом виде. В символьном виде, наименования используются только для отображения на экране или в документации.
Архитектура SNMP:
Сеть, использующая SNMP для управления содержит три основных компонента:
-
SNMP менеджер - ПО, устанавливаемое на ПК администратора (системы мониторинга) -
SNMP агент - ПО, запущенное на сетевом узле, за которым осуществляется мониторинг. -
SNMP MIB - MIB это Management information base. Этот компонент системы обеспечивает структурированость данных, которыми обмениваются агенты и менеджеры. По сути - это некая база данных в виде текстовых фалов.
SNMP менеджер и SNMP агент
Для понимания назначения компонентов, можно сказать, что SNMP менеджер является прослойкой (интерфейсом) между оператором\администратором и сетевым узлом с запущенным SNMP агентом. Так же, можно сказать, что SNMP агент - это интерфейс между SNMP менеджером и железным оборудованием на сетевом узле. Если провести аналогию протокола SNMP с клиент-серверной архитектурой (например, веб-сервера) то веб-сервер работает как служба на некотором порту, а пользователь силами браузера обращается к веб-серверу как клиент. Это четко обозначенная архитектура с выраженным клиентом и сервером. В случае SNMP роли клиента и сервера несколько размыты. Например, SNMP агент является своего рода службой, работающей на устройстве (за которым производится мониторинг) и обрабатывает запросы на определенном порту udp/161, то есть фактически является сервером. А SNMP менеджер является своего рода клиентом, который обращается к SNMP агенту. В SNMP существует т.н. Trap. Это запрос от агента к менеджеру. Точнее даже не запрос, а уведомление. При отправке данного уведомления, агент и менеджер "меняются ролями". То есть, менеджер в таком случае должен являться сервером, работающем на порту udp/162, а агент является клиентом. В последних версиях SNMP trap может именоваться как
извещение (notification).
SNMP работает на 7 уровне модели OSI, то есть является службой прикладного уровня. Взаимодействие агента и менеджера на уровне протокола SNMP организуется посредством т.н. объектов PDU (Protocol Data Unit), которые инкапсулируются в транспортный протокол. Хотя, SNMP поддерживает различные виды транспорта, в 99% случаев используется - UDP. При этом, каждое сообщение PDU содержит определенную команду (на чтение переменной, запись значения переменной, или ответ\trap агента). В целом, взаимодействие узлов по SNMP можно представить следующей последовательностью: менеджер -> SNMP(PDU)-UDP-IP-Ethernet-IP-UDP-SNMP(PDU) ->агент. При использовании шифрования в SNMP, по умолчанию используются порт для запросов\ответов udp/10161, а Trap отправляются на udp/10162.
Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB. Тем самым делая ее доступной для менеджеров. Давайте рассмотрим схему взаимодействия SNMP-агент - SNMP-менеджер:
Итак, как я уже сказал, SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника (о полной структуре пакета SNMP опишу ниже). Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент таким образом предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.Часто OID характеризующий определенный объект в дереве MIB сравнивают со структурой телефонных номеров, т. к. они (номера) так же иерархичны и отдельные части номера назначаются различными организациями. Например, международные телефонные номера состоят из кода страны (назначаемого международной организацией) и телефонного номера в том виде, в котором он определен локально в стране. При этом, телефонный номер в стране делится на код области \ края \ региона, номер АТС и далее номер абонента, привязанного к АТС. Аналогично - в MIB OID верхнего уровня назначаются международной организацией (ISO IEC???), ветки OID нижнего уровня назначаются организациями, отвечающими за эти ветки.
2.Структура OID
Итак, структура OID в дереве MIB:
В вершине дерева - корень (точка), от которого ответвляются ветви. Во многих схемах приведены некоторые ветви верхнего уровня (например itu-t, iso\itu-t и другие ниже), но информации об их назначении я не нашел. Посему, нас интересует вертка iso (0), которая хранит в себе следующие значения до internet (1): iso.org.dod.internet, что соответствует числовому ID .1.3.6.1.
Данный раздел (iso.org.dod.internet) разветвляется на подразделы, которые в большинстве своем контролируются IANA и состоят (согласно RFC1155) из:
· directory OID=1.3.6.1.1 (iso.org.dod.internet.directory) - зарезервировано для использования в будущем.
· mgmt OID=1.3.6.1.2 (iso.org.dod.internet.mgmt) - в этой ветке находится стандартные ответвления объектов.
· experimental OID=1.3.6.1.3 (iso.org.dod.internet.experimental) - это ветка для экспериментов разработчиков.
· private OID=1.3.6.1.4 (iso.org.dod.internet.private) - раздел предназначен для использования производителями оборудования.
Далее, необходимо рассмотреть отдельным пунктом ветку 1.3.6.1.2 (iso.org.dod.internet.mgmt), состоящую из подветки mib-2 (1), а так же reserved (0), pib (2), http (9)и некоторых других. Стоит отметить, что в зависимости от версии протокола (SNMPv1 vs SNMPv2) на месте данной ветки могут быть «прилинкованы» разные поддеревья в целом имеющие примерно одинаковую структуру и одинаковые идентификаторы, но в более новой версии протокола - поддерево более расширено. Наверно, в этом и состоит несовместимость версий протокола.
Итак, iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1): данная ветка является базовой для большинства сетевых устройств и содержится практически в любом устройстве. Ветка поделена на базовые группы (которых на текущий момент более 170), характерные для любого сетевого оборудования. Давайте рассмотрим наиболее применяемые:
1. iso.org.dod.internet.mgmt.mib-2.system (1.3.6.1.2.1.1) - ветка содержит в себе несколько объектов, характеризующих хост (аптайм, версия ОС и др.), описана в RFC1213.
2. iso.org.dod.internet.mgmt.mib-2.interface (1.3.6.1.2.1.2) - содержит объекты, описывающие сетевую подсистему хоста (количество интерфейсов, размер MTU, скорость передачи, физические адреса и т. п.), описана в RFC2863.
3. iso.org.dod.internet.mgmt.mib-2.ip (1.3.6.1.2.1.4) - содержит набор объектов, описывающих данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов и мн.др). Описана в RFC1213.
4. iso.org.dod.internet.mgmt.mib-2.tcp (1.3.6.1.2.1.6) и iso.org.dod.internet.mgmt.mib-2.udp (1.3.6.1.2.1.7) - содержат объекты, хранящие в себе информацию, касающуюся соответствующего транспортного протокола. Описана в RFC1213.