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

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук

Типові помилки в кадрах

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

Помилки в кадрах, зв'язані з колізіями

Нижче наведені типові помилки, викликані колізіями, для кадрів протоколу 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.



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

Отримано з https://wiki.cusu.edu.ua/index.php?title=Типові_помилкові_ситуації:_вплив_на_продуктивність_та_діагностика&oldid=55963