Мистецтво діагностики локальних мереж

Якщо програми періодично працюють повільно, комп'ютери "зависають" або відключаються від сервера, і програмісти при цьому говорять, що у всьому винна мережа, а адміністратор мережі, - що у всьому винні програми, то ця стаття адресована саме вам.

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

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

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

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

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

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

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

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

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

При перевірці мережі кабельним сканером замість активного обладнання до кабелю підключаються з одного кінця – сканер, з іншого – інжектор. Після перевірки кабелю сканер та інжектор відключаються, та підключається активне обладнання: мережні плати, концентратори, комутатори. При цьому немає повної гарантії того, що контакт між активним обладнанням та кабелем буде настільки ж гарний, як між обладнанням сканера та кабелем. Ми неодноразово траплялися з випадками, коли незначний дефект вилки RJ-45 не виявлявся під час тестування кабельної системи сканером, але виявлявся при діагностиці мережі аналізатором протоколів.

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

Будь-яка методика тестування мережі істотно залежить від наявних у розпорядженні системного адміністратора коштів. На нашу думку, в більшості випадків необхідним і достатнім засобом виявлення дефектів мережі (крім кабельного сканера) є аналізатор мережевих протоколів. Він повинен підключатися до домену мережі (collision domain), де спостерігаються збої, максимально близько до найбільш підозрілих станцій чи серверу (див. Правило #3.3).

Якщо мережа має архітектуру з компактною магістраллю (collapsed backbone) і в якості магістралі використовується комутатор, то аналізатор необхідно підключати до портів комутатора, через які проходить аналізований трафік. Деякі програми мають спеціальні агенти або зонди (probes), які встановлюються на комп'ютерах, підключених до віддалених портів комутатора. Зазвичай агенти (не плутати з агентами SNMP) є сервіс або завдання, що працює у фоновому режимі на комп'ютері користувача. Як правило, агенти споживають мало обчислювальних ресурсів та не заважають роботі користувачів, на комп'ютерах яких вони встановлені. Аналізатори та агенти можуть бути підключені до комутатора двома способами.

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

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

Якщо в комутаторі спеціальний порт відсутній, то аналізатор (або агент) слід підключати до портів доменів мережі, що цікавлять, в максимальній близькості до найбільш підозрілих станцій або серверу (див. Рисунок 1б). Іноді це може вимагати використання додаткового концентратора. Згідно з Правилом #3.3, даний спосіб кращий за перший. Виняток становить випадок, коли один із портів комутатора працює в повнодуплексному режимі. Якщо це так, порт попередньо необхідно перевести в напівдуплексний режим.

Малюнок 1б. Аналізатор протоколів та віддалені агенти контролюють основні домени мережі. Для діагностики домену сервера використовується додатковий концентратор.

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

По-перше, аналізатор протоколів повинен мати вбудовану функцію створення трафіку (див. Правило #3.4). По-друге, аналізатор протоколів повинен уміти "проріджувати" прийняті кадри, тобто приймати не всі кадри поспіль, а, наприклад, кожен п'ятий або кожен десятий з обов'язковою подальшою апроксимацією отриманих результатів. Якщо ця функція відсутня, то при сильній завантаженості мережі, хоч би якою продуктивністю володів комп'ютер, на якому встановлено аналізатор, останній буде "зависати" і/або втрачати кадри. Це особливо важливо при діагностиці швидких мереж типу Fast Ethernet та FDDI.

Пропоновану методику ми ілюструватимемо з прикладу використання суто програмного аналізатора протоколів Observer компанії Network Instruments, що у середовищі Windows 95 і Windows NT. На наш погляд, цей продукт має всі необхідні функції для ефективного проведення діагностики мереж.

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

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

Припустимо, що аналізатор протоколів встановлено у тому домені мережі (collision domain), де прикладне програмне забезпечення працює повільно. Середня утилізація каналу зв'язку становить 19%, пікова сягає 82%. Чи можна на підставі цих даних зробити достовірний висновок, що причиною повільної роботи програм у мережі є перевантаженість каналу зв'язку? Навряд чи.

Часто можна чути про стандарт де-факто, відповідно до якого для задовільної роботи мережі Ethernet утилізація каналу зв'язку "в тренді" (усереднене значення за 15 хвилин) не повинна перевищувати 20%, а "у піку" (усереднене значення за 1 хвилину) – 35-40%. Наведені значення пояснюються тим, що в мережі Ethernet при утилізації каналу зв'язку, що перевищує 40%, суттєво зростає кількість колізій та, відповідно, час реакції прикладного ПЗ. Незважаючи на те, що такі міркування в загальному випадку правильні, безумовне дотримання подібних рекомендацій може призвести до неправильного висновку про причини повільної роботи програм у мережі. Не враховують особливості конкретної мережі, саме: тип прикладного ПЗ, протяжність домену мережі, число одночасно працюючих станцій.

Щоб визначити, яка максимально допустима утилізація каналу зв'язку у вашому конкретному випадку, ми рекомендуємо дотримуватися наведених нижче правил.
Правило #1.1.
Якщо в мережі Ethernet у будь-який момент часу обмін даними відбувається не більше ніж між двома комп'ютерами, то будь-яка скільки завгодно висока утилізація мережі є допустимою.

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

Якщо робоча станція та сервер мають високу продуктивність, і між ними йде обмін великими порціями даних, то утилізація в каналі зв'язку може досягати 80-90% (особливо в пакетному режимі - burst mode). Це абсолютно не уповільнює роботу мережі, а навпаки свідчить про ефективне використання її ресурсів прикладним ПЗ.

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

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

Наскільки канал зв'язку відповідальний за недостатню продуктивність системи, можна з'ясувати в такий спосіб. Вибравши найбільш масову операцію цього прикладного ПЗ (наприклад, для банківського ПЗ такою операцією може бути введення платіжного доручення), вам слід визначити, як утилізація каналу зв'язку впливає на час виконання такої операції.

Найпростіше це зробити, скориставшись функцією генерації трафіку, що є в ряді аналізаторів протоколів (наприклад, Observer). За допомогою цієї функції інтенсивність навантаження, що генерується, слід нарощувати поступово, і на її тлі проводити вимірювання часу виконання операції. Фонове навантаження доцільно збільшувати від 0 до 50-60% з кроком трохи більше 10%.

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

У цьому експерименті фонове навантаження не слід задавати більше 60-70%. Навіть якщо канал зв'язку не є вузьким місцем, за таких навантажень час виконання операцій може зрости внаслідок зменшення ефективної пропускної здатності мережі.
Правило #1.3.
Максимально допустима утилізація зв'язку залежить від протяжності мережі.

При збільшенні довжини домену мережі допустима утилізація зменшується. Чим більша довжина домену мережі, тим пізніше виявлятимуться колізії. Якщо протяжність домену мережі мала, то колізії будуть виявлені станціями ще на початку кадру, у момент передачі преамбули. Якщо довжина мережі велика, то колізії буде виявлено пізніше - у момент передачі кадру. В результаті накладні витрати на передачу пакета (IP або IPX) зростають. Чим пізніше виявлено колізію, тим більше величина накладних витрат і більше часу витрачається на передачу пакета. В результаті час реакції прикладного ПЗ, хоч і незначно, але збільшується.

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

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

Місцева колізія (local collision) - це колізія, що фіксується в домені, де підключено вимірювальний пристрій, в межах передачі преамбули або перших 64 байт кадру, коли джерело передачі знаходиться в домені. Алгоритми виявлення місцевої колізії для мережі на основі кручений пари (10BaseT) і коаксіального кабелю (10Base2) відмінні один від одного.

У мережі 10Base2 передавальна кадр станція визначає, що сталася локальна колізія зміни рівня напруги в каналі зв'язку (за його подвоєння). Виявивши колізію, передавальна станція посилає канал зв'язку серію сигналів про затор (jam), щоб всі інші станції домену дізналися, що сталася колізія. Результатом цієї серії сигналів виявляється поява в мережі коротких, неправильно оформлених кадрів завдовжки менше 64 байт з неправильною контрольною послідовністю CRC. Такі кадри називаються фрагментами (collision fragment чи runt).

У мережі 10BaseT станція визначає, що сталася локальна колізія, якщо під час передачі кадру вона виявляє активність на приймальній парі (Rx).

Віддалена колізія (remote collision) - це колізія, що виникає в іншому фізичному сегменті мережі (тобто за повторювачем). Станція дізнається, що відбулася віддалена колізія, якщо вона отримує неправильно оформлений короткий кадр з невірною контрольною послідовністю CRC, і при цьому рівень напруги в каналі зв'язку залишається в межах (для мереж 10Base2). Для мереж 10BaseT/100BaseT показником є ​​відсутність одночасної активності на приймальній та передавальної парах (Tx та Rx).

Пізня колізія (late collision) - це місцева колізія, яка фіксується вже після того, як станція передала канал зв'язку перші 64 байт кадру. У мережах 10BaseT пізні колізії часто фіксуються вимірювальними пристроями як помилки CRC.

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

Крім високого рівня утилізації каналу зв'язку колізії у мережі Ethernet можуть бути викликані дефектами кабельної системи та активного обладнання, а також наявністю шумів.

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

У цьому важливо з'ясувати, яка причина колізій - висока утилізація мережі чи " приховані " дефекти мережі. Щоб це визначити, ми рекомендуємо дотримуватись таких правил.
Правило #2.1.

Не всі вимірювальні прилади правильно визначають загальну кількість колізій у мережі.

Практично всі суто програмні аналізатори протоколів фіксують наявність колізії лише тому випадку, якщо вони виявляють у мережі фрагмент, т. е. результат колізії. При цьому найбільш поширений тип колізій - що відбуваються в момент передачі преамбули кадру (тобто до початкового обмежувача кадру (SFD)) - програмні вимірювальні засоби не виявляють, так влаштований набір мікросхем мережевих плат Ethernet. Найбільш точно колізії виявляють апаратні вимірювальні прилади, наприклад, LANMeter компанії Fluke.
Правило #2.2.

Висока утилізація каналу зв'язку не завжди супроводжується високим рівнем колізій.

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

Ознакою наявності дефекту в мережі є така ситуація, коли невисока утилізація каналу (менше 30%) супроводжується високим рівнем колізій (понад 5%).

Якщо кабельна система попередньо була протестована сканером, то найбільш ймовірною причиною підвищеного рівня колізій є шум лінії зв'язку, викликаний зовнішнім джерелом, або дефектна мережева плата, що неправильно реалізує алгоритм доступу до середовища передачі (CSMA/CD).

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

Частку колізій у кількості кадрів має сенс аналізувати в останній момент активності підозрілих (повільно працюючих) станцій і у разі, коли утилізація каналу зв'язку перевищує 30%. Якщо з трьох кадрів один зіткнувся з колізією, це ще не означає, що в мережі є дефект.

В аналізаторі протоколів Observer графік, показаний на Малюнку 3, змінює колір залежно від кількості колізій і утилізації каналу зв'язку, що при цьому спостерігається.
Правило #2.4.

При діагностиці мережі 10BaseT всі колізії повинні фіксуватися як видалені, якщо аналізатор протоколів не створює трафіку.

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

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

Колізії в мережі можуть бути наслідком перевантаження вхідних буферів комутатора.

Слід пам'ятати, що комутатори при перевантаженості вхідних буферів емулюють колізії, щоб "пригальмувати" робочі станції мережі. Цей механізм називається "керування потоком" (flow control).
Правило #2.6.
Причиною великої кількості колізій (і помилок) у мережі може бути неправильна організація заземлення комп'ютерів, включених до локальної мережі.

Якщо комп'ютери, включені в мережу не мають загальної точки заземлення (занулення), між корпусами комп'ютерів може виникати різниця потенціалів. У персональних комп'ютерах "захисна" земля поєднана з "інформаційною" землею. Оскільки комп'ютери об'єднані каналом зв'язку локальної мережі, різниця потенціалів між ними призводить до виникнення струму каналом зв'язку. Цей струм викликає спотворення інформації та є причиною колізій та помилок у мережі. Такий ефект отримав назву ground loop або inter ground noise.

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

Звертаємо вашу увагу, що встановлення джерела безперебійного живлення не знімає описаних труднощів. Найбільш докладно дані проблеми та способи їх вирішення розглядаються в матеріалах компанії APC (American Power Conversion) у Посібнику з захисту електроживлення (Power Protection Handbook).

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

У мережах Ethernet найпоширенішими є такі типи помилок.

Короткий кадр - кадр довжиною менше 64 байт (після 8-байтної преамбули) з правильною контрольною послідовністю. Найімовірніша причина появи коротких кадрів - несправна мережна плата або неправильно налаштований або зіпсований мережний драйвер.

Останнім часом ми спостерігаємо велику кількість помилок цього на відносно повільних комп'ютерах (486/SX), що працюють під Windows 95 з мережними платами NE2000. Причина нам невідома.

Довгий кадр (long frame) – кадр довший за 1518 байт. Довгий кадр може мати правильну чи неправильну контрольну послідовність. У разі такі кадри зазвичай називають jabber. Фіксація довгих кадрів з правильною контрольною послідовністю вказує найчастіше некоректність роботи мережного драйвера; фіксація помилок типу jabber - на несправність активного устаткування чи наявність зовнішніх перешкод.

Помилки контрольної послідовності (CRC error) – правильно оформлений кадр допустимої довжини (від 64 до 1518 байт), але з невірною контрольною послідовністю (помилка у полі CRC).

Помилка вирівнювання (alignment error) - кадр, що містить число біт, не кратне числу байт.

Блики (ghosts) - послідовність сигналів, відмінних за форматом від кадрів Ethernet, яка містить роздільника (SFD) і довжиною понад 72 байт. Вперше цей термін було введено компанією Fluke з метою диференціації відмінностей між віддаленими колізіями та шумами каналу зв'язку.

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

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

Відповідно до загальноприйнятих стандартів де-факто кількість помилок канального рівня не повинна перевищувати 1% від загальної кількості переданих по мережі кадрів. Як показує досвід, ця величина перекривається лише за наявності явних дефектів кабельної системи мережі. При цьому багато серйозних дефектів активного обладнання, що викликають численні збої в роботі мережі, не виявляються на канальному рівні мережі (див. Правило # 3.8).
Правило #3.1.

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

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

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

EtherExpress Pro компанії Intel повідомляють лише про помилки CRC та вирівнювання. Мережеві плати компанії SMC надають інформацію лише про короткі кадри. NE2000 видає майже повну інформацію, виявляючи помилки CRC, короткі кадри, помилки вирівнювання, колізії.

Мережні карти D-Link (наприклад, DFE-500TX) та Kingstone (наприклад, KNE 100TX) повідомляють повну, а за наявності спеціального драйвера - навіть розширену інформацію про помилки та колізії в мережі.

Ряд розробників аналізаторів протоколів пропонують свої драйвери найбільш популярних мережевих плат.
Правило #3.2.

Звертайте увагу на "прив'язку" помилок до конкретних MAC-адрес станцій.

При аналізі локальної мережі ви, напевно, звертали увагу на те, що помилки зазвичай "прив'язані" до певних МАС-адрес станцій. Однак колізії, що відбулися в адресній частині кадру, відблиски, нерозпізнані ситуації типу короткого кадру з нульовою довжиною даних не можуть бути прив'язані до конкретних МАС-адрес.

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

Якщо більшість помилок прив'язані до конкретних MAC-адрес станцій, то постарайтеся виявити закономірність між місцезнаходженням станцій, що передають помилкові кадри, розташування вимірювального приладу (див. Правила # 3.3, # 3.4) і топологією мережі.
Правило #3.3.

У межах одного домену мережі (collision domain) тип і кількість помилок, що фіксуються аналізатором протоколів, залежить від місця підключення вимірювального приладу.

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

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

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

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

Підтвердження наведеного правила можна знайти на серверах Web компаній Fluke (www.fluke.com) та Net3 Group (www.net3group.com).

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

Генерація трафіку дозволяє загострити наявні проблеми та створює умови для їхнього прояву. Трафік повинен мати невисоку інтенсивність (не більше 100 кадрів/с) та сприяти утворенню колізій у мережі, тобто містити короткі (
При виборі аналізатора протоколів або іншого діагностичного засобу увагу слід звернути насамперед на те, щоб обраний інструмент мав вбудовану функцію генерації трафіку інтенсивності, що задається. Ця функція є зокрема в аналізаторах Observer компанії Network Instruments і NetXray компанії Cinco (нині Network Associates).
Правило #3.5.

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

Якщо частка помилок CRC у загальному числі помилок велика, слід визначити довжину кадрів, містять цей тип помилок.

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

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

Порівняти довжину помилкових і правильних кадрів найпростіше шляхом збору в буфер аналізатора серії кадрів з помилкою CRC.
Правило #3.7.

Таблиця1 систематизує причини помилок та колізій для етапів 2 та 3

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

Найбільш надійним способом локалізації дефектів є почергове відключення підозрілих станцій, концентраторів та кабельних трас, ретельна перевірка топології ліній заземлення комп'ютерів (особливо для мереж 10Base2).

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

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

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

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

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

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

Іноді, крім спотворення, спостерігається зникнення інформації. Найчастіше воно відбувається на дешевих мережних платах або комутаторах Ethernet-FDDI. Механізм зникнення інформації у разі зрозумілий. У ряді комутаторів Ethernet-FDDI зворотний зв'язок швидкого порту з повільним (або навпаки) відсутній, в результаті інший порт не отримує інформації про перевантаження вхідних/вихідних буферів швидкого (повільного) порту. В цьому випадку при інтенсивному трафіку інформація на одному з портів може зникнути.

Досвідчений адміністратор мережі може заперечити, що крім захисту інформації на канальному рівні в протоколах IPX та TCP/IP можливий захист інформації за допомогою контрольної суми.

Повною мірою на захист за допомогою контрольної суми можна покладатися, тільки якщо прикладне програмне забезпечення як транспортний протокол задіює TCP або UDP. Тільки за їх використання контрольною сумою захищається весь пакет. Якщо як "транспорт" застосовується IPX/SPX або безпосередньо IP, то контрольною сумою захищається лише заголовок пакета.

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

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

Крім заміни (вимкнення) підозрілого обладнання виявити такі дефекти можна двома способами.

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

Другим способом є метод стресового тестування мережі.

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

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

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

Спостережуваними параметрами зазвичай є:

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

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

Спостерігаючи досить довго за роботою каналу зв'язку та сервера, можна встановити тенденцію зміни значень різних параметрів роботи мережі (утилізації ресурсів, числа помилок тощо). На підставі таких спостережень адміністратор може зробити висновки щодо необхідності заміни активного обладнання або зміни архітектури мережі.

У разі появи в мережі проблеми адміністратор в момент її прояву повинен записати в спеціальний буфер або файл дамп канальної траси і на підставі аналізу її вмісту зробити висновки про можливі причини проблеми.
Джерело: Бібліотека IT фахівця.

http://inform.p-stone.ru/libr/nets/monitor/data/public14/#p1

Перед тим як писати "у мене нічого не працює", постарайтеся з'ясувати, що конкретно у вас не працює.

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

Будь ласка, прочитайте перед написанням хоча б кілька повідомлень теми на останній сторінці - можливо, що ця проблема вже вирішена або її вже вирішують!

Діагностичні команди:

*Виконуються у попередньо відкритому вікні "командного рядка". (Пуск -> Усі програми -> Стандартні -> Командний рядок)
Для Windows Vista/7: Win+R ===> cmd ===> Enter
Для Windows NT/2000/XP/VISTA: "Пуск" - "Виконати" - "cmd"
Windows 95/98: "Пуск" - "Виконати" - "command".

Копіювання тексту: правою кнопкою на цьому вікні - "редагування" - "виділити" і "редагування" - "копіювати".

ipconfig /all
nslookup
ping [адреса хоста(наприклад, ya.ru)] [-n 20]
pathping [адреса хоста]
tracert [адреса хоста]

ipconfig /all показує налаштування мережевих інтерфейсів.
Все, що там вказано, необхідно звірити з пам'яткою користувача (якщо пам'ятка стара, то звірити з тими даними, виданими технічною підтримкою). Як настроюється підключення дивіться на сайті

ping [-t] показує час відповіді зазначеного хоста. Великі затримки побічно можуть бути індикатором повільного ресурсу (завантаженого каналу, слабкого заліза ресурсу тощо). Ключ [-t] служить до виконання команди доти, як користувач не перерве її натисканням "Ctrl+C". За замовчуванням, без цього ключа, ping виконається лише чотири рази, чого не завжди достатньо.

pathping Показує час відповіді та кількість пакетів, що зникли, на всьому протязі маршруту до хоста.

tracert
Для графічного відображення проблем можна завантажити з локальної мережі програму PingPlotter

nslookup
Перевірити роботу DNS.

Алгоритм перевірки: Помилка "Мережевий кабель не підключено"

1. Перевірити підключення кабелю в мережі
2. Перевірити цілісність кабелю до щитка.
3. Зателефонувати до Тех. підтримку.

Мережевий кабель підключено, але вхідних пакетів немає.

1. Перевірити підключення кабелю в мережі (можна вийняти та вставити кабель у гніздо).
2. Вимкнути всі брандмауери (файєрволи), якщо вони у вас є.
3. Пропінгувати шлюз (адресу взяти з налаштувань з'єднання або відомостей про з'єднання на панелі керування).
4. Зателефонувати до Тех. підтримку.

Мережевий кабель підключено, вхідні пакети є, але не зайти на внутрішні сервіси:

1. Вимкнути всі брандмауери (файєрволи), якщо вони у вас є.
2. Перевірити роботу DNS (nslookup).
3. Перевірити зв'язок із цими серверами (ping )
4. Перевірити зв'язок із центральними серверами. (ping online.vo, ping 192.168.0.250, ping адреса_вашого_шлюзу)
5. Перевірити налаштування браузера
5.1. Internet Explorer -> меню "Сервіс" -> "Властивості Оглядача" -> "З'єднання" -> "Налаштування мережі" -> перевірити, чи відключена галка "використовувати проксі-сервер"
6. Зателефонувати до Тех. підтримку.

Перевірка DNS:

Команда nslookup сервер повинна повернути ip-адресу цього сервера. Наприклад, команда "nslookup vo47.ru" має повернути адресу "193.106.108.68"

Команди діагностики

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

Виявлення дефектів фізичного рівня мережі: кабельної системи; системи електроживлення активного обладнання; наявності шуму від зовнішніх джерел.

Вимірювання поточної завантаженості каналу зв'язку мережі та визначення впливу величини завантаження каналу зв'язку на час реакції прикладного.

Вимірювання кількості колізій у мережі та з'ясування причин їх виникнення.

Вимірювання кількості помилок передачі на рівні каналу зв'язку і з'ясування причин їх виникнення.

Виявляє дефекти архітектури мережі.

Вимірювання поточної завантаженості сервера та визначення впливу ступеня його завантаження на час реакції прикладного ПЗ.

Виявлення дефектів прикладного ПЗ, наслідком яких є неефективне використання пропускної спроможності сервера та мережі.

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

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

При перевірці мережі кабельним сканером замість активного обладнання до кабелю підключаються з одного кінця – сканер, з іншого – інжектор. Після перевірки кабелю сканер та інжектор відключаються, та підключається активне обладнання: мережні плати, концентратори, комутатори. При цьому немає повної гарантії того, що контакт між активним обладнанням та кабелем буде настільки ж гарний, як між обладнанням сканера та кабелем. Неодноразово трапляються випадки, коли незначний дефект вилки RJ-45 не виявляється під час тестування кабельної системи сканером, але виявлявся під час діагностики мережі аналізатором протоколів.

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

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

Другий підхід заснований на дослідженні базових ліній параметрів (так званих трендів), що характеризують роботу пристрою, що діагностується. Основний принцип другого підходу можна сформулювати наступним чином: "пристрій працює добре, якщо він працює так, як завжди". На цьому принципі заснована запобіжна (proactive) діагностика мережі, мета якої - запобігти настанню її критичних станів. Протилежною запобіжною є реактивна (reactive) діагностика, мета якої не запобігти, а локалізувати та ліквідувати дефект. На відміну від першого, цей підхід дозволяє виявляти дефекти, що виявляються не завжди, а іноді. Недоліком другого підходу є припущення, що мережа спочатку працювала добре. Але "як завжди" і "добре" не завжди означають те саме.

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

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

Муромський інститут (філія) Володимирського державного університету

Методи вирішення проблем проектування та діагностики локальних обчислювальних мереж

А.Є. Лашин, Д.О. Мальцев

Науковий керівник – В.В. Чекушкін, професор кафедри САПР, д.т.н.

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

ЛОМ включає: кабельну локальну мережу, активне мережеве обладнання та комп'ютери різного призначення. Переваги застосування локальної обчислювальної мережі:

Можливість отримати та надіслати будь-яку інформацію з будь-якого комп'ютера в мережі.

Вільне додавання, видалення та переміщення робочих місць співробітників всередині офісу/будівлі.

Оперативне нарощування (модернізація) системи устаткування без витрат за кабельну мережу.

При побудові ЛОМ головним завданням є ефективне проектування її структури (рис. 1). Завдяки правильно обраній структурі локальної мережі можна значно підвищити швидкість і функціональність системи та скоротити подальші витрати на її створення та подальший сервіс.

Мал. 1 – Структура локальної обчислювальної мережі

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

Мережа сформована за допомогою комутаторів і кручений пари, обжатий за стандартом T568A. Доступ до інтернету здійснюється за допомогою роутера. Мережа інтернет (виділена лінія) підключається до входу роутера, яке вихід підключається до входу розгалужувача. Розгалужувач у свою чергу або на пряму або через інші розгалужувачі підключається до комп'ютера. Таким чином здійснюється з'єднання всіх комп'ютерів в єдину локальну обчислювальну мережу (ЛВС).

Щоб окремі комп'ютери відображалися у мережному оточенні всередині ЛОМ, необхідно кожен комп'ютер налаштувати належним чином. Тобто встановити драйвер мережевої карти і встановити налаштування мережного підключення. В даному випадку потрібно відключити mac адресу, ввести IP адресу та маску підмережі, а якщо потрібно доступ в інтернет, то ввести адресу шлюзу (IP адреса роутера).

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

локальна мережа роутер

1. Спочатку необхідно перевірити цілісність лінії кручений пари. Якщо ялини виявлено урвище, необхідно його усунути;

2. Перевірити, якість контакту конектора кручений пари, як у роз'ємі мережевої карти, так і в роз'ємі комутатора. Вийняти конектор з роз'єму і знову вставити до характерного клацання;

3. Перевірити правильність введених налаштувань (наприклад, у 2-х машин у ЛОМ не може бути однакова IP адреса). Ввести правильні установки для конкретної машини;

4. Якщо проблема не в цьому, необхідно спробувати під'єднати мережевий провід до іншого роз'єму в комутаторі (буває, що вигоряє один з роз'ємів, а не весь комутатор). Вийняти конектор з роз'єму та приєднати його до іншого роз'єму;

5. Перевірити стан mac адреси (при встановленні на машину деяких операційних систем він може змінитися). В даному випадку, відключити в настройках mаc адресу;

6. Якщо несправність не усунена, то потрібно перевстановити драйвера мережної карти, але після цього доведеться вводити всі налаштування заново. Вставити диск з драйвером і запустити інсталяцію драйвера за допомогою стандартної утиліти, далі ввести всі налаштування для конкретної машини;

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

Це основні сім проблем, які можуть виникнути. Але бувають випадки абсолютно специфічних неполадок: наприклад, дуже сильна запиленість, вихід з ладу роутера або його блоку живлення, проблема з розеткою мережі 220 В, і т.д. Деякі проблеми можуть бути абсолютно неординарні і вимагати іншого вирішення проблеми (наприклад, не правильне розведення з'єднувальних проводів, в такому випадку потрібно виправити некоректно розведений кінець проводу).

Кошти, що застосовуються для діагностування та моніторингу КС, можна розділити на кілька великих класів:

- Системи керування мережею (Network Management Systems)- централізовані програмні системи, побудовані відповідно до моделі TMN, які збирають дані про стан вузлів та комунікаційних пристроїв мережі, а також дані про трафік, що циркулює в мережі. Ці системи не тільки здійснюють моніторинг та аналіз мережі, а й виконують в автоматичному або напівавтоматичному режимі дії з керування мережею - включення та відключення портів пристроїв, зміна параметрів мостів адресних таблиць мостів, комутаторів та маршрутизаторів тощо. Прикладами систем управління можуть бути популярні системи HP OpenView, Sun NetManager, IBM NetView, Tivoli. Відповідно до рекомендацій ISO можна виділити такі функції систем керування мережею:

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

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

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

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

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

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

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

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

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

Прикладами засобів управління системою є такі продукти, як System Management Server компанії Microsoft або LANDeskManager фірми Intel, а типовими представниками засобів управління мережами є HPOpenView, SunNetManager і IBMNetView.

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

- Аналізатори протоколів (Protocol analyzers)- є програмними або апаратно-програмними системами, які обмежуються на відміну від систем управління функціями моніторингу та аналізу трафіку в мережах, у тому числі і бездротових. Виділяють низку критеріїв оцінки аналізатори протоколів:

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

− Якість інтерфейсу програмного забезпечення (буфер захоплення, фільтри, перемикачі, післяфільтраційний пошук, діапазон статистичних даних).

− Наявність багатоканальності.

− Генерація трафіку.

− Можливість інтеграції з ПК.

− Розмір та вага.

− Співвідношення ціни та послуг, що надаються.

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

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

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

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

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

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

У зв'язку з повсюдним поширенням оптоволоконних мереж зв'язку все більшої ваги набувають інструменти тестування ВОЛЗ.

Візуальний дефектоскоп - VFL (Visual Fault Locator) може використовуватися, щоб перевірити полярність, а також виявити неприпустимі вигини або обрив кабелю. VFL - це потужний інфрачервоний лазер, що посилає випромінюваний ним потік в один кінець кабелю. При цьому VFL визначає безперервність, ідентифікує правильність підключення конекторів.

Аналізатор оптичних втрат - OLTS (Optical Loss Test Set) включає два компоненти: джерело світла і вимірювач потужності оптичного сигналу. Використання засобів діагностики цього типу дозволяє перевірити цілісність волокна та перевірити відповідність кабелю встановленим стандартам. Багато пристроїв роблять таке порівняння автоматично.

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

Оптичні рефлектометри OTDR (Optical Domain Reflectometer) - діагностичні інструменти, які використовуються, щоб характеризувати втрату потужності оптичного сигналу, посилаючи короткий імпульс світла з одного кінця волокна та аналізуючи світло, відбите від іншого кінця волокна. Реєструючи показання, OTDR визначає оптичну потужність, час проходу сигналу та відображає ці дані у вигляді графіка. Дані пристрої дозволяють проводити вимірювання елементів, що входять до мережі, включаючи довжину частин волокна, однорідність послаблення сигналу, розташування конекторів. Таким чином, можна візуально визначити місцезнаходження рефлексивних подій (зв'язки, обриви волокна) та нерефлексивні події (з'єднання, неприпустимі або напружені вигини), аналізуючи графік, або за допомогою таблиці подій, яка може бути згенерована пристроями OTDR.

Рис.1.3 - Оптичний рефлектометр

Рефлектометр MTS 8000 - це нова мультимодульна тестова платформа для оптоволоконних систем. У цьому приладі одночасно встановлено рефлектометр, оптичний тестер, вимірювач оптичної потужності, локатор візуальних дефектів, оптичний мікроскоп, оптична гарнітура, OTDR. Конструктивне рішення, розроблене фахівцями Acterna, дозволяє одночасно встановлювати в MTS 8000 велику кількість змінних оптичних модулів, завдяки чому користувач отримує можливість вимірювати всі необхідні характеристики в залежності від типу робіт. Процесор, встановлений в MTS 8000, дозволяє тестувати мережу за заздалегідь встановленими наборами тестів. Внутрішня пам'ять пристрою складає 8МБ. Новою цікавою особливістю є можливість встановлення жорсткого диска ємністю до 6 ГБ. Для зручності та можливості оперативної роботи у MTS 8000 встановлені накопичувачі FDD, CD-RW, а також USB-порти.

- Експертні системи- цей вид систем акумулює людські знання про виявлення причин аномальної роботи мереж та можливі способи приведення мережі у працездатний стан. Експертні системи часто реалізуються як окремих підсистем різних засобів моніторингу та аналізу мереж: систем управління мережами, аналізаторів протоколів, мережевих аналізаторів. Найпростішим варіантом експертної системи є контекстно-залежна help-система. Більш складні експертні системи є так звані бази знань, які мають елементи штучного інтелекту. Прикладом є експертна система аналізу мережі Expert Anаlysis із сімейства продуктів Distributed Sniffer System.

В основі системи лежить унікальна база знань, накопичена фахівцями компанії Network General з 1986 року та заснована на досвіді роботи з користувачами різних мереж та розробках груп Станфордського та Массачусетського університетів, а також компанії Nippon Telephone and Telegraph (NTT).

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

Симптом - подія в мережі, якій адміністратор мережі повинен приділити додаткову увагу (наприклад, фізична помилка при зверненні до вузла мережі або поодинока повторна передача файлу). Необов'язково означає виникнення часткової втрати працездатності, проте за високого рівня періодичності потребує уваги адміністратора.

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

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

Система автоматичного аналізу Expert Analysis базується на унікальній багатозадачній технології аналізу пакетів, яка складається з наступних кроків.

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

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

Стандартизована інформація надходить на групу завдань-експертів. Кожна з цих програм є експертом лише у своїй вузькій галузі, наприклад, знання протоколу взаємодії клієнта з сервером NetWare. Якщо експерт знаходить подію, пов'язану з його областю інтересів, він генерує певний відповідний об'єкт (наприклад, "користувач Guest сервера IBSO") в об'єктно-орієнтованій базі даних про мережу, що називається BlackboardKnowledgeBase, і пов'язує її з відповідними об'єктами нижчого рівня. В результаті виникає деяка складна структура, що відображає всі об'єкти мережі, що відносяться до деякого протоколу, і всі можливі зв'язки між ними на всіх рівнях моделі ISO/OSI.

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

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

Ще одним прикладом ЕС з елементами штучного інтелекту є програма OptiView Protocol Expert, Розроблена компанією Fluke Networks і є представником сімейства розподілених систем аналізу та моніторингу обчислювальних мереж 10/100/1000 Ethernet. Призначення системи, як і Expert Anаlysis, спрямоване на скорочення часу простою та ліквідацію вузьких місць мережі.

Всі виявлені події система класифікує за рівнями мережевої моделі OSI:

Рівень додатків: Excessive ARP, Excessive BOOTP, NFS retransmission, all ICMP errors, HTTP Get Response, Slow Server Connect, Slow Server Response;

Транспортний рівень: TCP/IP checksum error;

Мережевий рівень: duplicate IP або IPX address, IP TTL expiring, IP ilegal source address, ISL Ilegal VLAN ID, unstable MST, HSRP coup/resign;

Канальний рівень: ilegal MAC джерела адреси, broadcast/multicast storms, фізичних errors.

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