SMON, AMON и другие

Новые сетевые технологии требуют применения новых средств мониторинга.

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

ПРОБЛЕМЫ МОНИТОРИНГА КОММУТИРУЕМЫХ СЕТЕЙ

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

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

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

SMON ОТ LANNET

Мониторинг коммутаторов (Switch MONitoring, SMON) был впервые предложен в 1996 году компанией LANNET (теперь подразделение Lucent Technologies) для своих коммутаторов LANswitch Plus. Вместо того чтобы реализовывать агентов мониторинга на каждом порту, компания встроила в коммутатор один аппаратный зонд SMON для мониторинга всего трафика через коммутирующую структуру. Таким образом, он позволял видеть всю картину трафика через коммутатор так, как если бы это был один сегмент локальной сети.

Однако LANNET не ограничилась мониторингом коммутаторов самих по себе. Архитектура SMON предполагала подход сверху вниз (см. Рисунок 1). На верхнем уровне Enterprise SMON администратор мог видеть всю картину коммутируемой сети, а при необходимости он имел возможность углубляться до необходимого уровня детализации — до уровня коммутатора, виртуальной локальной сети, порта, диалога или конкретного пользователя.

Рисунок 1. Общая архитектура мониторинга коммутаторов в соответствии с SMON

В SMON компания LANNET отказалась от многих групп RMON (первоначально SMON поддерживал только четыре группы — Host Matrix, Host, Host TopN и Ethernet Statistics), а взамен ввела несколько своих: Enterprise Switch Statistics — для одновременного мониторинга нескольких коммутаторов, Switch Statistics — для общего контроля за функционированием и состоянием коммутатора, Port и Port TopN — для быстрого определения утилизации портов и выявления наиболее загруженных среди них, а также Switch Host, HostTopN и Host Matrix — для быстрой идентификации наиболее активных генераторов трафика и контроля диалогов через коммутатор.

SMON НА ПУТИ К СТАНДАРТУ

LANNET представила SMON в IETF в качестве предложения по стандарту. Принятие его в качестве стандарта должно было состояться осенью 1998 года. Заявленная цель нового стандарта состоит в обеспечении удаленного мониторинга коммутируемых сетей.

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

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

СТАНДАРТЫ УПРАВЛЕНИЯ СЕТЯМИ ATM

Во многом отличающаяся от пакетных сетей Ethernet, технология ATM ставит свои проблемы в области управления сетями. Как и в общем случае, управление сетью на базе устройств различных производителей невозможно без наличия единого коммуникационного протокола и общего набора объектов управления. Таковыми являются протоколы SNMP и CMIP и соответствующие им базы управляющей информации. Если ATM Forum использует оба протокола, то IETF — только SNMP, а ITU-T — только CMIP.

Технология ATM предназначена как для частных, так и для общедоступных сетей, причем аспекты управления сетью в этих случаях несколько различаются. ATM Forum определил общую модель управления сетью (см. Рисунок 2). Управление частными сетями осуществляется через интерфейсы M1 и M2. М1 отвечает за управление оборудованием конечных пользователей, подключенное к коммутаторам, а М2 — за управление коммутаторами и сетями ATM (М3 предназначен для обмена информацией об ошибках, параметрах и конфигурации между частными и общедоступными сетями, М4 — для управления общедоступными сетями ATM и коммутаторами в них, а М5 — для обмена управляющей информацией между двумя общедоступными сетями). Для каждого из интерфейсов ATM Forum определил свои MIB.

Рисунок 2. Общая модель управления частными и общедоступными сетями АТМ в соответствии со стандартом АТМ Forum.

Одним из первых принятых IETF стандартов для управления частными сетями и устройствами ATM стала AToM MIB, RFC 1695 (иногда ее еще называют просто ATM MIB). Она предоставляет информацию о конфигурации и характеристиках виртуальных каналов между конечными точками. Данная MIB обязательна для реализации всеми ПК, коммутаторами и маршрутизаторами в локальных сетях, если они взаимодействуют между собой по ATM. В общем, AToM MIB предназначена для получения информации о конфигурации и статусе для интерфейсов M1, M2 и М3.

Кроме того, IETF принял стандар-ты на MIB для различных систем передачи, поддерживающих ATM, в том числе RFC 1406 для управления каналами Т-1/Е-1, RFC 1407 для Т-3/Е-3 и RFC 1595 для SONET.

КАНАЛООТВОД

Однако и ATM MIB, и SONET MIB, и др. обеспечивали поддержку мониторинга лишь на нижних — физическом и ATM — уровнях. Администраторы же сетей нуждались в средствах мониторинга и на более высоких уровнях для разрешения проблем в функционировании протоколов и т. п. Образованный в 1995 году консорциум по разработке стандартов мониторинга ATM (ATM Monitoring, AMON) предложил базу управляющей информации для управления каналами ATM (ATM Circuit Steering MIB, ACS MIB, иногда ее еще называют Virtual Circuit Mirroring MIB, или даже просто AMON MIB).

По своей природе технология ATM ориентирована на установление соединения, поэтому данные пользователей и приложений могут передаваться через конкретные виртуальные соединения (Virtual Channel, VC). Вместе с тем ATM предусматривает механизм доставки трафика по нескольким указанным адресам. Эту возможность и использует ACS MIB для направления трафика на тестовое оборудование в целях его декодирования и анализа (соединения типа "точка—точка" преобразуются в соединения типа "точка—группа").

УДАЛЕННЫЙ МОНИТОРИНГ ATM

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

С этой целью ряд компаний разработал предложение для IETF по спецификации ATM RMON. Оно опирается на стандартные механизмы RMON для сбора и анализа данных на уровне ячеек ATM. Помимо направления каналов на выделенный анализатор, как предлагается ACS MIB, данная спецификация предусматривает и два других метода сбора информации, в том числе возможность встраивания зондов RMON непосредственно в коммутирующую структуру ATM.

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

Вместе с RMON и RMON-2 MIB для мониторинга сетей передачи кадров эта спецификация позволит создать новый класс приложений для мониторинга всего трафика в локальных сетях, где магистральная сеть построена на базе технологии ATM.

SNMP, ВЕРСИЯ 3

Несмотря на то что концепция службы идентификации с поддержкой одной или даже нескольких соответствующих схем была заложена еще в первую версию простого протокола управления сетью, ни одной такой схемы помимо тривиальной идентификации по принадлежности (community string) не было реализовано, причем имя передавалось в открытом виде. Эта слабость SNMP была известна его разработчикам, но они решили отказаться от определения жестких мер защиты, дабы не усложнять (и, соответственно, не затягивать) процедуру принятия стандарта в надежде, что служба идентификации будет определена в виде отдельного блока позднее.

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

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

Вместе с тем они не стали изобретать велосипед и многое позаимствовали из предшествующих разработок, в частности из RFC 1909, 1910 со спецификацией не получившей одобрения версии SNMPv2u. Как следствие, SNMPv3 можно рассматривать как дополнение SNMPv2 средствами защиты и администрирования.

Одной из возможных моделей обеспечения защиты является User-Based Security Model (USM) для защиты на уровне сообщений (RFC 2274). Она предназначена для предотвращения следующих угроз:

? изменения информации;
? нелегального проникновения;
? изменения потока сообщений;
? подслушивания.

В целях обеспечения целостности данных, а также во избежание нелегального проникновения USM использует такие алгоритмы хэширования, как MD5 и Secure Hash Algorithm для вычисления выборки сообщения. Для предупреждения некоторых атак с изменением потока сообщений USM предусматривает механизм свободно синхронизируемых монотонно возрастающих индикаторов времени. При необходимости защиты от подслушивания USM позволяет применять алгоритм шифрования DES.

Кроме того, данный RFC описывает MIB для удаленного мониторинга и управления конфигурационными параметрами USM, в том числе для распространения и управления ключами.

УПРАВЛЯЙ И ВЛАСТВУЙ

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