Боремося з широкомовним штормом

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

Отже, продовжимо з місця "обриву" :) Після того, як мережа практично повністю "лягла", я почав йти від її центру (нашого керованого комутатора в серверній) по кабелю, який був підключений до 19-му порту пристрою. Структуру мережі на роботі я, так-сяк, знаю (іноді, вона мені навіть сниться в важких сновидіннях) тому через два проміжних світча я опинився в одній комірчині "тата Карло", біля старенького, але якісно виконаного, 16-ти портового хаба ( концентратора) від фірми «Compex», на якому явно спостерігалися колізії.

Ось - фото крупнішим планом, щоб було добре видно, про що я говорю:

Боремося з широкомовним штормом

Як бачите, індикатор «Collision» постійно "горить" червоним!

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

Примітка. аплинк (uplink) - порт світча, підключений до магістрального кабелю (тому кабелю, який якщо перерізати, то - капець всьому Інтернету на роботі) :) Також аплінком може називатися порт, підключений кабелем до наступного свитчу, роутера і т.д. Або - сам кабель, каскадом з'єднує всі активне комутаційне обладнання в локальній мережі.

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

Якщо чесно, я не розумію виробників дешевих комутаторів (щоб не образити останніх - "пристроїв початкового класу") :) Їм що важко зробити додатковий індикатор, який би вказував на наявність колізій і проблем в лінії або - на самому пристрої? Чомусь всі 5-ти і 8-ми портові моделі до 50-ти доларів позбавлені цього! Тільки «Power» і - все!

Боремося з широкомовним штормом

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

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

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

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

Потім, мабуть, - економити почали:

Боремося з широкомовним штормом

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

  1. G - (Green - зелений) - Tx (transmit - передача)
  2. Y - (Yellow - жовтий) - Rx (receive - режим отримання даних)
  3. O - (Orange - помаранчевий) - Col (collision - колізія)
  4. R - (Red - червоний) - Pol (polar - перепутана полярність підключення контактів кабелю "вита пара")

На нижній - тільки стандартний на сьогодні Link / Akt (один діод з двома станами). Перше Link (Lnk) - позначає наявність линка (грубо кажучи - підключення мережевого кабелю), при цьому індикатор просто постійно світиться. Друге Akt - активність обміну даними по мережі (індикатор блимає). Риторичне питання: чи багато корисного можна дізнатися з подібною "світломузики". )

А ось - ще одне фото, гігабітного мережного адаптера фірми «ATI»:

Боремося з широкомовним штормом

Тут на кожен режим роботи (10, 100 і 1000 мегабіт в секунду) - свій індикатор.

Отже, дядько пам'ятає, де він зупинився і що хотів сказати, тому - продовжуємо. ) Висмикнувши черговий лінк (мережевий кабель) з хаба, я побачив що індикатор колізії погас, а колега, який тримає руку "на пульсі" нашого керованого комутатора D-Link, повідомив: "трафік - в нормі!".

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

Треба сказати, що комп'ютер цей взагалі рідко використовувався і, в основному, виступав в ролі принт-сервера для знаходиться поруч з ним ПК. Насамперед, підійшовши до системного блоку. я витягнув кабель з його мережевої карти (колізії припинилися), вставив кабель - почалися знову. Як каже в подібних випадках один мій знайомий байкер: «Щасливий кінець знайдений! »:)

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

Почнемо з першого: можливі причини виникнення широковещательного шторму.


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

Друга особливість, яка і призводить до лавиноподібного або поступового (як пощастить) наростання сміттєвого трафіку в мережі - аж до повного її ступору, полягає в тому, що в заголовку пакетів канального рівня (Ethernet) не вказано час життя пакета, як у випадку з IP пакетами (рівень мережевої).

Примітка. часом життя пакета даних називається поле TTL - (time to live), яке зменшується на одиницю з проходженням кожного нового маршрутизатора на шляху проходження пакету.

Є навіть такий бородатий анекдот:

Хлопчик сказав мамі: "Я хочу їсти".
Мама відправила його до тата.
Хлопчик сказав татові: "Я хочу їсти".
Папа відправив його до мами.
Хлопчик сказав мамі: "Я хочу їсти".
Мама відправила його до тата.
І бігав так хлопчик, поки в один момент не впав.
Що трапилося з хлопчиком? TTL скінчився

За значенням цього поля можна побічно визначити, наскільки далеко знаходиться від нас той чи інший віддалений хост. Давайте розглянемо це на простому прикладі використання команди «ping». На фото нижче я запустив її до трьох різних серверів в мережі: (фото нижче - клікабельно)

Боремося з широкомовним штормом

На фото вище ми першою позицією бачимо приклад передачі пакетів (команда ping) між сервером yandex.ru (час життя TTL тут зменшилася до 57-ми одиниць). Трохи нижче - відповідь від сервера нашого місцевого провайдера ukrtelecom.ua (тут час життя більше, тому що сам сервер знаходиться ближче до мене, на Україні, - TTL одно 122 одиниці). І останній запис: ping 172.16.1.1 це - відповідь від маршрутизатора Cisco, який розташовується в нашій локальній мережі на роботі. Оскільки пакет через нього не пройшов, то у відповіді проставлено початкова (вихідна) значення поля TTL - 255 одиниць.

Ось ще один приклад:

Боремося з широкомовним штормом

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

Відразу скажу, що ми свій центральний керований комутатор D-Link DES-3550 з самого початку не конфігурували для боротьби з широкомовним штормом (тому мережа і "впала"), але після цього випадку - вжили відповідних заходів. Ось зараз про це і поговоримо!

Розберемо більш детально одну з секцій налаштувань нашого комутатора другого рівня. Нас буде цікавити пункт «Traffic Control»: (клікабельно)

Боремося з широкомовним штормом

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

У наступній сходинці «Action» (дія) вибираємо що потрібно зробити при виявленні broadcast storm? Тут - два варіанти: «drop» (відкидати широкомовні пакети) і «shutdown» (повністю відключити порт). Для себе ми вибрали перший варіант.

І ще одна важлива рядок, на яку треба звернути увагу «Treshold (pps)» (поріг PPS - packet per second - пакетів в секунду). Це - гранично допустиме значення кількості пакетів, які потрапляють на порт комутатора за одну секунду. Тут за умовчанням встановлено число в 128 000 пакетів.

Хочете дізнатися чому саме це значення? Давайте розбиратися разом. )

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

  • 14 880 пакетів / сек на порт зі швидкістю роботи 10 Мб / с
  • 148 800 пакетів / сек на порт зі швидкістю роботи 100 Мб / с
  • 1 148 800 пакетів / сек на порт в 1000 Мб / с (1 гігабіт)


Це - межа самої технології Ethernet, та й свитч, швидше за все, почне "захлинатися" приходять з такою інтенсивністю пакетами. З огляду на, що наш керований комутатор D-Link це 100 мегабітні пристрій (його межа - значення в 148 800), то і цифра, проставлена ​​в поле «Treshold» (поріг) тепер виглядає досить логічною: трохи менше максимуму (128 000).

Після того, як ми натиснемо кнопку «Apply» (застосувати), весь вхідний трафік, який перевищить цифру 128 000 пакетів в секунду буде просто відкидатися.

Це - необхідна робота на перспективу! А в нашому випадку, боротьба з широкомовним штормом, причиною якого була несправна мережева карта, закінчилася тим, чим і повинна була - її заміною. Зараз графік завантаження порту під номером 19 виглядає ось так: (клікабельно)

Боремося з широкомовним штормом

Всього 3% від максимуму. Це - його нормальний штатний режим роботи.

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

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

До стандартних методів управління трафіком відносяться такі прийоми як: «Метод зворотного тиску на вузол» (backpressure) і «Метод захоплення середовища». Давайте коротко їх розглянемо!

У комутатора завжди є можливість впливати на кінцевий вузол з допомогою правила алгоритму доступу до середовища, який кінцевий вузол зобов'язаний дотримуватися (пам'ятаєте про CSMA / CD?). Точніше, вплив відбувається за допомогою усіляких, найбезсовісніших, порушень цих правил. ) Кінцеві вузли (комп'ютери) строго дотримуються всі приписи, описані в стандарті алгоритму доступу до середовища, а ось комутатори - немає!

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

Другий метод "гальмування" хоста заснований на так званому агресивній поведінці порту комутатора при захопленні середовища. Давайте, розглянемо і його!

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

Що ще нам потрібно запам'ятати наостанок? Те, що надійною перешкодою на шляху широкомовного шторму стають маршрутизатори (роутери). Вони просто ігнорують весь широкомовний трафік канального рівня і не передають його в сусідню мережу або її сегмент. Але це вже - зовсім інша історія :)

Боремося з широкомовним штормом