3.2 Методика попереджуючої діагностики

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

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

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

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

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

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

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

3.2 Організація процесу діагностики

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

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

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

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

Малюнок 3.5 - Перший спосіб підключення аналізатора

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

Малюнок 3.6 - Другий спосіб підключення аналізатора

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

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

Пропоновану методику ми будемо ілюструвати на прикладі використання чисто програмного аналізатора протоколів Observer компанії Network Instruments - це потужний аналізатор мережевих протоколів і засіб для моніторингу та діагностики мереж Ethernet, бездротових мереж стандарту 802.11 / B / G, мереж Token Ring і FDDI. Спостерігач дозволяє в режимі реального часу вимірювати характеристики роботи мережі, здійснювати декодування мережевих протоколів (підтримується більше 500 протоколів), створювати і аналізувати тренди характеристик роботи мережі.

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

Перший етап: Вимірювання утилізації мережі і встановлення кореляції між уповільненням роботи мережі і перевантаженням каналу зв'язку.

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

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

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

Щоб визначити, яка ж максимально допустима утилізація каналу зв'язку в кожному конкретному випадку, рекомендується дотримуватися наведених нижче правилам.

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

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

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

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

Правило 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 Не всі вимірювальні прилади правильно визначають загальне число колізій в мережі. Практично все чисто програмні аналізатори протоколів фіксують наявність колізії тільки в тому випадку , якщо вони виявляють в мережі фрагмент , т. е. результат колізії . При цьому найбільш поширений тип колізій - відбуваються в момент передачі преамбули кадру ( т. е до початкового обмежувача кадру ( ЮФО ) . ) - Програмні вимірювальні кошти не виявляють , так вже влаштована набір мікросхем мережевих плат Ethernet. Найбільш точно колізії виявляють апаратні вимірювальні прилади , наприклад LANMeter компанії Fluke.

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

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

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

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

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

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

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

Правило 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-байтной преамбули) з правильною контрольної послідовністю. Найбільш ймовірна причина появи коротких кадрів - несправна мережева плата або неправильно сконфігурований або зіпсований мережевий драйвер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Генерація трафіку дозволяє загострити наявні проблеми і створює умови для їх прояву. Трафік повинен мати невисоку інтенсивність (не більше 100 кадрів / с) і сприяти утворенню колізій у мережі, т. е. містити короткі (<100 байт) кадри.

При виборі аналізатора протоколів або іншого діагностичного засобу увагу слід звернути насамперед на те, щоб обраний інструмент мав вбудовану функцію генерації трафіку задаваемой інтенсивності. Ця функція є, зокрема, в аналізаторах Observer компанії Network Іnstruments та NetXray компанії Сінко (нині Network Associates).

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

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

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

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

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

Таблиця 3.1 - Типи помилок і колізій, що фіксуються вимірювальним засобом для етапів 2 і 3

Причина опомилок	Локальні колізії	Віддалені колізії	Пізні колізії	Короткий кадр	Довгий кадр	Jabber	Помилка CRC
Дефектна мережева плата	>5% при U<30%	>5% при U<30%	Так	Так	Так	Так	Так
Дефективний драйвер плати				Так	Так	Так	Так
Дефектний концентратор, повторювач, трансивер	>5% при U<30%	>5% при U<30%	Так			Так	Так
Неправильне підключення активного обладнання	>5% при U<30%	>5% при U<30%	Так			Так
Занадто довгий кабель			Так				Так
Більше 4 повторювачів або об'єднаних в каскад концентраторів			Так
Неправильне заземлення комп'ютерів або коаксіального кабелю	>5% при U<30%	>5% при U<30%	Так			Так	Так
Дефекти кабельної системи та пасивного обладнання	>5% при U<30%	>5% при U<30%	Так			Есть	Так
Джерело шуму поряд з кабельної системою	>5% при U<30%	>5% при U<30%	Так			Так	Так
Примітка. U - утилізація каналу зв'язку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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