Агенти RMON

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

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

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

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

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



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

Вбудовані зонди являють собою модулі розширення для мережевих пристроїв. Такі модулі випускаються багатьма виробниками, зокрема, такими великими компаніями, як 3Com, Cabletron, Bay Networks і Cisco. (До речі, 3Com і Bay Networks нещодавно придбали компанії Axon і ARMON, визнаних лідерів в області розробки і виробництва засобів управління 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 - умови фільтрації пакетів. Ознаки, за якими фільтруються пакети, можуть бути найрізноманітнішими - наприклад, можна зажадати відфільтровувати всі помилкові пакети, довжина яких виявляється менше деякого заданого значення. Можна сказати, що установка фільтра відповідає як би організації каналу для передачі пакета. Куди веде цей канал - визначає користувач. Наприклад, всі помилкові пакети можуть перехоплюватися і направлятися в відповідний буфер. Крім того, поява пакету, відповідаючого встановленому фільтру, може розглядатися як подія (event), на яку система повинна реагувати заздалегідь обумовленим чином.

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

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

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

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

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

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



5656515137810615.html
5656584870520885.html
    PR.RU™