RMON (Remote Monitoring - удаленное наблюдение) - средство работы с оборудованием, предназначенным для выполнения сложных функций управления сетью. RMON - это протокол для сбора информации обо всей сети из единственного узла, применение которого позволяет отказаться от услуг специалиста, непосредственно наблюдающего за объектом, подозревающимся в неисправности, и анализирует сетевые даные. Хотя в обоих протоколах RMON и SNMP используются файлы MIB, это вовсе не одна и та же вещь. Оба они - средства управления сетями, но RMON обеспечивает поддержку расширенного набора файлов MIB, позволяющих собирать больше информации, чем SNMP.

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

Объекту RMON присвоен номер 16 в наборе объектов MIB, а сам объект RMON объединяет 10 групп следующих объектов.

Statistics

Текущие накопленные статистические данные о характеристиках пакетов, количестве коллизий и т. п.

Histoty

Статистические данные, сохраненные через определенные промежутки времени для последующего анализа тенденций их изменений.

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 MIB является его независимость от протокола сетевого уровня (в отличие от стандартов MIB-I и MIB-II, ориентированных на протоколы TCP/IP). Поэтому он удобен для гетерогенных сред, использующих различные протоколы сетевого уровня.

Рассмотрим более подробно группу Statistics, которая определяет, какую информацию о кадрах (называемых в стандарте пакетами) Ethernet может предоставить агент RMON. Группа History основана на объектах группы Statistics, так как ее объекты просто позволяют строить временные ряды для объектов группы Statistics. В группу Statistics входят наряду с некоторыми другими следующие объекты.

• etherStatsDropEvents — общее число событий, при которых пакеты были проигнорированы агентом из-за недостатка его ресурсов. Сами пакеты при этом не обязательно были потеряны интерфейсом.

• etherStatsOctets — общее число байт (включая ошибочные пакеты), принятых из сети (исключая преамбулу н включая байты контрольной суммы).

• etherStatsPkts — общее число полученных пакетов (включая ошибочные).

• etherStatsBroadcastPkts — общее число хороших пакетов, которые были посланы по широковещательному адресу.

• etherStatsMulticastPkts — общее число хороших пакетов, полученных по мультивещательному адресу.

• etherStatsCRCAlignErrors — общее число полученных пакетов, которые имели длину (исключая преамбулу) между 64 и 1518 байт, не содержали целое число байт (alignment error) или имели неверную контрольную сумму (FCS error).

• etherStatsUndersizePkts — общее число пакетов, которые имели длину меньше, чем 64 байт, но были правильно сформированы.

• etherStatsOversizePkts — общее число полученных пакетов, которые имели длину больше, чем 1518 байт, но были тем не менее правильно сформированы.

• etherStatsFragments — общее число полученных пакетов, которые не состояли из целого числа байт или имели неверную контрольную сумму и имели к тому же длину, меньшую 64 байт.

• etherStatsJabbers — общее число полученных пакетов, которые не состояли из целого числа байт или имели неверную контрольную сумму и имели к тому же длину, большую 1518 байт.

• etherStatsCollisions — наилучшая оценка числа коллизий на данном сегменте Ethernet.

• etherStatsPkts640ctets — общее количество полученных пакетов (включая плохие) размером 64 байт.

• etherStatsPkts65tol270ctets — общее количество полученных пакетов (включая плохие) размером от 65 до 127 байт.

• etherStatsPktsl28to2550ctets — общее количество полученных пакетов (включая плохие) размером от 128 до 255 байт.

• etherStatsPkts256to5110ctets — общее количество полученных пакетов (включая плохие) размером от 256 до 511 байт.

• etherStatsPkts512tol0230ctets — общее количество полученных пакетов (включая плохие) размером от 512 до 1023 байт.

• etherStatsPktsl024tol5180ctets — общее количество полученных пакетов (включая плохие) размером от 1024 до 1518 байт.

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

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