Перегляд вихідного коду сторінки Типові помилкові ситуації: вплив на продуктивність та діагностика

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

* ''Локальна колізія (LocalCollision)''. Є результатом одночасної передачі двох або більше вузлів, які належать до того сегменту, в якому проводяться виміри. Якщо мережевий аналізатор не генерує кадри, то в мережі 10Base-T (на скручений парі) локальні колізії не фіксуються. Занадто високий рівень локальних колізій є наслідком проблем із кабельної системою.

*''Віддалена колізія (RemoteCollision)''. Ці колізії відбуваються на інщій стороні повторювача. Оскільки концентратор 10Base-T є багатопортовим повторювачем, в якому кожен сегмент закріплений за одним вузлом, то всі вимірювані колізії в мережі 10Base-T є видаленими (крім тих випадків, коли аналізатор сам генерує кадри і може бути винуватцем колізії). Не всі аналізатори протоколів і моніторингу однаковим чином фіксують віддалені колізії. Це відбувається через те, що деякі вимірювальні засоби і системи не фіксують колізії, що відбуваються при передачі преамбули.

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

==== Діагностика колізій ====
Середня інтенсивність колізій в нормально працюючій мережі має бути менше 5%. Великі сплески (понад 20%) можуть бути індикатором кабельних проблем.

Якщо інтенсивність колізій більше 10%, то уже треба проводити дослідження мережі.

Рекомендується наступний порядок дослідження:

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

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

У мережі Ethernet на основі коаксіального кабелю в якості причин колізій можуть виступати:

*Занадто велика довжина сегментів (понад 185 метрів для тонкого коаксиала і понад 500 метрів для товстого); 
*Занадто багато підключень до сегменту (понад 30 для тонкого коаксиала); 
*Занадто багато заглушок - необхідно перевірити, щоб сегмент завершувався заглушкою в 50 Ом лише в одному місці (багатопортові повторювачі для коаксіального кабелю зазвичай мають внутрішні заглушки, тому установка зовнішньої заглушки для них є зайвою); *Неправильное заземлення - кожен коаксіальний сегмент має заземлення лише в одній точці.

Причинами колізій в мережі Ethernet на кручений парі можуть бути:

*Занадто велика довжина сегментів (понад 100 метрів); 
*Порушення правил 4-х хабів; 
*Неправильне з'єднання контактів пар кабелю; 
*Некоректно працюють порти концентратора чи мережні адаптери; 
*Погані з'єднання в кросових секціях.

==== Помилки кадрів Ethernet, пов'язані з довжиною і неправильною контрольною сумою  ====
*Укорочені кадри (Shortframes). Це кадри, які мають довжину, менше допустимої, тобто менше 64 байт. Іноді цей тип кадрів диференціюють на два класи - просто короткі кадри (short), в яких є коректна контрольна сума, і "коротишки" (runts), що не мають коректної контрольної суми. Найімовірнішими причинами появи коротких кадрів є несправні мережні адаптери та драйвери.

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

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

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

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

Іншою причиною некоректної роботи протоколів може бути неузгодженість протоколів різного рівня в одному і тому самомущо  вузлі, наприклад, протоколів FDDI і IPX, що розроблені у розрахунку на різні інтерфейси міжрівневої взаємодії в стеку, FDDI - а інтерфейс NDIS, а IPX - на інтерфейс ODI. 
[[Файл:98769876.gif]]

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

Усього є чотири популярних стандарти формату кадру Ethernet: 
*Кадр Ethernet DIX (або кадр Ethernet II);
*Кадр стандарта 802.3(або кадр Novell 802.2);
*Кадр Novell 802.3 (або кадр Raw 802.3);
*Кадр Ethernet SNAP.

Кадр стандарту EthernetDIX, званий також кадром EthernetII, розроблений компаніями Digital, Xerox і Intel (перші літери назви компаній і дали назву цьому варіанту Ethernet) при створенні перших мереж Ethernet. Всього було випущено дві версії фірмового стандарту Ethernet, тому остання, друга версія цього стандарту також іноді вказується при позначенні варіанту протоколу Ethernet і відповідно його формату кадру. Часто в літературі саме цей варіант формату кадру називають кадром Ethernet, залишаючи для міжнародного стандарту технології EthernetIEEE 802.3 позначення 802.3.

Кадр стандарту EthernetDIX має наступний формат:
[[Файл:987789.jpg]]

Поля Destination і Source містять 6-ти байтним МАС-адреси вузла призначення і джерела, а поле Type - двухбайтного ідентифікатор протоколу верхнього рівня, який помістив свої дані в полі даних Data. Для поля Type існують стандартні значення числових ідентифікаторів для всіх популярних протоколів, що використовуються в локальних мережах. Наприклад, протокол IP має числовий ідентифікатор 0800 і т.п. Ці значення можна знайти у постійно оновлюваному RFC (наприклад, в RFC 1700), в якому Уаза всі конкретні числові значення, що застосовуються в протоколах мережі Internet.

У стандарті IEEEEthernet 802.3 визначений формат кадру Ethernet, близький до формату EthernetDIX, але має деякі відмінності:
[[Файл:9877890.jpg]]

Одне з принципових відмінностей полягає в тому, що замість поля Type у ньому використовується поле Length (Довжина), також має розмір 2 байти, але містить довжину поля даних в байтах.

Поле Type встандарте 802.3 замененодвумядополнительнымиполями - DSAP (Destination Service Access Point) і SSAP (Source Service Access Point). Поле DSAP вказує сервіс (протокол), якому призначаються дані, а поле SSAP позначають сервіс (протокол), який відправив ці дані. Призначення цих полів те ж, що і поля Type, але наявність двох полів дозволяє організувати передачу даних між протоколами різного типу (правда, на практиці ця властивість ніколи не використовується). Однобайтовий формат полів SAP не дозволив використовувати в них ті ж числові позначення ідентифікаторів протоколів, які прижилися для кадрів EthernetDIX, тому кожен протокол верхнього рівня має зараз два ідентифікатора - один використовується при інкапсуляції пакета протоколу в кадр EthernetDIX, а другий - при інкапсуляції в кадр Ethernet 802.3.

Ще однією відмінністю кадру IEEE 802.3 є однобайтове поле Control (Управління), яке призначене для реалізації режиму роботи з встановленням соедінененія. У поле Control повинні міститися номери кадрів квитанцій підтвердження доставки даних, необхідні для відпрацювання процедур відновлення загублених або перекручених кадрів. На практиці більшість операційних систем не використовує цих можливостей кадру 802.3, обмежуючись роботою в дейтаграмному режимі (при цьому значення поля Control завжди дорівнює 03).

Так як стандарт IEEE ділить канальний рівень на два підрівня - MAC і LLC, то іноді кадр Ethernet 802.3 також представляють як композиції двох кадрів. Кадр МАС-рівня включає поля преамбули, адрес призначення і джерела, поле довжини і поле контрольної суми, а кадр LLC містить поля DSAP, SSAP, Control і поле даних (яке через введення нових трьох однобайтових полів має максимальну довжину на 3 байти менше ).

Кадр Novell 802.3, який також називають кадром Raw 802.3 (тобто "грубий" або "очищений" варіант стандарту 802.3) являє собою кадр МАС-рівня без полів рівня LLC:

[[Файл:98778900.jpg]]

Цей тип кадру тривалий час успішно застосовувався компанією Novell в її мережах NetWare. Відсутність поля типу протоколу верхнього рівня не створювало труднощів, так як в мережах Novell довгий час використовувався лише один протокол мережевого рівня - протокол IPX. Надалі при переході до багатопротокольним мереж компанія Novell стала використовувати як основного стандартний кадр IEEE 802.3 (який в документації Novell називається кадром 802.2 - номер стандарту на підрівень LLC).

Кадр EthernetSNAP (SubNetworkAccessProtocol) активно використовується в мережах TCP / IP для досягнення сумісності числових ідентифікаторів протоколів з тими, які використовуються в кадрі EthernetDIX. Кадр EthernetSNAP визначений у стандарті 802.2H і являє собою розширення кадру IEEE 802.3 шляхом введення двох додаткових полів: 3-х байтового поля OUI (OrganizationUnitIdentifier) і двухбайтового поля Type. Поле Type має той же формат і те ж призначення, що і поле Type кадру EthernetDIX. Тому числові значення ідентифікаторів протоколів, що поміщаються в це поле кадру EthernetSNAP, збігаються зі значеннями, що використовуються в кадрах EthernetDIX, і в цьому весь сенс введення додаткових полів заголовка SNAP. У полі OUI вказується код організації, яка определеяется стандартні значення для поля Type. Для протоколу Ethernet такою організацією є комітет IEEE 802.3, і його код дорівнює 00 00 00. Наявність поля OUI дозволяє використовувати заголовок SNAP не тільки для протоколу Ethernet, а й для інших протоколів, які контролюються іншими організаціями.

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

Багато сучасні операційні системи та комунікаційне обладнання вміють одночасно працювати з різними типами кадрів, розпізнаючи їх автоматично. Розпізнавання йде за значенням 2-х байтового поля, розташованого за адресою джерела. Це поле може бути полем Type або Length. Числові ідентифікатори протоколів вибрані так, що значення поля Type буде завжди більше 1500, в той час як поле Length завжди містить значення менше або рівне 1500. Подальше відділення кадрів EthernetSNAP від IEEE 802.3 проводиться на підставі значення полів DSAP і SSAP. Якщо присутній заголовок SNAP, то поля DSAP і SSAP завжди містять цілком певний числовий ідентифікатор, зарезервований за протоколом SNAP.

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

Мережеві аналізатори та засоби моніторингу вміють автоматично розрізняти формати кадрів Ethernet. Для завдання умов захоплення кадрів, що містять пакети певних протоколів верхнього рівня, аналізатори дозволяють користуватися як числовими ідентифікаторами цих протоколів для полів SAP (DSAP і SSAP), так і числовими ідентифікаторами для поля Type (які мають також назву EtherType).

У мережах TokenRing і FDDI завжди використовуються кадри стандартного формату, тому в цих мережах не виникають проблеми, пов'язані з несумісністю форматів кадрів.

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

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

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

==== Помилки кадрів Ethernet у стандарті RMON====
Стандарт RMON визначає такі типи помилок кадрів Ethernet:

etherStatsCRCAlignErrors - загальне число отриманих пакетів, які мали довжину (виключаючи преамбулу) між 64 і 1518 байтами, не містили ціле число байт (alignmenterror) або мали невірну контрольну суму (FCSerror).

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

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

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

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

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

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

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

Для забезпечення сумісності протоколів маршрутизації розроблені спеціальні протоколи, які передають маршрутні дані між різними частинами мережі в уніфікованому форматі. До таких протоколів відносяться протокол EGP (ExteriorgatewayProtocol) і його пізніша модифікація BGP (BorderGatewayProtocol), розроблені і вживані в мережі Internet. Вони можуть переносити знання про мережі між протоколами RIP, OSPF, NLSP, IS-IS та іншими.

Однак, тільки застосування протоколів типу EGP або BGP не вирішує проблем роботи гетерогенної щодо протоколів маршрутизації мережі. Знання про будь-якої мережі можуть надійти від різних частин мережі, і, відповідно, від різних протоколів. У таких випадках для стійкої роботи мережі потрібно віддавати пріоритет більш надійно працюють в умовах зміни топології протоколах типу "стан зв'язків", таких як OSPF, NLSP і IS-IS. Багато маршрутизатори дозволяють задавати пріоритети одних протоколів маршрутизації перед іншими.

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

У мережах TCP / IP помилкові ситуації, що фіксуються маршрутизатором при неможливості передати пакет в мережу призначення, повідомляються кінцевому вузлу службовим протоколом ICMP, пакети якого обов'язково потрібно аналізувати у великих мережах, що використовують маршрутизатори.
====Неіснуюча адреса і дублювання адрес ====
Відправлення пакета за неіснуючим адресою природно не може привести до нормального взаємодії вузлів в мережі. Неіснуючі адреси можуть з'явитися в мережі тільки в тому випадку, коли вони зберігаються постійно в базі даних стека протоколів (наприклад, в базi служби DNS стека TCP / IP або служби NDS мереж NetWarе). При цьому може наступити момент, коли зберігається адреса застаріє і не буде відповідати дійсності.

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

Серйозні проблеми в мережі створює дублювання адрес, тобто наявність у мережі двох вузлів з одним і тим ж адресою. Така ситуація найчастіше призводить до недосяжності обох вузлів з однаковою адресою, або ж до порушення нормальної роботи всієї мережі, якщо дублюються не адреси вузлів, а адреси мереж (IP або IPX). Проблема дублювання адрес характерна більшою мірою для адрес верхніх рівнів, починаючи з мережевого, де адреси призначаються адміністратором і тому можуть повторюватися в результаті людських помилок. Адреси канального рівня (МАС-адреси) присвоюються мережевим адаптерам, портам маршрутизаторів і агентам [[SNMP]]-управління компаніями-виробниками, тому їх дублювання малоймовірно (тільки у випадку перепризначення адреси, що можливо шляхом його програмування).

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

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

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

Однак, не тільки протокол SDLC чутливий до тимчасових затримок передачі пакетів. Багато протоколів, що працюють в режимі логічного з'єднання, мають таку властивість. Наприклад, протокол TCP стежить за цілісністю логічного з'єднання шляхом встановлення спеціального таймера, який встановлюється під час поселення чергового TCP-повідомлення. Якщо таймер минає раніше, то сесія TCP розривається, що призводить до розриву сесії протоколу прикладного рівня, наприклад, FTP. Так як протокол FTP не володіє властивістю продовження передачі файла з перерваного місця після розриву і повторного встановлення з'єднання, то розриви сесії TCP можуть призводити до того, що файл обсягом у кілька мегабайт, який був переданий майже повністю, доведеться передавати заново. Подібна ситуація іноді зустрічається в мережі Internet, коли завантаженість FTP-сервера або маршрутизаторів призводить до значних затримок відправки чергового TCP-повідомлення. Для запобігання розривів у протоколі TCP передбачена можливість генерації пакетів keepalive в той час, коли відсутні дані користувача для передачі, проте цей режим є опціональним і не всі реалізації стека TCP / IP його підтримують.

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

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

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

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

[[category:Комп'ютерні мережі]]