2.3.2 Агенти rmon

Новітнім додаванням до функціональних можливостей SNMP є специфікація RMON, яка забезпечує віддалене взаємодія з базою MIB.

Стандарт на RMON з'явився в листопаді 1991 року, коли Internet Engineering Task Force випустив документ RFC 1271 під назвою "Моніторинг мережі Моніторинг Management Information Base" ("Інформаційна база дистанційного моніторингу мереж"). Даний документ містив опис RMON для мереж Ethernet.

RMON - протокол моніторингу комп'ютерних мереж , розширення SNMP , в основі якого , як і в основі SNMP , лежить збір і аналіз інформації про характер інформації, що передається по мережі. Як і в SNMP , збір інформації здійснюється апаратно- програмними агентами , дані від яких надходять на комп'ютер , де встановлено додаток управління мережею. Відмінність RMON від свого попередника полягає, в першу чергу , в характері збираються інформації - якщо в SNMP ця інформація характеризує тільки події , що відбуваються на тому пристрої , де встановлений агент , то RMON вимагає , щоб одержувані дані характеризували трафік між мережевими пристроями.

До появи RMON протокол SNMP не міг використовуватися віддаленим чином , він допускав лише локальне управління пристроями. База RMON MIB володіє поліпшеним набором властивостей для віддаленого управління , оскільки містить агреговану інформацію про пристрій , що не вимагає передачі по мережі великих обсягів інформації. Об'єкти RMON MIB включають додаткові лічильники помилок в пакетах , гнучкіші засоби аналізу графічних трендів і статистики , більш потужні засоби фільтрації для захоплення і аналізу окремих пакетів , а також більш складні умови встановлення сигналів попередження . Агенти RMON MIB більш інтелектуальні порівняно з агентами MIB - я або MIB - II і виконують значну частину роботи з обробки інформації про пристрій , яку раніше виконували менеджери. Ці агенти можуть розташовуватися усередині різних комунікаційних пристроїв , а також бути виконані у вигляді окремих програмних модулів , що працюють на універсальних ПК і ноутбуках (прикладом може служити LANalyzerNovell ).

нтелект агентів RMON дозволяє їм виконувати прості дії з діагностики несправностей та попередження про можливі відмови - наприклад , в рамках технології RMON можна зібрати дані про нормальне функціонування мережі ( . Т. е виконати так званий аналіз за базовим ) , а потім виставляти попереджувальні сигнали, коли режим роботи мережі відхилиться від базового - це може свідетельсствовать , зокрема , про неповну справності обладнання . Зібравши воєдино інформацію, що отримується від агентів RMON , додаток управління може допомогти адміністратору мережі ( що знаходиться , наприклад , за тисячі кілометрів від аналізованого сегмента мережі ) локалізувати несправність і виробити оптимальний план дій для її усунення.

Збір інформації RMON здійснюється апаратно- програмними зондами , що підключаються безпосередньо до мережі . Щоб виконати завдання збору і первинного аналізу даних , зонд повинен мати достатні обчислювальними ресурсами і об'ємом оперативної пам'яті. В даний час на ринку є зонди трьох типів : вбудовані , зонди на базі комп'ютера , і автономні . Продукт вважається підтримуючим RMON , якщо в ньому реалізована хоча б одна група RMON . Зрозуміло , чим більше груп даних RMON реалізовано в даному продукті , тим він , з одного боку , дорожче , а з іншого - тим більш повну інформацію про роботу мережі він надає.

Вбудовані зонди являють собою модулі розширення для мережевих пристроїв. Такі модулі випускаються багатьма виробниками , зокрема , такими великими компаніями , як 3Com , Cabletron , Bay Networks і Cisco. (До речі , 3Com і Bay Networks нещодавно придбали компанії Axon і Армоні , визнаних лідерів в області розробки і виробництва засобів управління RMON . Такий інтерес до цієї технології з боку найбільших виробників мережевого устаткування зайвий раз показує , наскільки потрібним для користувачів є дистанційний моніторинг . ) Найбільш природним виглядає рішення вбудовувати модулі RMON в концентратори , адже саме з нагляду за цими пристроями можна скласти собі уявлення про роботу сегмента. Гідність таких зондів очевидно: вони дозволяють отримувати інформацію з усіх основних групах даних RMON при відносно невисокій ціні . Недоліком в першу чергу є не надто висока продуктивність , що проявляється, зокрема , в тому , що вбудовані зонди часто підтримують далеко не всі групи даних RMON . Не так давно 3Com оголосила про намір випустити підтримують RMON драйвери для мережевих адаптерів Etherlink III і Fast Ethernet. У результаті виявиться можливим збирати та аналізувати дані RMON безпосередньо на робочих станціях в мережі.

Зонди на базі комп'ютера - це просто підключення до мережі комп'ютери з встановленим на них програмним агентом RMON. Такі зонди (до числа яких належить, наприклад, продукт Cornerstone Agent 2.5 компанії Network General) володіють вищою продуктивністю, ніж вбудовані зонди, і підтримують, як правило, всі групи даних RMON. Вони більш дороги, ніж вбудовані зонди, але набагато дешевше автономних зондів. Крім цього, зонди на базі комп'ютера мають досить великий розмір, що може іноді обмежувати можливості їх застосування.

Автономні зонди володіють найвищою продуктивністю ; як легко зрозуміти , це одночасно і найбільш дорогі продукти з усіх описаних . Як правило , автономний зонд - це процесор ( класу i486 або RISC -процесор ) , оснащений достатнім обсягом оперативної пам'яті і мережним адаптером . Лідерами в цьому секторі ринку є компанії Frontier і Hewlett -Packard. Зонди цього типу невеликі за розміром і дуже мобільні - їх дуже легко підключати до мережі і відключати від неї. При вирішенні задачі управління мережею глобального масштабу це, звичайно , не дуже важлива властивість , однак якщо кошти RMON застосовуються для аналізу роботи корпоративної мережі середніх розмірів , то ( враховуючи високу вартість пристроїв ) мобільність зондів може зіграти дуже позитивну роль.

Об'єкту RMON привласнений номер 16 в наборі об'єктів MIB, а сам об'єкт RMON об'єднує у відповідності з документом RFC 1271, складається з десяти груп даних.

• Statistics - поточні накопичені статистичні дані про характеристики пакетів, кількості колізій тощо.

• History - статистичні дані, збережені через певні проміжки часу для подальшого аналізу тенденцій їх змін.

• Alarms - порогові значення статистичних показників , при перевищенні яких агент RMON посилає повідомлення менеджеру . Дозволяє користувачеві визначити ряд порогових рівнів (ці пороги можуть отнсіться до самих різних речей - будь-якому параметру з групи статистики , амплітуді або швидкості його зміни і багато чому іншому) , по перевищенні яких генерується аварійний сигнал. Користувач може також визначити , за яких умов перевищення порогового значення має супроводжуватися аварійним сигналом - це дозволить уникнути генерації сигналу " по дрібницях" , що погано , по-перше , тому, що на постійно палаючу червону лампочку ніхто не звертає уваги , а по-друге , тому, що передача непотрібних аварійних сигналів по мережі призводить до зайвої завантаженні ліній зв'язку. Аварійний сигнал , як правило , передається в групу подій , де і визначається , що з ним робити далі.

• Host - даних про хостахи мережі, в тому числі і про їх MAC-адресах..

• HostTopN - таблиця найбільш завантажених хостів мережі . Таблиця N головних хостів ( HostTopN ) містить список N перших хостів , що характеризуються максимальним значенням заданого статистичного параметра для заданого інтервалу. Наприклад , можна зажадати список 10 хостів , для яких спостерігалося максимальну кількість помилок протягом останніх 24 годин. Список цей буде складений самим агентом , а додаток управління отримає лише адреси цих хостів і значення відповідних статистичних параметрів . Видно , до якої міри такий підхід економить мережеві ресурси.

• TrafficMatrix - татистика про інтенсивність трафіку між кожною парою хостів мережі , впорядкована у вигляді матриці . Рядки цієї матриці пронумеровані відповідно до MAC -адресами станцій - джерел повідомлень , а стовпці - відповідно до адресами станцій - отримувачів . Матричні елементи характеризують інтенсивність трафіку між відповідними станціями і кількість помилок. Проаналізувавши таку матрицю , користувач легко може з'ясувати , які пари станцій генерують найбільш інтенсивний трафік. Ця матриця , знову-таки , формується самим агентом , тому відпадає необхідність у передачі великих обсягів даних на центральний комп'ютер , що відповідає за управління мережею.

• Filter - умови фільтрації пакетів. Ознаки, за якими фільтруються пакети , можуть бути найрізноманітнішими - наприклад , можна зажадати відфільтровувати як помилкові всі пакети , довжина яких виявляється менше деякого заданого значення . Можна сказати , що установка фільтра відповідає як би організації каналу для передачі пакета. Куди веде цей канал - визначає користувач . Наприклад , всі помилкові пакети можуть перехоплюватися і направлятися в соответсвующий буфер. Крім того , поява пакету , відповідного встановленому фільтру , може розглядатися як подія (події ), на яке система повинна реагувати заздалегідь обумовленим чином.

• PacketCapture - умови захоплення пакетів . До складу групи перехоплення пакетів ( захоплення пакетів ) входять буфера для захоплення , куди направляються пакети , чиї ознаки задовольняють умовам , сформульованим у групі фільтрів. При цьому захоплюватися може не пакет цілком , а , скажімо , тільки перші кілька десятків байт пакета. Вміст буферів перехоплення можна згодом аналізувати за допомогою різних програмних засобів , з'ясовуючи цілий ряд дуже корисних характеристик роботи мережі . Перебудовуючи фільтри на ті чи інші ознаки , можна характеризувати різні параметри роботи мережі.

• Event - умови реєстрації і генерації подій . У групі подій (подій) визначається , коли слід відправляти аварійний сигнал додатком управління, коли - перхвативать пакети , і взагалі - як реагувати на ті чи інші події , що відбуваються в мережі , наприклад , на перевищення заданих в групі тривоги порогових значень : чи слід ставити до відома додаток управління , або треба просто запротоколювати дана подія і продовжувати працювати. Події можуть і не бути пов'язані з предачі аварійних сигналів - наприклад , напрямок пакета в буфер перехоплення теж являє собою подію.

Дані групи пронумеровані у вказаному порядку, тому, наприклад, група Hosts має числове ім'я 1.3.6.1.2.1.16.4.

Десяту групу складають спеціальні об'єкти протоколу TokenRing.

Всього стандарт RMON MIB визначає близько 200 об'єктів у 10 групах, зафіксованих в двох документах - RFC 1271 для мереж Ethernet і RFC 1513 для мереж TokenRing.

Відмінною рисою стандарту RMON MIB є його незалежність від протоколу мережевого рівня (на відміну від стандартів MIB-я і MIB-II, орієнтованих на протоколи TCP / IP). Тому, його зручно використовувати в гетерогенних середовищах, що використовують різні протоколи мережевого рівня.