Засоби моніторингу та аналізу мережі

Класифікація засобів моніторингу та аналізу

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

Процес контролю роботи мережі зазвичай ділять на два етапи - моніторинг і аналіз.

На етапі моніторингу виконується більш проста процедура - процедура збору первинних даних про роботу мережі: статистики про кількість циркулюючих в мережі кадрів і пакетів різних протоколів, стан портів концентраторів, комутаторів і маршрутизаторів і т. п.

Далі виконується етап аналізу, під яким розуміється більш складний і інтелектуальний процес осмислення зібраної на етапі моніторингу інформації, зіставлення її з даними, отриманими раніше, і вироблення припущень про можливі причини сповільненої або ненадійної роботи мережі.

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

Всі засоби моніторингу та аналізу мереж, можна розділити на кілька великих класів:

• Системи управління мережею (Network Management Systems) - централізовані програмні системи, які збирають дані про стан вузлів і комунікаційних пристроїв мережі, а також дані про трафік в мережі. Ці системи не тільки здійснюють моніторинг і аналіз, а й виконують в автоматичному чи напівавтоматичному режимі управління мережею - включення і відключення портів пристроїв, зміна параметрів мостів адресних таблиць мостів, комутаторів і маршрутизаторів і т.п. Прикладами систем управління можуть служити популярні системи HPOpenView, SunNetManager, IBMNetView.

• Засоби управління системою (System Management). Засоби управління системою часто виконують функції, аналогічні функціям систем управління, але стосовно інших об'єктів. У першому випадку об'єктом управління є програмне і апаратне забезпечення комп'ютерів мережі, а у другому - комунікаційне устаткування. Разом з тим, деякі функції цих двох видів систем управління можуть дублюватися, наприклад, засоби управління системою можуть виконувати найпростіший аналіз мережевого трафіку.До найбільш відомих систем управління системами відносяться LANDesk, IBM Tivoli, Microsoft Systems Management Server, HP OpenView, Novell ZENworks і CA Unicenter.

• Вбудовані системи діагностики і управління (Embedded Systems). Ці системи виконуються у вигляді програмно-апаратних модулів, які встановлюються в комунікаційне обладнання, а також у вигляді програмних модулів, вбудованих в операційні системи. Вони виконують функції діагностики і управління тільки одним пристроєм, і в цьому їх основна відмінність від централізованих систем управління. Прикладом засобів цього класу може служити модуль управління концентратором Distrebuted 5000, реалізує функції автосигментацієї портів при виявленні несправностей, приписування портів внутрішнім сегментам концентратора і деякі інші. Як правило, вбудовані модулі управління також виконують роль SNMP-агентів, які поставляють дані про стан пристрою системам управління.

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

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

• Експертні системи. Цей вид систем акумулює людські знання про виявлення причин аномальної роботи мереж і можливі способи приведення мережі у працездатний стан. Експертні системи часто реалізуються у вигляді окремих підсистем різних засобів моніторингу та аналізу мереж: систем управління мережами, аналізаторів протоколів, мережевих аналізаторів. Найпростішим варіантом експертної системи є контекстно-залежна help-система. Більш складні експертні системи являють собою так звані бази знань, що володіють елементами штучного інтелекту. Прикладом такої системи є експертна система, вбудована в систему управління Spectrum компанії Cabletron.

• Багатофункціональні пристрої аналізу та діагностики. У зв'язку з розповсюдженням локальних мереж виникла необхідність розробки недорогих портативних приладів, які суміщають функції декількох пристроїв: аналізаторів протоколів, кабельних сканерів і, навіть, деяких можливостей ПЗ мережного управління. Як приклад такого роду пристроїв можна привести Compas компанії MicrotestInc. або 675 LANMeterкомпаніі FlukeCorp.

Системи управління

Відповідно до рекомендацій ISO можна виділити такі функцій засобів управління мережею:

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

• Обробка помилок - це виявлення і усунення наслідків збоїв у роботі мережі.

• Аналіз продуктивності - допомагає на основі накопиченої статистичної інформації оцінювати час відповіді системи і величину трафіка, а також планувати розвиток мережі.

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

• Облік роботи мережі - включає реєстрацію і управління використовуваними ресурсами і пристроями. Ця функція оперує такими поняттями як час використання і плата за ресурси.

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

Засоби управління мережею (NetworkManagement), не слід плутати із засобами управління комп'ютерами та їх операційними системами (SystemManagement). Типовими представниками засобів управління мережами є системи HPOpenView, SunNetManager і IBMNetView.

Засоби управління системою зазвичай виконують такі функції:

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

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

• Віддалений аналіз продуктивності і виникаючих проблем. Адміністратор може віддалено управляти ресурсами будь-якого ПК, що працює в мережі. База даних системи управління зберігає детальну інформацію про конфігурацію всіх комп'ютерів в мережі для того, щоб можна було виконувати віддалений аналіз виникаючих проблем.

Прикладами засобів управління системою є такі продукти, як SystemManagementServer компанії Microsoft або LANDeskManager фірми Intel.

Останнім часом в області систем управління спостерігаються дві досить чітко виражені тенденції:

• інтеграція в одному продукті функцій управління мережами і системами;
• розподіленість системи управління, при якій в системі існує кілька консолей, які збирають інформацію про стан пристроїв і систем та видають керуючі дії.

Стандарти управління мережою

Організація	Стандарти	Особливості
IETF	SNMP	Управління має бути простим, орієнтоване на змінні
ISO	CMIP, CMIS	Управління має бути потужним, об'єктно-орієнтованим
ITU-T	TMN	Визначена тільки архітектура
DMTF	WBEM, CIM	Управління мережами і системами, об'єктно-орієнтоване
OMG	CORBA	Архітектура віддалених об'єктів

Нині найуспішнішим сімейством стандартів є SNMP. Він лідирує за кількістю керованих систем (агентів). Керуючі системи (менеджери) зазвичай підтримують безліч стандартів, тому тут складно говорити про лідерство SNMP. За кількістю вкладених грошей, можливо, лідирує Telecommunications Management Network (TMN).

Показово простежити залежність популярності стандартів від середовища їх застосування. У локальних і глобальних мережах передачі даних, що використовують Протокол інтернету (Internet Protocol, IP) найбільш широко розповсюджений стандарт SNMP. У системах відомчих автоматичних телефонних станцій (ВАТС) та в публічних телефонних мережах найбільш часто використовуються пропрієтарні рішення. У мобільних мережах в основному використовуються рішення на основі стандартів ISO.

Майже всі успіхи SNMP пов'язані з особливостями процесу стандартизації в IETF:

• Стандарти безкоштовні і вільно розповсюджувані;

• Стандарти легко доступні в електронній формі;

• Швидкий розвиток стандартів, продумані етапи стандартизації;

• На всіх етапах ведеться технічна експертиза;

• Робочі групи очолюють технічні, а не політичні лідери;

• Прототипи систем на основі стандартів демонструють їх придатність;

Протокол SNMP

Створення систем управління мережами неможливе без орієнтації на певні стандарти, тому що управляюче програмне забезпечення та мережеве обладнання розробляють сотні компаній. Оскільки корпоративна мережа напевно неоднорідна, керуючі інструменти не можуть відображати специфіки однієї системи або мережі. Найбільш поширеним протоколом управління мережами є протокол SNMP (SimpleNetworkManagementProtocol), його підтримують сотні виробників. Головні переваги протоколу SNMP - простота, доступність, незалежність від виробників. Значною мірою саме популярність SNMP затримала прийняття CMIP, варіанта керуючого протоколу за версією OSI. Протокол SNMP розроблений для управління маршрутизаторами в мережі Internet і є частиною стека TCP/IP.

У системах управління, побудованих на основі протоколу SNMP, стандартизуються наступні елементи:

• протокол взаємодії агента і менеджера;

• мова опису моделей MIВ та повідомлень SNMP - мова абстрактної синтаксичної нотації ASN.1 (стандарт ISO 8824:1987, рекомендації ITU-T X.208);

• кілька конкретних моделей MIB (MIB-I, MIB-II, RMON, RMON 2), імена об'єктів яких реєструються в дереві стандартів ISO. Все інше віддається на розсуд розробника системи управління. Протокол SNMP і тісно пов'язана з ним концепція SNMP MIB були розроблені для управління маршрутизаторами Internet як тимчасове рішення. Але, як це часто буває з усім тимчасовим, простота і ефективність вирішення забезпечили успіх цього протоколу, і сьогодні він використовується при управлінні практично будь-якими видами обладнання і програмного забезпечення обчислювальних мереж. І хоча в області управління телекомунікаційними мережами спостерігається стійка тенденція застосування стандартів ITU-T, в які входить протокол CMIP, і тут є досить багато прикладів успішного використання SNMP-управління. Агенти SNMP вбудовуються в аналогові модеми, модеми ADSL, комутатори АТМ і т. д.

SNMP - це протокол, що використовується для отримання від мережевих пристроїв інформації про їх статус, продуктивність та характеристики, які зберігаються в спеціальній базі даних мережевих пристроїв, що називається MIB (ManagementInformationBase). Існують стандарти, що визначають структуру MIB, в тому числі набір типів її змінних (об'єктів в термінології ISO), їх імена і допустимі операції цими змінними (наприклад, читати). У MIB, поряд з іншою інформацією, можуть зберігатися мережеві та / або MAC-адреси пристроїв, значення лічильників оброблених пакетів і помилок, номери, пріоритети та інформація про стан портів. Деревоподібна структура MIB містить обов'язкові (стандартні) піддерева, а також в ній можуть знаходитися приватні (private) піддерева, що дозволяють виробнику інтелектуальних пристроїв реалізувати будь-які специфічні функції на основі його специфічних змінних.

Агент в протоколі SNMP - це елемент, який надає менеджерам, розміщеним на керуючих станціях мережі, доступ до значень змінних MIB, і тим самим дає їм можливість реалізовувати функції з управління та спостереження за пристроєм. Типова структура системи управління зображена на наступному малюнку:

Стандарти управління OSI

Загальні відомості. Концепція SMAE

Модель мережевого управління OSI - OSI Management Framework - визначена в документі ISO / IEC 7498-4: Basic Reference Model, Part 4, Management Framework.

Документ ISO / IEC 7498-4 складається з наступних основних розділів:

• Терміни та загальні концепції.

• Модель управління системами.

• Інформаційна модель.

• Функціональні області управління системами.

• Структура стандартів управління системами.

Функціональні області управління системами вже були розглянуті вище.

Стандарти ISO в галузі управління використовує термінологію, яка частково збігається з термінологією систем управління SNMP.

Як показано на малюнку, обмін керуючою інформацією з використанням протоколу управління (Management Protocol) відбувається між суб'єктами програм управління системами (Systems Management Application Entities, SMAE):

Суб'єкти SMAE розташовані на прикладному рівні семирівневої моделі OSI і є елементами служби управління. Під суб'єктом в моделі OSI розуміється активний в даний момент елемент протоколу будь-якого рівня, який бере участь у взаємодії. Прикладами SMAE є агенти та менеджери систем управління.

Агенти та менеджери

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

Наприклад, якщо деякий елемент мережі Х відмовив, то менеджеру необхідно оновити свою базу даних конфігурації мережі. Елемент X, який є для системи управління керованим об'єктом (managed object), може послати повідомлення агенту. Елемент Х може знаходитися в тій же керованої системі, що і агент, або може перебувати в іншій системі. У свою чергу агент надсилає повідомлення менеджеру про те, що елемент Х відмовив. Відповідно до цього повідомленням менеджер оновлює базу даних конфігурації.

ПРИМІТКА. У стандартах Internet під об'єктом розуміється окремий атрибут бази МIВ, що є моделлю керованого ресурсу, а в стандартах ISO об'єкт позначає всю модель керованого ресурсу.

Менеджер не тільки збирає і порівнює дані, одержувані від агентів, на основі цих даних він може також виконувати адміністративні функції, керуючи операціями віддалених агентів.

У стандартах OSI різниця між менеджерами та агентами не дуже чітка. Суб'єкт SMAE, що виконує в одній взаємодії роль менеджера, може в іншій взаємодії виконувати роль агента, і навпаки.Стандарти OSI не визначають способів взаємодії агента з керованими об'єктами. Стандарти OSI також не говорять про те, як агент взаємодіє з керованими об'єктами, які перебувають за межами керованої системи, тобто об'єктами, з якими потрібно взаємодіяти через мережу. У таких випадках може знадобитися, наприклад, щоб один агент запросив дані про деякий об'єкт від іншого агента. Порядок такого роду взаємодії також не визначається стандартами OSI.

Щоб менеджер і агент змогли взаємодіяти, кожен повинен мати певні відомості про один одного. Ці відомості модель OSI називає контекстом додатку (Application Context, AC). AC описує елементи прикладного рівня стека OSI, які використовуються агентами і менеджерами.

ПРИМІТКА. Необхідно зазначити, що стандарти управління OSI значною мірою орієнтовані на стек протоколів OSI (саме стек, а не модель OSI), так само як системи управління SNMP орієнтовані на роботу зі стеком TCP / IP.

Прикладний рівень стека OSI включає кілька допоміжних служб загального призначення, які використовуються прикладними протоколами і клієнтськими програмами (в тому числі і додатками управління) для автоматизації найбільш часто виконуваних дій. Це не закінчені протоколи прикладного рівня, подібні протоколах ftp, telnet або NCP, за допомогою яких користувач мережі може виконати якусь корисну дію, а допоміжні системні функції, які допомагають розробнику прикладного протоколу або програми написати її компактно і ефективно. На прикладному рівні стека OSI існують наступні допоміжних служби:

• ACSE (Association Control Service Element). Відповідає за встановлення з'єднань між додатками різних систем. З'єднання (сесія, сеанс) на прикладному рівні OSI носить назву асоціації. Асоціації бувають індивідуальними та груповими (shared).

• RTSE (Reliable Transfer Service Element). Займається підтримкою відновлення діалогу, викликаного розривом нижележащих комунікаційних служб, в рамках асоціації.

• ROSE (Remote Operations Service Element). Організовує виконання програмних функцій на віддалених машинах (аналог служби виклику віддалених процедур RPC).

Управління системами, управління рівнем та операції рівня

Основна модель управління OSI включає: управління системами, управління N-рівнем і операції N-рівня. Це розбиття на три області зроблено для того, щоб врахувати всі можливі ситуації, що виникають при управлінні.

Управління системами має справу з керованими об'єктами на всіх семи рівнях OSI, включаючи прикладний рівень. Воно засноване на надійній передачі з встановленням з'єднання керуючої інформації між кінцевими системами. Необхідно підкреслити, що модель управління OSI не дозволяє використання служб без встановлення з'єднання.

Управління N-рівнем обмежено керованими об'єктами якогось певного рівня семирівневої моделі. Протокол управління використовує при цьому комунікаційні протоколи нижчих рівнів. Управління N-рівнем корисно, коли немає можливості використовувати всі семи рівнів OSI. У цьому випадку допускається користуватися протоколом управління N-рівня, який строго призначений для даного рівня. Прикладами рівневого протоколу управління є протоколи управління для локальних мереж, розроблені інститутом IEEE (SMT технології FDDI), які обмежені рівнями 1 і 2.

Нарешті, операції N-рівня зводяться до моніторингу та управління на основі керуючої інформації, що міститься в комунікаційних протоколах тільки даного рівня. Наприклад, дані моніторингу мережі, що містяться в кадрах STM-n технології SDH, відносяться до операцій N-рівня, а саме фізичного рівня. Стандарти на управління N-рівнем і операції N-рівня не входять в набір стандартів управління OSI. Стандарти OSI розглядають лише управління системами за допомогою повного семирівневого стека.

Основна модель управління системами передбачає виконання керуючих операцій і передачу повідомлень між одноранговими системами, що означає необов'язковість жорсткого розподілу ролей на керуючі та керовані системи. Ця модель полегшує реалізацію розподілених аспектів управління. З іншого боку, допускається реалізація однорангових систем як керуючих і керованих.

Інформаційна модель управління

Керований об'єкт - це представлення OSI про ресурс з метою управління. Ресурс може бути описаний як керований об'єкт. Конкретний керований об'єкт - це екземпляр (instance) деякого класу керованих об'єктів. Модель управління OSI широко використовує об'єктно-орієнтований підхід. Клас керованих об'єктів - це набір властивостей, які можуть бути обов'язковими або умовними. За допомогою опису одного класу керованих об'єктів, наприклад комутаторів, можна створити інший клас керованих об'єктів, наприклад комутаторів, що підтримують техніку VLAN, успадкувавши всі властивості класу комутаторів, але додавши нові атрибути.

Для управління ресурсами менеджер і агент повинні бути обізнані про деталі цих ресурсів. Деталізація представлення керованих об'єктів, які потрібні для виконання функцій управління, зберігається в репозиторії, відомому як Management Information Base (MIB). Бази MIB OSI зберігають не тільки описи класів керованих об'єктів, але й характеристики мережі та її елементів. Бази MIB містять характеристики кожної частини керованого обладнання і ресурсів. MIB також включає опис дій, які можуть виконуватися на основі зібраних даних або ж викликані зовнішніми командами. Бази MIB дозволяють зовнішнім системам опитувати, змінювати, створювати і видаляти керовані об'єкти (реальні ресурси мережі при цьому, природно, продовжують працювати). Протокол CMIP і локальні інтерфейси управління забезпечують доступ до цих можливостей.

MIB - це концептуальна модель, і вона не має ніякого зв'язку зі способом фізичного або логічного зберігання даних в ресурсі. Стандарти не визначають аспекти власне зберігання даних. Протоколи OSI визначають синтаксис інформації, що зберігається в MIB, і семантику обміну даними.

Протокол CMIP та послуги CMIS

Доступ до керуючої інформації, що зберігається в керованих об'єктах, забезпечується за допомогою елемента системи управління, званого службою CMSIE (Common Management Information Service Element). Служба CMSIE побудована в архітектурі розподіленого додатку, де частину функцій виконує менеджер, а частина - агент. Взаємодія між менеджером і агентом здійснюється по протоколу CMIP. Послуги, що надаються службою CMSIE, називаються послугами CMIS (Common Management Information Services).

Протокол CMIP та послуги CMIS визначені в стандартах Х.710 і Х.711 ITU-T. Послуги CMIS поділяються на дві групи - послуги, що ініціюються менеджером (запити), та послуги, що ініціюються агентом (повідомлення).

Послуги, що ініціюються менеджером, включають наступні операції:

• M-CREATE інструктує агента про необхідність створити новий екземпляр об'єкту певного класу або новий атрибут усередині екземпляра об'єкта;

• M-DELETE інструктує агента про необхідність видалення деякого екземпляра об'єкту певного класу або атрибуту усередині екземпляра об'єкта;

• M-GET інструктує агента про повернення значення деякого атрибуту певного екземпляра об'єкту;

• M-SET інструктує агента про зміну значення деякого атрибуту певного екземпляра об'єкту;

• M-ACTION інструктує агента про необхідність виконання певної дії над одним або кількома примірниками об'єктів.

Агент ініціює тільки одну операцію: M-EVENT_REPORT - відправка повідомлення менеджеру.

Для реалізації своїх послуг служба CMISE повинна використовувати служби прикладного рівня стека OSI - ACSE, ROSE.

Відмінність послуг CMIS від аналогічних послуг SNMP полягає в більшій гнучкості. Якщо запити GET і SET протоколу SNMP застосовні тільки до одного атрибуту одного об'єкта, то запити M-GET, M-SET, M-ACTION і M-DELETE можуть застосовуватися до більш ніж одного об'єкту. Для цього стандарти CMIP / CMIS вводять такі поняття, як огляд (scoping), фільтрація (filtering) і синхронізація (synchronization).

Основні характеристики протоколу CMIP

CMIP реалізує весь набір послуг CMIS . За допомогою цих послуг протокол CMIP підтримує наступну послугу віддалених операцій:

• Запит ( invoke ) ;
• Повернення результату ;
• Повернення помилки ;
• Відхилення запиту користувачем послуги ;
• Відхилення запиту провайдером послуги .

Керуюча інформація від менеджера до агента , що передається по протоколу CMIP кодується відповідно до правил ASN.1 і BER . Для кожної операції визначено формат блоку даних , які переносяться по мережі від менеджера агенту , і навпаки. Формат протокольних блоків даних CMIP описується нотацією ASN.1 і має набагато складнішу структуру , ніж блоки SNMP. Наприклад , блок даних операції M- GET має поля для завдання імен атрибутів , значення яких запрошувати менеджер , а також поля завдання параметрів огляду і фільтрації. Є також поля для завдання параметрів прав доступу до об'єкта. Застосування протоколу CMIP визначає досить високий початковий рівень складності системи управління , так як для його роботи необхідно реалізувати ряд допоміжних служб , об'єктів і баз даних об'єктів . Сповіщення агента CMIP завжди передаються за допомогою надійного транспортного протоколу і в разі втрати будуть передані повторно . Протокол CMIP розрахований на агентів , які можуть з однієї простої команді від менеджера виконати складну послідовність дій . Протокол CMIP істотно краще масштабується , так як може впливати відразу на декілька об'єктів , а відповіді від агентів проходять через фільтри , які обмежують передачу керуючої інформації тільки певним агентам і менеджерам . Протокол CMIP , який є протоколом взаємодії між агентами і менеджерами системи управління OSI , дозволяє за допомогою однієї команди впливати відразу на групу агентів , застосувавши такі опції, як огляд і фільтрація . MIB для протоколу CMIP не мають єдиного стандарту і розробляються кожним виробником телекомунікаційного обладнання тільки для свого власного обладнання . Виняток становить тільки стандарт на MIB з систем передачі G.722 , G.774 .

Content Management Interoperability Services ( CMIS , сервіси взаємодії при управлінні контентом) - пропонований провідними виробниками пакет стандартів , що складається з набору веб -сервісів для спільного використання інформації, що зберігається в незв'язаних між собою сховищах контенту [ 1 ] .

Даний набір стандартів призначений для забезпечення стандартизованих можливостей взаємодії користувачів і додатків , які разом використовують різні сховища контента. Першу технічну специфікацію для веб -сервісів для обміну контентом між ЄСМ -системами підготували спільно фахівці EMC , IBM , Microsoft , Alfresco , Open Text (англ.) , SAP , Day Software (англ. ) і Oracle і подали заявку на стандартизацію в OASIS . Заявка опублікована у відкритому доступі для публічного обговорення [ 2 ] [ 3 ] . Змістовно , CMIS - це набір технічних специфікацій моделі предметної області для взаємодії з репозиторіями ECM -систем за допомогою веб- служб. CMIS містить предметно- орієнтовану модель даних управління контентом , набір базових сервісів, що працюють з моделлю даних і підтримку протоколів взаємодії цих сервісів , включаючи : SOAP і REST / Atom.

Переваги CMIS

Специфікація CMIS містить опис інтерфейсу для веб -сервісів , який :

• розроблений для роботи з існуючими сховищами , дозволяючи користувачам створювати і вдосконалювати додатки, що підтримують одночасну роботу з безліччю сховищ - роблячи доступним контент , який вони вже мають
• відокремлює веб -сервіси та контент від сховища контента , дозволяючи користувачам керувати контентом незалежно
• забезпечує базові веб -сервіси і інтерфейс Web 2.0 , що відчутно спрощує розробку додатків
• є платформою розробки , яка не залежить від мови програмування
• підтримує розробку композитних додатків і мешап ( mash - up ) бізнес-або ІТ- аналітиками
• забезпечує зростання співтовариства незалежних розробників програмного забезпечення

Порівняння протоколів SNMP та CMIP

• Застосування протоколу SNMP дозволяє будувати як прості, так і складні системи управління, а застосування протоколу CMIP визначає деякий, досить високий початковий рівень складності системи управління, так як для його роботи необхідно реалізувати ряд допоміжних служб, об'єктів і баз даних об'єктів.

• Агенти CMIP виконують, як правило, більш складні функції, ніж агенти SNMP. Через це операції, які менеджеру можна виконати над агентом SNMP, носять атомарний характер, що призводить до численних обмінів між менеджером і агентом.

• Повідомлення (traps) агента SNMP надсилаються менеджеру без очікування підтвердження, що може привести до того, що важливі мережеві проблеми залишаться непоміченими, оскільки відповідне повідомлення виявиться втраченим, у той час як повідомлення агента CMIP завжди передаються за допомогою надійного транспортного протоколу і в разі втрати будуть передані повторно.

• Вирішення частини проблем SNMP може бути досягнуто за рахунок застосування більш інтелектуальних MIB (до яких відноситься RMON MIB), але для багатьох пристроїв і ситуацій таких MIB немає (або немає стандарту, або немає відповідної MIB в керованому обладнанні).

• Протокол CMIP розрахований на інтелектуальних агентів, які можуть по одній простій команді від менеджера виконати складну послідовність дій.

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

Вбудовані засоби моніторингу і аналізу мереж

Агенти SNMP

Реалізація агентів SNMP для управління мережами зв'язку

Останнім часом з жорсткістю вимог до керованості телекомунікаційних мереж перед російськими операторами зв'язку все гостріше постає питання віддаленого контролю та моніторингу комутаційного і периферійного обладнання. У цих умовах вибір системи управління стає нетривіальним завданням.

Існують готові комплекси управління та візуалізації контролю за технологічними процесами, такі, як SCADA - система Trace Mode фірми AdAstra Research Group, проте вони можуть виявитися не по кишені вітчизняним постачальникам послуг зв'язку. Тому часто постає питання: купувати систему управління або краще розробити її самим?

Далі буде розглядатися реалізація декількох фрагментів системи управління телекомунікаційним обладнанням на базі протоколу SNMP. Спочатку цей протокол розроблявся для управління обчислювальними мережами, проте завдяки своїй гнучкості і все більш широкому розповсюдженню він може бути з успіхом застосований як базовий протокол управління телекомунікаційними мережами.

Особливо вагомим буде виграш при використанні SNMP-рішень для малих і середніх компаній. Важливим їх перевагою є той факт, що основні компанії - виробники комунікаційного та периферійного обладнання - Cisco, Hewllet-Packard, 3Com, APC та ін - вважають за необхідне підтримувати протокол SNMP в своїх продуктах. В результаті забезпечується простота інтеграції в телекомунікаційну систему нового обладнання з підключенням його до існуючих засобів моніторингу.

Трохи про технології

Ядро протоколу SNMP, розроблене в центрі "Моторола - Мікропроцесорні системи" Московського державного інженерно-фізичного інституту (МІФІ), призначене для реалізації SNMP - агентів (у тому числі проксі-агентів) для конкретних цілей. Рішення на базі SNMP дозволяють оперативно контролювати різні параметри віддалених об'єктів і при необхідності проводити їх конфігурування.

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

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

Реалізація проксі-агента SNMP на базі персонального комп'ютера

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

Структура SNMP - агента уніфікована з метою використання на різних об'єктах мережі зв'язку. Вона складається з проксі-агента з підключеними промисловими контролерами , які виконують функції збору стану контактних датчиків. В якості проксі-агента використовувався ПК з процесором 486DX, ОЗУ об'ємом 12 Мбайт, дисковим накопичувачем об'ємом 200 Мбайт і мережним адаптером Ethernet.

Збір інформації про стан контактних датчиків виробляють контролери типу ADAM - 4053 фірми Advantech. Контролери мають 16 клем для під'єднання до контактних датчикам зовнішнього обладнання і передають дані про їх стан за допомогою інтерфейсу RS-485. Вони можуть розташовуватися на відстані до 1 км від комп'ютера і підключаються до його шині за допомогою ISA-адаптера Advantech типу PCL-488, який має два порти RS-485/422.

Програма Agent, розроблена для операційної системи MS Windows NT 4.0 Workstation, періодично зчитує дані від контролерів контактних датчиків, оповіщає програму - менеджер про зміни їх стану, забезпечує відповіді на запити менеджера. Додаткова програма - конфігуратор - Agent_Setup робить налаштування агента на канали зв'язку з менеджером, настройку фізичного інтерфейсу для зв'язку з контролерами стану контактних датчиків і ряд інших функцій. Конфігурація зберігається у файлі Agent.ini. Зв'язок SNMP-менеджера і SNMP - агента здійснюється або по мережі Ethernet (станція -агент містить Ethernet-адаптер), або по телефонній лінії (за допомогою модему), або по інтерфейсу RS-232 (нуль-модемне з'єднання через COM-порт).

Програмне забезпечення станції - агента реалізовано на мові Сі++ з використанням наступних можливостей операційної системи Windows NT 4.0 Workstation : програмний інтерфейс Win32; реалізація протоколів TCP/IP, PPP; функції дозвону за допомогою модему. Для коректної роботи програми - агента в операційній системі повинен бути модуль comctl32.dll версії 4.71. Установка на комп'ютері браузера MS Internet Explorer версії 4.0 (або пізнішої) гарантує його наявність.

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

В даний час ряд компаній-операторів для прискорення розробки і зниження вартості систем використовують на своїх технологічних серверах відкриту операційну систему Linux. Враховуючи перспективу широкого застосування ОС Linux у системах зв'язку і управління, ми розробили версію проксі-агента для цієї операційної системи. Вона орієнтована на дистрибутив Linux RedHat 6.0 і поставляється у вигляді rpm-файлів. Версія для Linux виконує функції SNMP - агента відповідно до SNMPv1 і частково з SNMPv2 і має декілька каналів збору інформації.

У порівнянні з описаною вище системою контролю на базі ОС Windows NT дана система забезпечує наступні додаткові можливості:

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

Реалізація SNMP - агента на базі комунікаційного процесора MC68360

Фірмою Motorola випускається досить широка номенклатура комунікаційних контролерів: MC68302, MC68356, MC68360, MPC860. Розглянута нижче система управління маршрутизатором реалізована на базі контролера MC68EN360, який призначений для використання в цифрових телекомунікаційних мережах.

Управління маршрутизатором проводиться SNMP - менеджером, встановленим на станції управління. В якості SNMP - агента використовувався комунікаційний модуль, реалізований на базі контролера MC68EN360. До нього за допомогою інтерфейсу RS- 232 підключається персональний комп'ютер, який використовується в якості консолі для конфігурації термінального обладнання - маршрутизатора. У системі реалізована архітектура мережі управління SNMPv1 і частково SNMPv2. SNMP - менеджер періодично опитує SNMP - агенти про стан контрольованого устаткування і представляє отримані дані в зручному для оператора вигляді. SNMP - агенти забезпечують прийом інформації з маршрутизатора, відповіді на запити SNMP-менеджера і оповіщення про надзвичайні ситуації. На комунікаційному модулі, виконує функції SNMP - агента, встановлені операційне ядро реального часу RTEMS 4.0.0 (Real Time Executive for Multiprocessor Systems) і модуль BSP (Board Support Package), що забезпечує зв'язок з апаратурою. У завдання останнього входять ініціалізація модуля і запуск системи, реалізація системних годин для планувальника завдань, підключення драйверів.

У SNMP - агента використано ядро RTEMS, написаний на мові Сі для 32-розрядних процесорів, на базі яких реалізовані контролери MC68EN360. Ядро скомпільовано за допомогою компілятора GCC 2.8.1 в середовищі операційної системи Linux Redhat 5.2, встановленої на персональному комп'ютері. Для управління маршрутизатором був розроблений SNMP-агент, що володіє необхідними характеристиками, а також драйвери додаткового терміналу та годин реального часу; крім того, визначено структуру відповідної бази даних MIB для SNMP - агента, встановленої на станції управління.

Розроблений SNMP -агент підтримує керуючі бази SNMP (MIB II), Ethernet MIB; забезпечує обробку запитів SNMP - менеджера; виробляє трансляцію команд і обмін даними між консоллю і комунікаційним модулем по протоколу RS-232; забезпечує проходження команд і відповідей з консолі на термінал і назад; зберігає необхідні дані (паролі, адреси менеджерів і т. п.) в незалежній пам'яті.

Програмне забезпечення SNMP - агента являє собою набір завдань і служб, кожна з яких виконується незалежно від інших завдань.

Головне завдання Init запускається перший і виробляє ініціалізацію комунікаційного модуля і його компонентів: годин реального часу , BSD - сокетів, термінального обладнання (каналу роботи з маршрутизатором), а також запуск основних завдань: TimerSrv, SNMPSrv, ConsoleSrv, TerminalSrv. Після цього система входить в режим очікування.

Служба таймера TimerSrv посилає періодичні запити і вчиняє інші процедури, пов'язані з часом. Вона встановлює прапори і перевіряє умови, згідно з якими виконуються дії в службах ConsoleSrv і TerminalSrv.

Служба SNMPSrv , що здійснює основні функції SNMP - агента, контролює надходження повідомлень від SNMP-менеджера на порт Ethernet і вживає необхідні дії відповідно до протоколу SNMPv1. Ця служба виконує опитування внутрішніх станів маршрутизатора з періодом в одну хвилину (час задається службою таймера). SNMP-агент забезпечує виконання команд get - request, get - next - request, get - response, set - request, trap. Він робить аналіз поточного стану маршрутизатора і діагностує помилки, які відображаються у відповідних полях Error структури PDU (Protocol Data Unit) відповідно до протоколу SNMPv1.

Служба роботи з консоллю ConsoleSrv забезпечує необхідне конфігурування маршрутизатора, яке здійснюється за допомогою використовуваного як консолі персонального комп'ютера. Ця служба реагує на команди консолі (визначено 14 команд), що задають режими роботи маршрутизатора, що виконують запис і читання необхідної інформації, в тому числі IP-адрес комп'ютерів, які мають право змінювати вміст MIB. Всі повідомлення, що йдуть від терміналу до консолі і назад, передаються комунікаційним модулем в наскрізному режимі. Дані, що вводяться з консолі, записуються в енергонезалежну пам'ять, тому вони зберігаються при відключенні живлення.

Служба роботи з термінальним обладнанням TerminalSrv безпосередньо управляє маршрутизатором. З її допомогою комунікаційний модуль періодично зчитує дані про поточний стан терміналу, які потім передаються SNMP-менеджеру для оновлення вмісту його MIB.

Розроблене програмне забезпечення для реалізації функцій SNMP - агента є базою для створення різних систем управління розподіленими мережами, побудованими на базі процесорів і контролерів Motorola.

Агенти RMON

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

Об'єкту RMON присвоєно номер 16 в наборі об'єктів MIB, а сам об'єкт RMON об'єднує 10 груп наступних об'єктів:

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

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

• Alarms - порогові значення статистичних показників, при перевищенні яких агент RMON посилає повідомлення менеджеру.

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

• HostTopN - таблиця найбільш завантажених хостів мережі.

• TrafficMatrix - статистика про інтенсивність трафіка між кожною парою хостів мережі.

• Filter - умови фільтрації пакетів.

• PacketCapture - умови захоплення пакетів.

• Event - умови реєстрації і генерації подій.

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

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

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

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

Розглянемо більш докладно групу Statistics, яка визначає, яку інформацію про кадри Ethernet може надати агент RMON.

До групи Statistics входять наступні об'єкти:

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

• etherStatsOrtets - загальне число байт (включаючи помилкові пакети), прийнятих з мережі (крім заголовка але з байтами контрольної суми).

• etherStatsPkts - загальне число отриманих пакетів (включаючи помилкові).

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

• etherStatsMulticastPkts - загальне число хороших пакетів, отриманих за мультівещательнимі адресою.

• etherStatsCRCAlign Errors - загальне число отриманих пакетів, які мали довжину (виключаючи заголовок) між 64 і 1518 байт, не містили ціле число байт (alignment error) або мали невірну контрольну суму (FCS error).

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

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

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

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

• etherStatsCollisions - найкраща оцінка числа колізій на даному сегменті Ethernet.

• etherStatsPkts640ctets - загальна кількість отриманих пакетів (включаючи погані) розміром 64 байт.

• etherStatsPkts65to1270ctets - загальна кількість отриманих пакетів (включаючи погані) розміром від 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 на протоколи верхніх рівнів, виконуючи частину роботи аналізаторів протоколів.

Аналізатори протоколів

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

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

Универсальная измерительная платформа EXFO FTB-500

Але найбільш досконалим засобом дослідження мережі є аналізатор протоколів. Аналізатор мережевих протоколів може використовуватися для:

• локалізації складних проблем;
• виявлення та ідентифікації несанкціонованого програмного забезпечення;
• отримання такої інформації, як базові моделі трафіку ( baseline traffic patterns ) і метрики утилізації мережі;
• ідентифікації невикористовуваних протоколів для видалення їх з мережі;
• генерації трафіку для випробування на вторгнення (penetration test) з метою перевірки системи захисту;
• роботи з системами виявлення вторгнень Intrusion Detection System (IDS);
• прослуховування трафіку, тобто локалізації несанкціонованого трафіку з використанням Instant Messaging (IM) або бездротових точок доступу Access Points - (AP);
• вивчення роботи мережі.

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

Незважаючи на відносне різноманіття аналізаторів протоколів, представлених на ринку, можна назвати деякі риси, в тій чи іншій мірі притаманні всім їм:

• Інтерфейс користувача. Більшість аналізаторів мають розвинений дружній інтерфейс, який базується, як правило, на Windows чи Motif. Цей інтерфейс дозволяє користувачеві: виводити результати аналізу інтенсивності трафіку; отримувати миттєву і середню статистичну оцінку продуктивності мережі; задавати певні події і критичні ситуації для відстежування їх виникнення; робити декодування протоколів різного рівня і представляти в зрозумілій формі вміст пакетів.

• Буфер захоплення. Буфери різних аналізаторів відрізняються за обсягом. Буфер може розташовуватися на мережевій карті, або для нього може бути відведено місце в оперативній пам'яті одного з комп'ютерів мережі. Якщо буфер розташований на мережевій карті, то управління ним здійснюється апаратно, і за рахунок цього швидкість введення підвищується. Однак це призводить до подорожчання аналізатора. У разі недостатньої продуктивності процедури захоплення, частина інформації буде губитися, і аналіз буде неможливий. Розмір буфера визначає можливості аналізу по більш або менш представницьким вибіркам даних, що захоплюються. Але яким би великим не був буфер захоплення, рано чи пізно він заповниться. У цьому випадку або припиняється захоплення, або заповнення починається з початку буфера.

• Можливість вимірювання середньостатистичних показників трафіку в сегменті локальної мережі, в якому встановлений мережевий адаптер аналізатора.

• Вимірюється коефіцієнт використання сегменту, матриці перехресного трафіку вузлів, кількість хороших і поганих кадрів, що пройшли через сегмент.

• Можливість роботи з декількома агентами, котрі поставляють захоплені пакети з різних сегментів локальної мережі. Ці агенти найчастіше взаємодіють з аналізатором протоколів за власним протоколом прикладного рівня.

• Фільтри. Фільтри дозволяють керувати процесом захоплення даних, і, тим самим, дозволяють економити простір буфера. Залежно від значення певних полів пакета, заданих у вигляді умови фільтрації, пакет або ігнорується, або записується в буфер захоплення. Використання фільтрів значно прискорює і спрощує аналіз, оскільки виключає перегляд непотрібних в даний момент пакетів.

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

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

• Багатоканальність. Деякі аналізатори протоколів дозволяють проводити одночасний запис пакетів від декількох мережевих адаптерів, що зручно для зіставлення процесів, що відбуваються в різних сегментах мережі. Можливості аналізу проблем мережі на фізичному рівні у аналізаторів протоколів мінімальні, оскільки всю інформацію вони отримують від стандартних мережевих адаптерів. Тому вони передають і узагальнюють інформацію фізичного рівня, яку повідомляє їм мережевий адаптер, а вона багато в чому залежить від типу мережного адаптера. Деякі мережні адаптери повідомляють більш детальні дані про помилки кадрів та інтенсивності колізій в сегменті, а деякі взагалі не передають таку інформацію верхнім рівням протоколів, на яких працює аналізатор протоколів.

Методологія проведення аналізу може бути представлена у вигляді наступних етапів:

Аналізатор протоколів виконує моніторинг мережевого трафіку

Аналізатор працює на станції хоста. Коли аналізатор запускається в хаотичному режимі (promiscuous mode), драйвер мережевого адаптера, NIC, перехоплює весь трафік, що проходить через нього. Аналізатор протоколів передає перехоплений трафік декодеру пакетів аналізатора (packet - decoder engine), який ідентифікує і "розщеплює" пакети по відповідним рівнями ієрархії. Програмне забезпечення протокольного аналізатора вивчає пакети і відображає інформацію про них на екрані хоста у вікні аналізатора. Залежно від можливостей конкретного продукту, представлена ​​інформація може згодом додатково аналізуватися і фільтруватися.

Зазвичай вікно протокольного аналізатора складається з трьох областей. Верхня область відображає підсумкові дані перехоплених пакетів. Зазвичай в цій області відображається мінімум полів, а саме:

• дата та час (у мілісекундах), коли пакети були перехоплені;
• вихідні і цільові IP- адреси;
• вихідні і цільові адреси портів;
• тип протоколу (мережевий , транспортний або прикладного рівня);
• деяка сумарна інформація про перехоплених даних.

У середній області показано детальну інформацію про пакет згідно мережевої моделі OSI. І нарешті, в нижній області пакет представлений в шістнадцятковому вигляді або в символьній формі - ASCII.

Обладнання для діагностики та сертифікації кабельних систем

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

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

Основні електромагнітні характеристики кабельних систем

Основними електричними характеристиками, що впливають на роботу кабелю, є: затухання, імпеданс (хвильовий опір), перехресні наводки двох кручених пар і рівень зовнішнього електромагнітного випромінювання.

Перехресні наводки між витими парами або NearEndCrosstalk (NEXT) - являють собою результат інтерференції електромагнітних сигналів, що виникають у двох кручених парах. Один з кабелів крученої пари передає сигнал, а другий - приймає. При проходженні сигналу по одному з кабелів, наприклад, по тому, що передає, у кабелі, що приймає сигнал виникають перехресні наводки. Величина NEXT залежить від частоти переданого сигналу - чим вище величина NEXT, тим краще (для категорії 5 NEXT повинен бути не менше 27 Дб при частоті 100 Мгц, для кабелю категорії 3 на частоті 10 МГц NEXT повинен бути не менше 26 Дб).

Затухання (Attenuation) - являє собою втрату амплітуди електричного сигналу при його поширенні по кабелю. Затухання має два основних джерела: електричні характеристики кабелю і поверхневий ефект. Останній пояснює залежність затухання від частоти. Затухання вимірюється в децибелах на метр. Для кабелю категорії 5 при частоті 100 Мгц загасання не повинно перевищувати 23.6 Дб на 100 м, а для кабелю категорії 3, за стандартом IEEE 802.3 10BASE-T, допустима величина затухання на сегменті довжиною 100 м не повинна перевищувати 11,5 Дб при частоті змінного струму 10 МГц.

Імпеданс (хвильовий опір) - це повний (активне і реактивне) опір в електричному ланцюзі. Імпеданс вимірюється в омах і є відносно постійною величиною для кабельних систем. Для неекранованої крученої пари найбільш часті значення імпедансу - 100 і 120 Ом. Характерні значення імпедансу для мереж стандарту Ethernet на коаксіальному кабелі становлять 50 Ом, а для мереж стандарту Arcnet - 93 Ом. Різкі зміни імпедансу по довжині кабелю можуть викликати процеси внутрішнього відображення, що призводять до виникнення стоячих хвиль. Стояча хвиля — тип коливань у неперервному середовищі, при яких кожна точка середовища здійснює періодичний рух зі сталою амплітудою, залежною від її положення. Стоячі хвилі не переносять енергію. Робоча станція, підключена до кабелю у районі вузла стоячої хвилі, не зможе отримувати адресовані їй повідомлення.

Активний опір - це опір постійному струму в електричному ланцюзі. На відміну від імпедансу активний опір не залежить від частоти і зростає зі збільшенням довжини кабелю. Для неекранованої крученої пари категорії 5 активний опір не повинен перевищувати 9.4 Ом на 100 м.

Ємність - це властивість металевих провідників накопичувати енергію. Два електричних провідника в кабелі, розділені діелектриком, являють собою конденсатор, здатний накопичувати заряд. Ємність є небажаною величиною, тому її слід робити якомога менше. Високе значення ємності в кабелі приводить до спотворення сигналу і обмежує смугу пропускання лінії. Для кабельних систем категорії 5 значення ємності не повинен перевищувати 5.6нФ на 100 м.

Рівень зовнішнього електромагнітного випромінювання, або електричний шум - це небажана зміна напруги в провіднику. Електричний шум буває двох типів: фоновий і імпульсний. Електричний шум можна також розділити на низько-, середньо-і високочастотний. Джерелами фонового електричного шуму є в діапазоні до 150 КГц лінії електропередачі, телефони і лампи денного світла; в діапазоні від 150 КГц до 20 Мгц комп'ютери, принтери, ксерокси; в діапазоні від 20 МГц до 1 ГГц – теле- і радіопередавачі, мікрохвильові печі. Основними джерелами імпульсного електричного шуму є мотори, перемикачі і зварювальні агрегати. Електричний шум вимірюється в мВ. Кабельні системи на крученій парі не сильно схильні до впливу електричного шуму (на відміну від впливу NEXT).

Мережеві аналізатори

Мережеві аналізатори (не слід плутати їх з аналізаторами протоколів) являють собою еталонні вимірювальні інструменти для діагностики та сертифікації кабелів і кабельних систем. Як приклад можна привести мережеві аналізатори компанії HewlettPackard - HP 4195A і HP 8510C. Мережеві аналізатори містять високоточний частотний генератор і вузькосмуговий приймач. Передаючи сигнали різних частот в передавальну пару і вимірюючи сигнал у приймальній парі, можна виміряти затухання і NEXT. Мережеві аналізатори - це великогабаритні і дорогі прилади, призначені для використання в лабораторних умовах спеціально навченим технічним персоналом.

Кабельні сканери

Дані прилади дозволяють визначити довжину кабелю, NEXT, затухання, імпеданс, схему розводки, рівень електричних шумів і провести оцінку отриманих результатів. Існує досить багато пристроїв даного класу, наприклад, сканери компаній MicrotestInc., FlukeCorp., DatacomTechnologiesInc., ScopeCommunicationInc. На відміну від мережевих аналізаторів сканери можуть бути використані не тільки спеціально навченим технічним персоналом, але навіть адміністраторами-новачками.

Для визначення місця розташування несправності кабельної системи (обриву, короткого замикання, неправильно встановленого роз'єму і т.д.) використовується метод "кабельного радара", або TimeDomainReflectometry (TDR). Суть цього методу полягає в тому, що сканер випромінює в кабель короткий електричний імпульс і вимірює час затримки до приходу відбитого сигналу. За полярності відображеного імпульсу визначається характер пошкодження кабелю (коротке замикання або обрив). У правильно встановленому і підключеному кабелі відбитий імпульс зовсім відсутній.

Точність вимірювання відстані залежить від того, наскільки точно відома швидкість розповсюдження електромагнітних хвиль у кабелі. У різних кабелях вона буде різною. Швидкість розповсюдження електромагнітних хвиль у кабелі (NVP) зазвичай задається у відсотках до швидкості світла у вакуумі. Сучасні сканери містять в собі електронну таблицю даних про NVP для всіх основних типів кабелів і дозволяють користувачеві встановлювати ці параметри самостійно після попереднього калібрування.

Найбільш відомими виробниками компактних кабельних сканерів є компанії MicrotestInc., WaveTekCorp., ScopeCommunicationInc.

Тестери

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

Перейти до Засоби аналізу та оптимізації мереж