Ун-т «Дубна». Курс «Компьютерные сети»
| Вид материала | Лекция |
- Ун-т «Дубна». Курс «Компьютерные сети», 408.34kb.
- Ун-т «Дубна». Курс «Компьютерные сети», 371.9kb.
- Ун-т «Дубна». Курс «Компьютерные сети», 560.01kb.
- Ун-т «Дубна». Курс «Компьютерные сети», 276.95kb.
- Ун-т «Дубна». Курс «Компьютерные сети», 547.71kb.
- Ун-т «Дубна». Курс «Компьютерные сети», 546.8kb.
- Ун-т «Дубна». Курс «Компьютерные сети», 676.23kb.
- Урок по теме «Компьютерные сети. Интернет», 157.31kb.
- Ун-т «Дубна». Курс «Компьютерные сети», 611.15kb.
- Лекция Глобальные сети. Интернет. Корпоративные компьютерные сети, 89.75kb.
Ун-т «Дубна». Курс «Компьютерные сети».
Лекция 10.
- Архитектура сетевого управления, основные модели.
- Протокол SNMP.
- Технология удаленного мониторинга (RMON)
Архитектура сетевого управления
Сеть состоит из множества разбросанных по большой территории сложных программных и аппаратных элементов - линий связи, хостов, мостов, маршрутизаторов и т.д, а также различных протоколов, реализованных как аппаратно, так и программно, осуществляющих управление этими устройствами. Сетевой администратор, работа которого заключается в поддержании сети в работоспособном состоянии, должен иметь специальные средства, помогающие ему следить за состоянием сети и управлять ею.
В определенной степени возможности управления имеются в стандартных сетевых операционных системах. Однако любая сеть требует дополнительных специальных методов управления Это связано с большим количеством коммуникационного оборудования, работа которого критически важна для выполнения сетью своих основных функций.
Распределенный характер сети делает невозможным поддержание работы сети без централизованной системы управления, которая бы в автоматическом режиме собирала информацию о состоянии всех узлов.
Одна их первых систем управления – SunNet Manager – была создана в 1989 и была ориентирована на поддержание двух функций, которые до сих пор считаются главными для любой системы управления сетью, а именно,
- управление коммуникационным оборудованием и
- контроль трафика сети.
Обычно система управления работает в автоматизированном режиме, т.е. автоматически выполняет простые действия по управлению сетью, а более сложные решения предоставляет решать оператору на основе подготовленной в автоматическом режиме информации.
Системы управления представляют собой сложные программно-аппаратные комплексы. В небольшой сети можно применять отдельные программы управления наиболее сложными устройствами. Однако при росте сети возникает проблема объединения разрозненных программ в единую систему управления, либо замены этих разрозненных программ единой интегрированной системой управления.
Примерами функций управляющей системы могут служить:
- обнаружение неисправностей интерфейсной карты хоста или маршрутизатора,
- мониторинг хостов,
- мониторинг трафика с целью контроля за распределением ресурсов,
- обнаружение быстрых изменений в таблице маршрутизации
- мониторинг уровней обслуживания на предмет соответствия параметров качества обслуживания (задержки, пропускная способность, доступность служб и т.д.) соответствующим соглашениям о качестве,
- обнаружение вторжения (трафик от подозрительного источника и\или к подозрительному получателю),
- контроль производительности
- контроль неисправностей
- управление конфигурацией,
- управление учетными записями, регулирующими правила доступа пользователей к различным ресурсам
- управление безопасностью
Таким образом, сетевое администрирование включает разработку, интеграцию и координацию аппаратуры, программного обеспечения и людей для мониторинга, тестирования, опроса, конфигурирования, анализа, оценки и контроля сети ресурсов для удовлетворения требований реального времени, производительности и качества обслуживания за приемлемую цену.
В любых сложных системах, требующих управления, всегда присутствуют две стороны – управляющая и управляемая.
Мanaged devices (управляемые устройства, объекты, представляющие часть сетевого оборудования – мосты, принтеры, модемы, хосты и т.д., либо настраиваемые наборы параметров - протоколы) используют программные средства, позволяющие им посылать сигналы тревоги, когда они распознают проблемы. Проблемы распознаются, когда превышен один или более порогов, заданных пользователем (аналог сигнализации).
Management entities (управляющие объекты) после получения этих сигналов реагируют выполнением одного, нескольких или группы действий, включающих:
- Уведомление оператора
- Регистрацию события
- Отключение системы
- Автоматические попытки исправления системы
Большинство архитектур управления сети для построения взаимоотношений управляемой и управляющей сторон используют одну и ту же базовую структуру «менеджер – агент – управляемый объект». Такая модель позволяет строить достаточно сложные в структурном отношении распределенные системы управления.
Чтобы можно было автоматизировать управление объектами сети, создается модель управляемого объекта (устройства), называемая базой данных управляющей информации (MIB, Management Information Base), где отражаются характеристики, ассоциированные с данным объектом и необходимые для его контроля. Например, модель маршрутизатора включает такие характеристики как количество и тип портов, таблицу маршрутизации, количество единиц данных протоколов разных уровней, прошедших через эти порты.
Агент сетевого управления, соответствующий каждому сетевому устройству - это процесс, работающий (на основе программной и\или аппаратной реализации) в управляемом устройстве и непосредственно взаимодействующий с управляющим объектом (менеджером).
Агент и менеджер работают с базой MIB. Агент наполняет базу управляемого объекта текущими значениями параметров, а менеджер извлекает данные, на основании которых узнает, какими параметрами объекта можно управлять, и дает указания и запросы агенту. Таким образом, агент является посредником менеджера в управлении управляемым объектом.
Менеджер и агент взаимодействуют по стандартному протоколу, который позволяет менеджеру запрашивать значения параметров, хранящихся в MIB, а также передавать агенту информацию, на основе которой тот должен управлять объектом. Таким образом, протокол сам по себе не управляет сетью, а является инструментом, с помощью которого сетевой администратор может управлять сетью (осуществлять мониторинг, тестирование анализ и т.д.)
Обычно менеджер работает на отдельном компьютере, управляя несколькими агентами. Агенты встраиваются в управляемое оборудование, либо могут работать на отдельном компьютере, связанном с управляемым оборудованием. Из-за разнообразия объектов, требующих управления, способ взаимодействия агента с менеджером и объектом не стандартизован. Задача решается разработчиками в зависимости от конкретной ситуации.
Наличие нескольких менеджеров позволяет распределить между ними нагрузку по управлению и обеспечить тем самым масштабируемость системы. Связь между менеджерами может быть одноранговая и иерархическая.
В случае одноранговой связи каждый менеджер управляет своей частью сети на основе информации от нижележащих агентов. Координация работы достигается за счет обмена информацией между базами данных менеджеров. Центральный менеджер отсутствует. Такая система считается сейчас неэффективной.
Иерархическое построение связей между менеджерами является более гибким. Каждый менеджер нижнего уровня выполняет функции агента для менеджера верхнего уровня с использованием укрупненной модели MIB своей части сети. Такой подход сокращает объемы информации, циркулирующей между уровнями системы управления.
Модель управления сети ISO\OSI
Модель управления сети состоит из 5 концептуальных областей:
- Управление эффективностью включает анализ производительности и надежности на основе статистической оценки таких параметров как пропускная способность, интенсивность трафика, вероятность искажения данных и др.
- Управление конфигурацией сети и именованием (Confiiguration Management) заключается в конфигурировании элементов сети и сети в целом, определении таких параметров как сетевые адреса, идентификаторы и др., отображении связей между элементами сети в таблицах коммутации.
- Управление учетом использования ресурсов включает регистрацию времени использования различных ресурсов (устройств, каналов, транспортных служб), иногда - ведение платы за ресурсы.
- Управление неисправностями включает выявление, определение и устранение последствий сбоев и отказов в работе сети.
- Управление защитой данных (безопасностью) подразумевает контроль доступа к ресурсам сети (данным и оборудованию), сохранение целостности данных при передаче их через сеть. Включает процедуры проверки прав доступа к ресурсам, аутентификации пользователей, распределения ключей шифрования и др.
Управление эффективностью
Цель управления эффективностью - измерение и обеспечение различных аспектов эффективности сети (пропускная способность сети, время реакции пользователей, коэффициент использования линии) и включает несколько этапов:
- Сбор информации об эффективности по тем переменным, которые представляют интерес для администраторов сети.
- Анализ информации для определения базовых уровней.
- Определение соответствующих порогов эффективности для каждой переменной, когда их превышение указывает на проблемы в сети.
Управление конфигурацией
Цель управления конфигурацией - контролирование информации о сетевой и системной конфигурации для учета воздействия на работу сети различных версий аппаратных и программных элементов.
Управление учетом использования ресурсов
Цель управления учетом использования ресурсов - измерение параметров использования сети, чтобы можно было регулировать ее использование индивидуальными или групповыми пользователями.
Управление неисправностями
Цель управления неисправностями - выявить, зафиксировать, уведомить пользователей и (в пределах возможного) автоматически устранить проблемы в сети с тем, чтобы эффективно поддерживать работу сети. Управление неисправностями включает несколько шагов:
- Определение симптомов проблемы.
- Изолирование проблемы.
- Устранение проблемы.
- Проверка устранения неисправности на всех важных подсистемах.
- Регистрация обнаружения проблемы и ее решения.
Управление защитой данных
Цель управления защитой данных - контроль доступа к сетевым ресурсам в соответствии с политикой информационной безопасности.
Подсистемы управления защитой данных работают путем разделения источников на санкционированные и несанкционированные области и выполняют следующие функции:
- Идентифицируют чувствительные ресурсы сети (включая системы, файлы и другие объекты)
- Определяют отображения в виде карт между чувствительными источниками сети и набором пользователей
- Контролируют точки доступа к чувствительным ресурсам сети
- Регистрируют несоответствующий доступ к чувствительным ресурсам.
Архитектура управляющей системы включает три аспекта управления, т.е. отвечает на три вопроса:
-
как и за чем нужно следить
в какой форме передавать информацию
как обмениваться информацией (протокол связи)
Простой протокол управления сетью SNMP
Типичная сеть состоит из множества устройств различных производителей. Управлять такой сетью возможно только при наличии стандартного протокола управления. Первые разработки появились с конца 80х. Самым популярным протоколом управления в современных сетях является Simple Network Management Protocol (SNMP). Широкое распространение он получил в силу своей гибкости и расширяемости — SNMP позволяет описывать объекты для самых разных устройств.
Этот протокол был в свое время разработан как временное и очень простое решение для управления IP-сетей, что отразилось в названии. Однако он настолько понравился разработчикам оборудования и сетевым администраторам, что на долгие годы стал протоколом №1 в системах сетевого администрирования.
Это протокол прикладного уровня, разработанный для стека TCP\IP, хотя имеются его реализации для других стеков, например, IPX\SPX. Он используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, хранящихся в MIB.
В системах управления на базе SNMP стандартизованы следующие элементы.
- Протокол взаимодействия агента и менеджера (собственно SNMP), ответ на 3й вопрос.
- Язык описания моделей MIB и сообщений SNMP – структура управляющей информации – язык абстрактной синтаксической нотации ASN.1, определяет типы данных и правила для записи и изменения управляющей информации, ответ на 2й вопрос.
- Конкретные модели MIB (MIB-1, MIB-2, RMON, RMON-2), определяющие управляемые MIB-объекты и их характеристики, ответ на 1й вопрос.
- функции безопасности (присутствуют в последних версиях)
Модель SNMP состоит из четырех компонентов:
- управляемых узлов;
- станций управления (менеджеров);
- управляющей информации;
- протокола управления.
Управляемые узлы - компьютеры, коммутаторы, принтеры, маршрутизаторы, или любые другие устройства, способные сообщать информацию о своем состоянии. Узел должен иметь агента SNMP, который поддерживает локальную базу данных о состоянии устройства и истории событий.
Управление сетью осуществляется со станций управления, на которых установлено специальное программное обеспечение для взаимодействия с агентами по сети.
Станции управления взаимодействуют с агентами с помощью протокола SNMP. Он позволяет станции запрашивать значения локальных переменных агента и при необходимости изменять их.
Множество объектов, которыми управляет SNMP, составляет базу управляющей информации (Management Information Base, MIB).
Структура SNMP MIB
На сегодня существует несколько стандартов на базы данных управляющей информацией для протокола SNMP.
Первоначальная спецификация MIB-1 определяла только операции чтения значений переменной.
Спецификация MIB-2 определяет также операции изменения или установки значений объектов.
Объекты подразделяются на группы. В MIB-1 114 стандартных объектов и 8 групп; в MIB-2 – 185 объектов и 10 групп.
Группа System содержит общие данные об устройстве – имя, местонахождение, функции устройства, программное и аппаратное обеспечение.
Группа Interface – параметры сетевых интерфейсов (тип, количество, скорость обмена), сбор статистики сетевых адаптеров о количестве переданных и полученных пакетов и байтов.
Группа АТ – данные о соответствии адресов (IP, MAC), например, в рамках протокола ARP.
Группа IP описывает статистику работы маршрутизатора.
Группа ICMP собирает данные, относящиеся к сообщениям об ошибках в IP.
Группа TCP служит для учета числа открытых соединений, количества переданных и полученных сегментов и ошибок.
Группа UDP фиксирует число переданных дейтаграмм.
Группа EGP используется для Exterior Gateway Protocol (MIB-2).
Группа Transmission служит родительским узлом для специфичных баз управляющей информации (MIB2).
Группа SNMP - сбор статистики протокола SNMP.
Примеры объектов.
SysUpTime – содержит значение продолжительности времени работы системы с момента последней перезагрузки.
ifNumber – определяет количество сетевых интерфейсов устройства
ifEntry – вершина поддерева, описывающего конкретный интерфейс. Входящими в поддерево объектами являются:
- ifType – тип протокола, поддерживающего интерфейс
- ifMtu – максимальный размер пакета сетевого уровня, который можно послать через данный интерфейс, и т.д.
| Группы объектов в MIB-2 | ||
| Группа | Кол. | Описание |
| System | 7 | Имя и описание оборудования |
| Interfaces | 23 | Сетевые интерфейсы и трафик |
| AT | 3 | Трансляция адресов |
| IP | 42 | Статистика по IP-пакетам |
| ICMP | 26 | Статистика по сообщениям ICMP |
| TCP | 19 | Параметры и статистика TCP |
| UDP | 6 | Статистика трафика UDP |
| EGP | 20 | Статистика трафика для EGP |
| Transmission | 0 | Зарезервирована |
| SNMP | 29 | Статистика о трафике SNMP |
Собственно SNMP представляет собой протокол, регламентирующий сообщения по типу «запрос—ответ», которыми сетевые станции управления и агенты обмениваются между собой. Первая версия протокола SNMP предусматривает всего пять различных сообщений.
Менеджер агенту может послать следующие три сообщения: GetRequest, GetNextRequest и SetRequest. Первые два служат для запроса у агента значений конкретных переменных. Третье позволяет менеджеру изменять значения переменных.
Агент может отправлять два различных сообщения: GetResponse - служит для ответа на запрос от менеджера, Trap - посылается при обнаружении агентом чрезвычайного события.
Протоколом SNMPv2 вводится еще два типа сообщений. GetBulkRequest позволяет запросить целый массив переменных, InformRequest — одному менеджеру сообщить другому, какими переменными он управляет.
| Типы запросов SNMPv2 | |
| Сообщение | Описание |
| GetRequest | Запрос для получения значения одной или более переменных |
| GetNextRequest | Запрос следующей переменной |
| GetBulkRequest | Запрос большой таблицы |
| SetRequest | Изменение значения переменных |
| InformRequest | Сообщение менеджером другому менеджеру описания своей локальной MIB |
| Snmpv2Trap | Сообщение о прерывании от агента |
Любое SNMP-сообщение состоит из трех основных частей:
- версии протокола,
- идентификатора общности,
- области данных.
Идентификатор общности (Community String) используется для группирования устройств, управляемых определенным менеджером, т.е. является аналогом пароля.
В области данных содержатся собственно команды протоколов, имена объектов и их значения.
SNMP использует транспортный протокол UDP, что позволяет агентам и менеджерам работать независимо друг от друга. С другой стороны, обмен сообщениями по ненадежному каналу может вести к потере важной информации. Обмен сообщениями происходят по порту 161. Асинхронные прерывания станция управления принимает на порт 162. Максимальная допустимая длина сообщений SNMP ограничивается длиной до 484 байт.
Одно из самых слабых мест SNMPv1 — реализация защиты. Агенты должны быть уверены, что полученный ими запрос действительно исходит от станции управления.
В SNMPv1 идентификация отправителя осуществляется посредством включения в сообщения имени группы (community name), причем имя передается открытым текстом.
Таким образом, к недостаткам протокола SNMPv1 можно отнести:
(1) отсутствие средств для взаимной аутентификации агентов и менеджеров,
(2) работа через ненадежный протокол UDP.
В SNMPv2 и SNMPv3 сделана попытка укрепить защиту SNMP за счет использования современных криптографических методов.
Особенности спецификаций SNMPv3 (1999):
- Модульность архитектуры и спецификаций SNMPv3. Модульность (взаимная независимость подсистем, выполняющих разные функции) позволяет сочетать компоненты от разных поставщиков, производить постепенную модернизацию, что гарантирует живучесть SNMP.
- Масштабируемость. Поддерживаются конфигурации произвольного масштаба, стоимость системы управления пропорциональна размеру.
- Информационная безопасность. Предусматривается защита управляющих сообщений и разграничение доступа к управляющей информации.
Основные компоненты архитектуры SNMPv3.
SNMP-машина включает четыре компонента:
- диспетчер;
- подсистему обработки сообщений;
- подсистему безопасности;
- подсистему разграничения доступа.
Диспетчер занимается приемом и отправкой SNMP-сообщений.
Подсистема обработки сообщений поддерживает несколько моделей обработки.
Подсистема безопасности SNMPv3 занимается защитой управляющих сообщений и обеспечивает:
- контроль целостности сообщений;
- аутентификацию источника данных;
- шифрование/дешифрование, если это предусмотрено политикой безопасности.
Для контроля целостности и аутентификации источника предусматриваются хэш-функции, вычисляемые на основании алгоритмов MD5 и SHA.
Модель безопасности включает и понятие разграничения доступа к управляющей информации. Это означает выдачу каждому субъекту своего представления (view) данных, а также подмножества управляющей информации, задаваемой спецификациями MIB. Таким образом, субъекты видят только то, к чему имеют доступ.
Спецификации SNMPv3, в соответствии с концепцией модульности, рассчитаны на одновременную поддержку нескольких моделей безопасности и разграничения доступа.
В SNMPv3 предусмотрено пять стандартных управляющих сервисов:
- генерация команд;
- прием извещений;
- обработка команд;
- порождение извещений;
- доверенное перенаправление,
Иерархическое разграничение функций в SNMPv3:
- минимальный агент (поддерживаются обработка команд и порождение извещений);
- доверенный агент (поддерживается доверенное перенаправление);
- минимальный менеджер (генерация команд и прием извещений с возможностью управления из командной строки);
- менеджер среднего уровня или дуальный узел, поддерживающий приложения минимального агента и минимального менеджера;
- управляющая станция (менеджер верхнего уровня), поддерживающая приложения минимального менеджера и, возможно, другие средства, предназначенные для управления большим числом узлов.
Удаленный мониторинг (RMON)
SNMP имеет недостатки при управлении крупными корпоративными сетями: большой объем трафика, высокая нагрузка на станцию управления, данные предоставляются по каждому узлу в отдельности, возможно только локальное администрирование устройств.
С другой стороны, из описания объектов MIB понятно, что эта база не дает детальной статистики по характерным ошибкам кадров Ethernet, не отражается изменение характеристик во времени, что часто интересует сетевого администратора. Эти ограничения сняты в новом стандарте RMON.
RMON (Remote MONitoring MIB), был разработан для поддержки удаленного мониторинга и анализа протоколов в локальных сетях.
Содержит агрегированную информацию об устройстве, не требующую передачи по сети больших объемов данных. Дополнительные счетчики ошибок в пакетах, более гибкие средства анализа статистики, более сложные условия установления сигналов предупреждений о неисправностях. Т.О., «интеллектуальность» агентов RMON выше, чем агентов MIB-1,2. Это позволяет им выполнять часть работы по обработке информации об устройствах, которая раньше возлагалась на менеджеров.
В RMON сбор и обработка данных осуществляются удаленными зондами, что позволяет сократить трафик в сети и нагрузку на станцию управления.
RMON стратегия - установление типичной картины трафика и задание порогов для предупреждения об отклонении трафика в сети от стандартных шаблонов.
Для этого администратору требуется собрать данные о функционировании сети и определить пороговые значения.
.
Если пороги заданы слишком низкими, то администратор будет получать большое количество предупреждений; если же пороги установлены на высоком уровне, то он может пропустить накопление отрицательных тенденций в работе сети. Однако сеть не является статичной, поэтому картина трафика изменяется.
RMON-2 и RMON-1 логически дополняют друг друга: RMON-1 полезнее всего для выявления физических ошибок, сбора статистики по станциям, а RMON-2 для сбора статистики о картине трафика на сетевом и прикладном уровнях.
RMON является одним из объектов в наборе MIB, объединяя, в свою очередь, 200 объектов в составе 10 групп для сетей Ethernet и Token Ring.
Группы RMON для Ethernet | |
| Название | Описание |
| Statictics | Статистика по числу октетов и пакетов, об ошибках и размере пакетов. |
| History | Распределение переменных первой группы за определенный период через заданные интервалы. |
| Host | Информация о трафике по каждому хосту в сегменте. |
| Host TopN | Отсортированные данные по указанному числу хостов в порядке убывания. |
| Matrix | Статистика по диалогам между парами хостов, в том числе о величине трафика и количестве ошибок в обоих направлениях. |
| Filter | Определения шаблонов для сбора пакетов. |
| Packet Capture | Сбор заданного числа пакетов, отвечающих указанному шаблону. |
| Alarm | Пороги для счетчиков для сигнализации об изменениях в функционировании сети. |
| Event | Протоколирование событий и определение действий при их наступлении. |
Например, в группу Statictics входят, в числе прочих такие объекты как
- число событий, при которых пакеты были проигнорированы из-за недостатка ресурсов,
- общее число байтов, принятых из сети
- общее число полученных пакетов, включая ошибочные,
- общее число хороших пакетов, направленных по широковещательному адресу,
- общее число хороших пакетов, направленных по групповому адресу,
- общее число полученных пакетов с неверной контрольной суммой,
- общее число полученных (хороших и плохих) пакетов определенных размеров (<64 байт), от 65 до 128, от128 до 255, и т.д.) и др.
Группа Hystory основана на объектах группы Statistics, что позволяет строить временные ряды для этих объектов.
Таким образом, можно сначала получить с помощью агента RMON данные о встречающихся в сегменте типах ошибок, собрать (с помощью объектов групп Statistics и Hystory) зависимость интенсивности этих ошибок от времени. После анализа таких зависимостей можно делать выводы об источнике ошибок и наметить пути исправления.
Группы объектов RMON-2 позволяют проанализировать работу протоколов верхних уровней.
Группа Protocol Directory позволяет управляющему приложению узнать, какой протокол (или протоколы) реализует конкретный агент. Такая информация просто необходима, если приложение и агент написаны разными разработчиками.
Группа Address Translation устанавливает связь между адресами сетевого и физического уровней.
Группы Network-Layer Host, Network-Layer Matrix, Application-Layer Host и Application-Layer Matrix предназначены для сбора статистики о трафике хостов и пар хостов на сетевом и прикладном уровнях. На основании этой статистики администратор может установить, какие клиенты с какими серверами общаются, так что системы могут быть перераспределены между сегментами сети для оптимизации потоков трафика.
Группа User History Collection позволяет администратору самому настроить сбор статистики за определенный период времени по любому из имеющихся счетчиков, например для файлового сервера или соединения между маршрутизаторами
Группа Probe Configuration — удаленно конфигурировать зонд другого разработчика.
Группы RMON-2 | |
| Название | Описание |
| Protocol Directory | Список протоколов, мониторинг пакетов которых зонд может осуществлять. |
| Protocol Distribution | Статистика трафика для каждого протокола с информацией о распределении и тенденциях в использовании протоколов. |
| Address Mapping | Соответствие между адресами сетевого и MAC-уровней. |
| Network-Layer Host | Статистика трафика каждого хоста. |
| Network-Layer Matrix | Статистика трафика о диалогах между парами хостов. |
| Application-Layer Host | Статистика трафика каждого хоста по протоколам. |
| Application-Layer Host | Статистика трафика о диалогах между парами хостов по протоколам. |
| User History Collection | Периодические выборки для определенных пользователем переменных. |
| Probe Configuration | Удаленная конфигурация параметров зонда. |
Отличительной чертой стандарта RMON MIB является независимость от протокола сетевого уровня, в отличие от стандартов MIB-1 и MIB-2, ориентированных на протоколы TCP\IP. Поэтому он удобен для гетерогенных сред, использующих разные протоколы сетевого уровня.
Достоинства RMON очевидны. Администратор может видеть весь трафик в локальном сегменте независимо от его расположения. Зная картину трафика, администратор может выявить тенденции, узкие места и проблемные ситуации. Можно управлять сетью гораздо большего размера и количества управляемых устройств.