Архитектура протоколов для обмена управляющей информацией между менеджером и агентом 1 страница
Функции менеджера и агента при обмене управляющей информацией
Сеть управления может быть постороена как иерархическая, так и одноуровневая (одноранговая). Количество менеджеров в сети управления одного оператора может быть несколько, и зависит от многих факторов, например, для гетерогенной сети, постороенной на оборудовании разных производителей, оператор вынужден использовать несколько управлеяющих систем, т.к. интегрированные системы управления либо очень дороги, либо ограничены по количеству и типам поддерживаемых MIB (баз данных управляющей информации).
В данном пособии рассматриваем вариант сети управления одноранговый с одним менеджером и несколькими, территориально распределенными (по управляемым объектам) агентам.
В центре управления сетью устанавливается сервер с программным обеспечением менеджера, выполняющим основные функции сбора, хранения, обработки, анализа управляющей информации, а также принятия управляющих решений. Для работы с персоналом центра управления, менеджер поддерживает функции интерфейсы F, G, обеспечивая работу нескольких рабочих мест (WS или АРМ). С этих рабочих мест персонал может выполнять администрирование сети.
Управляемое устройство, на котором функционирует программа-агент, может быть любого типа — например, сервер доступа в Интернет, УПАТС, АТС, мультиплексор SDH, маршрутизаторы, концентраторы и т.п. Программы управления должны быть построены таким образом, чтобы минимизировать воздействие программы-агента на управляемое устройство.
Программы-агенты по заданию менеджера или автоматически могут отслеживать следующие показатели работы сетевого оборудования:
· число и состояние каналов;
· сообщения о неисправности (сигналы тревог – alarm);
· число байтов и пакетов, входящих и исходящих из управляемого устройства;
· длина очереди в буферной памяти управляемого маршрутизатора;
· пропускная способность управляемого интерфейса и т.д.
В целом, функции управления определены рекомендацией ITU-T X.700, в виде так называемых 5-ти функциональных областей:
· управление конфигурацией сети – CM (Configuration Management),
· устранение последствий отказов – FM (Faults Management),
· управление рабочими характеристиками – PM (Performance Management),
· управление расчетами – AM (Account Management, Billing),
· управление защитой информации (безопасностью) – SM (Security Management).
В ряде рекомендаций серии Х.73х, Х.74х, Х.800 и М.3ххх эти функциональные области детализируются до отдельных функций и процедур.
Архитектура протоколов для обмена управляющей информацией между менеджером и агентом
Интерфейс между менеджером и агентами реализуется посредством стека сетевых и прикладных протоколов. В данном пособии рассмотрим вариант обмена управляющей информации по стеку протоколов SNMP/UDP/IP/Ethernret, часто используемому для управления локальными сетями.
1.2.1 Стек протоколов IETF (TCP-UDP/IP)
На рисунке 2 иллюстрируется данный стек протоколов в сравнении с семиуровневой моделью ISO.
| Уровни OSI-ISO | Уровни стека IETF | ||
| Приложения | Приложения (HP_OV, TNG, …) | ||
| Прикладной | Уровень сервисных протоколов | SNMP (Порты 161, 162) | |
| Представительный | |||
| Сеансовый | |||
| Транспортный | Транспортный | TCP, UDP | |
| Сетевой | Сетевой (WAN) | IP | |
| Канальный | Уровень сетевых интерфейсов (LAN, MAN) | Ethernet, ATM, FR, LAPD, … | |
| Физический |
Рисунок 2 – Стек протоколов SNMP/UDP/IP/Ethernet
Форматы заголовков протоколов, входящих в стек SNMP/UDP/IP/Ethernet:
Для передачи SNMP-сообщений используются протоколы UDP/IP/Ethernet, вносящие некоторую избыточность за счет своих заголовков.
На рисунке 3 приводятся общие форматы протоколов, входящих в этот стек.
| Заголовок Ethernet | Заголовок IP | Заголовок UDP | Заголовок и содержимое протокола SNMP | ||||||||||||||||
| 14 байт | 20 байт | 8байт | (Длина и содержимое определяется приложением) | ||||||||||||||||
      | |||||||||||||||||||
| DA байт | SA байт | Type 2 байта | |||||||||||||||||
| Version бита | Header Length бита | ToS бит | Длина IP-пакет бит | ID бит | Flags 3 бита | Смещение фрагмент бит | TTL бит | protocol (SAP) бит | CRC бит | IP SA бита | IP DA бита | ||||||||
| UDP-port Отправителя (от кого) 16 бит | UDP-port Получателя (кому) 16 бит | Длина UDP-пакета 16 бит | Контрольная сумма пакета 16 бит | ||||||||||||||||
| Рисунок 3 – Форматы заголовков протоколов Ethernet/IP/UDP | |||||||||||||||||||
Поля протокола SNMP кодируются в соответствии с правилами BER (X.209) и в общем случае представлены в виде формата T-L-V (Тэг-Длина-Значение).
Содержимое этих полей зависит от конкретного типа PDU (протокольного блока данных).
В первой версии протокола SNMP (SNMPv1) было предложено пять типов PDU (Get, Get-next, Set, Response и Trap), форматы которых несколько отличаются между собой.
Более подробно форматы заголовков и содержимого протокола SNMP рассматривается в следующем разделе и составляет основную часть предлагаемого задания.
Конкретные трассировки сообщений протокола SNMP, измеренные у реального Интернет-провайдера приводятся в вариантах заданий. Все трассировки сообщений там представлены в шестнадцатиричных кодах и задачей студента является расшифровать значение полей этих сообщений по предлагаемой методике.
Общий формат сообщений SNMP. Представление о формуле T-L-V – смотри в описании языка ASN.1 и правил кодирования BER.
| Version (INTEGER) | Community (OCTET STRING) | SNMP-PDUs (смотри ниже) |
| T-L-V | T-L-V | T – L- V |
Рисунок 4 – Общий формат сообщений протокола SNMP
Форматы основных PDU-SNMP представлены ниже.
| Формат PDUs SNMP Get, Get-next, Set и Response (T-L-V) | ||||||||
| Request ID (get, set, response) | Error status | Error index | Variable bindings | |||||
| T – L- V | T-L-V | T-L-V | T – L- V | |||||
| Формат PDU SNMP Trap (T-L-V) | ||||||||
| Enterprise | Agent Address | Generic Trap Type | Specific Trap code | Time stamp | Variable bindings | |||
| T – L- V | T-L-V | T-L-V | T-L-V | T-L-V | T – L- V | |||
Рисунок 5 – Форматы сообщений протокола SNMP
2. Основы управляющего протокола SNMP
2.1 Назначение и функции протокола
Протокол SNMP был разработан с целью проверки функционирования сетевых маршрутизаторов и мостов.
В системах управления на основе протокола SNMP, стандартизуются следующие элементы:
- протокол взаимодействия агента и менеджера, т.е. SNMP;
- язык описания моделей MIB и сообщений SNMP — язык абстрактной синтаксической нотации ASN.1 (стандарт ISO 8824:1987, рекомендации ITU-T Х.208);
- несколько конкретных моделей MIB (MIB-I, MIB-II, RMON, RMON 2), имена объектов которых регистрируются в дереве стандартов ISO.
Сегодня протокол SNMP используется при управлении любыми видами оборудования и ПО в телекоммуникациях. Агенты SNMP встраиваются в аналоговые модемы, модемы ADSL, коммутаторы ATM и т. д.
SNMP — протокол прикладного уровня в стеке TCP/IP. SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB (Management Information Base).
Простота SNMP определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB II. Сам протокол SNMP также несложен.
Основные операции по управлению вынесены в ПО менеджера.
Для того, чтобы объект был виден для управления со стороны менеджера, необходимо внедрить на управляемом объекте ПО агента с поддержкой протокола SNMP и соответствующей базы данных управляющей информации – MIB.
Агент в протоколе SNMP — это обрабатывающий элемент, который выполняет пассивную роль, передавая в ПО менеджера по его запросу значения накопленных статистических переменных, тем самым обеспечивая доступ к значениям переменных MIB и дает менеджеру возможность реализовывать функции по управлению и наблюдению за устройством.
При этом устройство, имеющее встроенного агента должно работть с минимальными издержками на поддержку протокола SNMP, а основная производительность устройства с этим агентом должна быть использована для выполнения своих основных функций маршрутизатора, моста или концентратора, а агент занимается сбором статистики и значений переменных состояния устройства и передачей их менеджеру системы управления.
Протокол SNMP допускает возможность не только проверки, но и внесения изменений в функционирование указанных устройств.
Вся информация об объектах системы-агента подержится в так называемой MIB (management information base) – базе управляющей информации, другими словами MIB представляет собой совокупность данных об объектах, доступных для операций записи-чтения для конкретного менеджера (см. раздел 2.3.3 – Базы данных управляющей информации – MIB).
Есть стандарты, определяющие структуру MIB, в том числе набор типов ее объектов, их имена и допустимые операции над этими объектами. Древовидная структура MIB стандартизована ISO и ITU-T и содержит обязательные (стандартные) поддеревья, а также частные (private) поддеревья, позволяющие изготовителю сетевых устройств управлять специфическими функциями на основе стандартизованных объектов MIB.
Собственно функции протокола SNMP, реализуемые посредством соответствующих сообщений, сводятся к следующим:
· Опросить содержимое MIB на стороне агента
· Изменить состояние переменных в MIB агента
· Ответить на запросы менеджера
· Уведомить менеджера о нештатных ситуациях на стороне агента
2.1.1 Версии протокола SNMP
Первая версия этого протокола была опубликована организацией IETF в 1990-м году в документе – RFC-1157 и ориентировалась на управление в локальных сетях.
С развитием сети Интернет протокол SNMP стал использоваться для управления территориально удаленными объектами, и тогда выявились такие недостатки первой версии SNMPv1 как:
· незащищенность от несанкционированного доступа,
· избыточность и
· недостаточная функциональность.
В последующем недостатки первой версии постепенно ликвидировались в версиях протокола
· SNMPv2 (RFC-1901…1910) и
· SNMPv3 (RFC-3410…3419).
При этом название «Simple - Простой» для последующих протоколов после первой версии уже не совсем соответствует действительности.
Одновременно для поддержки новых функций в следующих версиях SNMP, разрабатывалист соответствующие базы данных управляющей информации (MIB), ориентированные на версии SNMPv2, SNMPv3.
Более подробно о дополнительных функциях SNMP, появившихся в новых версиях, а также о новых версиях MIB будет описано ниже.
Сфера действия протокола SNMP в настоящее время включает любые сетевые устройства, такие как хабы, шлюзы, хосты и т.д.
2.1.2 Недостатки протокола SNMP
Указанные ниже недостатки имеют отношение в основном к первой версии протокола (RFC-1157), разработанной для управления локальными сетями, где безопасность и надежность поддерживаются за счет ограниченных размеров управляемой сети, а такой недостаток как информационная избыточность — не является решаюшим в локальной сети.
Тем не менее, при использовании протокола SNMPv1 за пределами локальной сети, необходимо осознавать его недостатки (впрочем, хорошо известные хакерам):
· Низкая безопасность. Отсутствие средств взаимной аутентификации агентов и менеджеров. Единственное средство идентификации — «строка сообщества» — «community string». Эта строка в сообщении SNMP передаётся в открытой форме и служит основой для деления агентов и менеджеров на «сообщества», так что агент взаимодействует только с теми менеджерами, которые указывают в поле community string ту же символьную строку, что и строка, хранящаяся в памяти агента. По сути это не способ аутентификации, а способ структурирования агентов и менеджеров.
- Низкая надежность. Работа через ненадёжный протокол UDP (подавляющее большинство реализации агентов SNMP) приводит к потерям аварийных сообщений (сообщений trap) от агентов к менеджерам, что может привести к некачественному управлению.
- Высокая информационная избыточность. SNMP-Агенты не отличаются особым интеллектом, в частности не могут производить на месте какую-либо серьёзную обработку запросов от менеджеров. Вместо этого SNMP-агент транслирует всю информацию к менеджеру, где и происходит основная обработка. Это часто создает избыточный служебный трафик. В локальной сети этого можно не замечать, но если управление удаленными объектами ведется через арендованные каналы сетей общего пользования, то избыточный трафик сопровождается также издержками на его оплату.
Разработчики платформ управления стараются преодолеть эти недостатки. Например, в платформе HP OpenView Telecom DM TMN, являющейся платформой для разработки многоуровневых систем управления в соответствии со стандартами TMN и ISO, работает новая версия SNMP, организующая надежный обмен сообщениями между агентами и менеджерами за счет самостоятельной организации повторных передач сообщений SNMP при их потерях.
2.1.3 Сравнение протоколов SNMP и СМIР
Не вдаваясь в рамках этого пособия в детали протокола CMIP (Common Management Information Protocol), разработанного ITU-T для управления большими (операторскими) сетями, полезно знать не только недостатки протокола SNMP, но и его плюсы, чтобы правильно позиционировать этот протокол в ряду других управляющих протоколов.
· SNMP позволяет строить простые и сложные системы управления, а СМIР определяет высокий начальный уровень сложности системы управления, так как для его работы необходимо реализовать ряд вспомогагельных служб, объектов и баз данных объектов.
- Агенты СМIР выполняют более сложные функции, чем агенты SNMP. Из-за этого операции, которые менеджеру можно выполнить над агентом SNMP, носят атомарный характер, что приводит к многочисленным обменам между менеджером и агентом.
- CMIP позволяет с помощью одной команды воздействовать сразу на группу агентов, применив такие опции, как обзор и фильтрация.
- Уведомления агента SNMP посылаются менеджеру без подтверждения, в то время как уведомления агента CMIP всегда передаются с помощью надежного транспортного протокола.
- Часть проблем SNMP можно решить за счет применения более интеллектуальных MIB (к которым относится RMON MIB), но для многих устройств таких MIB нет.
- CMIP рассчитан на интеллектуальных агентов, которые могут по одной простой команде от менеджера выполнить сложную последовательность действий.
- CMIP лучше масштабируется, так как может воздействовать сразу на несколько объектов, а ответы от агентов проходят через фильтры, ограничивающие передачу управляющей информации только определенным агентам и менеджерам.
Некоторые выводы:
Подводя итоги в обзорной части пособия, можно сделать следующие выводы:
1. В основе всех систем управления (СУ) сетями лежит схема «агент — менеджер». Эта схема использует абстрактную модель управляемого ресурса, называемую базой управляющей информации — Management Information Base, MIB.
2. Агент взаимодействует с управляемым ресурсом по нестандартному интерфейсу, а с менеджером — по стандартному индерфейсу через сетевые протоколы (точнее стек стандартизованных протоколов).
3. В больших СУ используется несколько менеджеров, взаимодействующих друг с другом по одноранговой или иерархической схеме.
4. Иерархическая схема взаимодействия менеджеров соответствует стандартам TMN и является более перспективной.
5. При построении СУ используется платформенный подход. Платформа СУ выполняет для менеджеров роль ОС для обычных приложений и обеспечивает разработчика менеджеров общим набором системных вызовов для любой СУ независимо от ее назначения.
6. Существуют два семейства стандартов СУ: СУ на основе SNMP, и международные стандарты, опирающиеся на протокол CMIP. SNMP специфицирует минимум аспектов и элементов CУ, а ISO/ITU-T — максимум.
7. СУ SNMP основаны на следующих концепциях, ориентированных на минимальную загрузку управляемых устройств:
o агент выполняет самые простые функции и работает в основном по инициативе менеджера;
o СУ состоит из одного менеджера, который периодически опрашивает всех агентов;
o SNMP использует транспортный протокол UDP и два основных типа команд — get для получения данных от агента и set для передачи управляющих воздействий агенту;
o агент может послать данные менеджеру по своей инициативе с помощью команды trap, но число ситуаций, в которых он применяет эту команду, очень невелико.
o Базы управляющей информации MIВ в SNMP состоят из дерева атрибутов, называемых объектами и группами объектов.
o Первые MIВ были ориентированы на управление маршрутизаторами:
o MIB-I — только контроль, MIB-II — контроль и управление. Разработка RMON MIB направлена на создание интеллектуальных агентов, контролирующих нижний уровень, — интерфейсы Ethernet и Token Ring. Имена объектов стандартных MIB Internet зарегистрированы в дереве регистрации имен стандартов ISO.
8. Стандарты ISO/ITU-T используют объектно-ориентированный подход. Определено несколько суперклассов обобщенных управляемых объектов, на основании которых путем наследования свойств создаются более специфические классы объектов.
9. Для описания управляемых объектов (УО) OSI разработаны правила GDMO, основанные на формах определенной структуры, заполняемых с помощью языка ASN.1.
10. Для представления знаний об УО, агентах и менеджерах СУ в OSI используется три древовидные базы данных: дерево наследования, дерево включения и дерево имен.
2.2 Сообщения (примитивы) протокола SNMP.
В SNMP агент взаимодействует с менеджером по принципу запрос-ответ. Генерируя какой-либо запрос, менеджер тем самым осуществляет определенное действие (операцию) по управлению объектом.
Действия менеджера и агента реализуются посредством обмена специфицированными протокольными блоками данных – PDU-SNMP, обозначаемых как запросы (команды) и ответы.
В данных методических указаниях мы будем считать синонимами термины SNMP-сообщение и протокольный блок данных - PDU.
Агент по своей иницитиве генерирует только одно действие, называемое ловушкой ("trap" - ловушка). Другие действия агентов сводятся к ответам (Response) на запросы менеджера.
Менеджеры могут генерировать три (в версии SNMPv1) вида запросов – GetRequest, GetNextRequest, SetRequest.
Итак, всего в версии SNMPv1 определены 5 типов запросов-ответов (PDU).
- GetRequest – Этот PDU реализует функцию опроса управляемых объектов. Позволяет получить от агента содержимое одного объекта из MIB. Часто используется сокращенная запись – Get.
- GetNextRequest – Этот PDU реализует операцию получения следующего экземпляра из таблицы. С помощью этой операции просматривается весь список объектов. Как только встречается первый объект из другой ветки MIB, операция прекращается. Сокращенное название звучит как GetNext.
- SetRequest – Этот PDU реализует реализует функцию изменения данных в MIB. Часто о ней говорят просто как о команде Set. С помощью команды Set происходит собственно управление устройством. Обычно определяются реакции агента на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.
- GetResponse – Этот PDU выполняется агентом в ответ на команды GetRequest, GetNextRequest, SetRequest. Если это ответ на первые две, то внутрь будут вложены запрошенные данные, если это ответ на Set, то внутри будет подтверждение об успешном выполнении операции Set. Самые распространенные названия для этой команды Reply или Response.
- Trap – Этот PDU позволяет агенту реализовать функцию оповещения менеджера о том, что на управляемом объекте произошла нештатная ситуация (тревога – alarm). Содержит внутри себя специальный идентификатор объекта – OID, показывающий, что это ловушка, а также информацию о том какой MIB-объект установил ловушку и данные этого объекта.
В общем виде процедуры обмена информацией между менеджером и агентом можно сформулировать следующим образом (см. рис. 6):
1. Менеджер формирует и посылает агенту стандартное сообщение-запрос для получения информации об объекте, на котором расположен данный агент;
2. Агент формирует ответ на запрос и посылает этот ответ менджеру;
3. Менеджер на основе полученной информации о состоянии объекта формирует и посылает агенту стандартное сообщение об изменении параметров;
4. Агент, получив сообщение на изменение параметров в MIB, посылает сообщение-прерывание и производит соответствующую реконфигурацию.
Рисунок. 6 – Процедуры протокола SNMP
Сообщения, содержащие такие блоки данных протокола как GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU, отправляются от менеджера к агенту, а сообщения, содержащие GetResponse-PDU и Trap-PDU, отправляются от агента к менеджеру.
Менеджер отправляет свои три запроса на UDP порт 161. Агент отправляет «ловушки» (trap) на UDP порт 162. Так как используются два разных порта, одна система может выступать в роли менеджера и агента одновременно.
Состав и формат сообщений протокола SNMP можно привести в традиционной форме, отображающей различные поля заголовков и информационной части.
На рис.7 представлен традиционный формат для SNMP-сообщений Get, GetNext Set и Response.
Рисунок 7 – Структура сообщения SNMP
Каждая часть сообщения SNMP кодируется в формате T-L-V (Тэг-Длина-Значение), в соответствии с правилами кодирования BER, описанными в рекомендации ITU-T X.209.
С учетом правил кодирования приведем формат сообщений протокола SNMP в следующем виде (см. рис. 8):
| Заголовок SNMP | Заголовок PDU (для Get, GetNext, Set, Response) | Переменные (Идентификаторы объектов в MIB, значения параметров) | ||||||||||||||||||||
| Версия | Пароль (Community) | Тип PDU | Идентификатор PDU | Статус ошибки | Индекс ошибки | Имя (Tag) | Длина (L) | Значение (Value) | ||||||||||||||
| Vers – 1 | По умолчанию: public | См. табл.1 | Целое значение от 0 до 232-1 | См. табл.2 | См. ниже | *** | **** | Имя (Tag) | Длина (L) | … | ||||||||||||
| T | L | V | T | L | V | T | L | V | T | L | V | T | L | V | T | L | V | T | L | T | L | V |
Рисунок 8 – Формат SNMP-сообщений, вкладываемых в UDP-дейтаграммы
Каждое сообщение SNMP протокола начинается с заголовка, определяющего общие функции данного сообщения (спросить, изменить, ответить, уведомить).
В заголовок любого SNMP-сообщения входят следующие поля:
· Версия протокола. В этом поле указывается целое число на 1 меньше версии протокола (Version – 1, т.е. номер версии SNMP минус один).
· Пароль доступа к управляемым ресурсам. В качестве такого пароля в SNMPv1 используется поле Community, которое содержит строку байт (октетов). Если администратором не используется другое, то по умолчанию эти октеты кодируют символы “public”, что означает общий доступ.
· Тип PDU (Protocol Data Unit – Протокольный блок данных). Определяет код команды (запроса) или ответа и, соответственно, основные функции данного сообщения (спросить, изменить, ответить, известить и т.п.). Коды запросов приведены в табл.1.
Таблица 1 – Коды заголовков сообщений протокола SNMP