Специфікація RMON MIB

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 на протоколи верхніх рівнів, виконуючи частину роботи аналізаторів протоколів.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Керуюча база даних MIB	\|	Проблеми безпеки протоколу SNMP v1/2

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.005 сек.