Боремося з широкомовним штормом
Сьогодні у нас - продовження попередньої частини статті, присвяченій поняттю широкомовний шторм. І я Вам розповім, як ми боролися з цим явищем у себе в робочій мережі.
Отже, продовжимо з місця "обриву" :) Після того, як мережа практично повністю "лягла", я почав йти від її центру (нашого керованого комутатора в серверній) по кабелю, який був підключений до 19-го порту пристрою. Структуру мережі на роботі я, сяк-так, знаю (іноді, вона мені навіть сниться у важких сновидіннях) тому через два проміжних світча я опинився в одній комірчині "папи Карло", біля старенького, але якісно виконаного, 16-ти портового хаба (концентратора) від фірми «Compex», на якому явно спостерігалися колізії.
Ось - фото крупним планом, щоб було добре видно, про що я кажу:
Як бачите, індикатор «Collision» постійно горить червоним!
Проходячи по мережі, і перебуваючи в режимі телефонного зв'язку зі своїм колегою, який віддалено моніторив центральний комутатор, я відключав (і включав назад) кожен світч, зустрічався мені на шляху. Таки чином, колега міг бачити, як колізії зникають і знову з'являються, а я розумів, що причина не в цьому сегменті мережі і йшов далі.
Діставшись до останнього ланки (концентратора), до якого було підключено всього два комп'ютери, розташовані в сусідніх приміщеннях і аплінк, я відключив і його. "Широкомовний шторм пропав" почув я у трубці голос колеги. Такс, якщо я добрався до останньої ланки в "гілці" локальній мережі і, при його відключенні, розсилка широкомовних пакетів припинилася, то тут, навскидку, - три варіанти:
Примітка: аплінк (uplink) - порт світча, підключений до магістрального кабелю (тому кабелю, що якщо перерізати, то капець всьому Інтернету на роботі) :) Також аплинком може називатися порт, підключений кабелем до наступного перемикач, роутеру і т. д. Або - сам кабель, каскадом з'єднує всі активне комутаційне обладнання в локальній мережі.
Перевірити перший варіант, зі списку вище, ми можемо методом виключення (або знаходження проблеми) у решти двох. Зараз же - просто починаємо висмикувати з портів по одному мережевому кабелю і дивимося, на якому з них індикатор колізії згасне? Все - логічно!
Якщо чесно, я не розумію виробників дешевих комутаторів (щоб не образити останніх - "пристроїв початкового класу") :) Їм важко зробити додатковий індикатор, який би вказував на наявність колізій і проблем в лінії або на самому пристрої? Чомусь всі 5-ти та 8-ми портові моделі до 50-ти доларів позбавлені цього! Тільки «Power» і все!
Уявляєте, в один не дуже прекрасний момент) може статися, якщо мережа у нас побудована тільки з використанням подібних бюджетних рішень? А це - реальний випадок, який стався на одному з моїх попередніх місць роботи. Комп'ютерна мережа там налічувала понад чотирьохсот комп'ютерів і була спроектована - самим потворним чином. Вірніше, от саме момент "проектування" в ній відсутній геть (скрізь - найдешевші світчі від різних виробників, ніякої кабельної схеми, виконаної хоча б від руки і т. д.)
Як Ви думаєте, що відбулося після виникнення (а це - тільки питання часу) першого широкомовного шторму в мережі? Правильно! Весь наш IT відділ бігав по поверхах і відключав цілі її ділянки, щоб виявити той, який генерує паразитний трафік, що приводить мережу в неробочий стан. У відсутність керованих комутаторів і індикаторів колізій на свитчах це - єдино можливий варіант розвитку подій!
Не хотів би нагадувати буркотливого старого, але скажу цю фразу: от раніше було зовсім по іншому! :)
На нормальній мережевий карті вендором встановлювалися різні світлодіоди, в роботі яких можна було з легкістю визначити, в якому режимі, на якій швидкості працює карта, чи немає з ним проблем і т. д.?
Потім, мабуть, - почали економити:
На фото вище ми бачимо, що дві карти одного класу кардинально відрізняються набором світлодіодних індикаторів. На верхній їх цілих чотири:
На нижній - тільки стандартний на сьогодні Link/Akt (один діод з двома станами). Перше Link (Lnk) - позначає наявність лінка (грубо кажучи - підключення мережевого кабелю), при цьому індикатор просто постійно світиться. Друге Akt - активність обміну даними по мережі (індикатор блимає). Риторичне питання: чи багато корисного можна дізнатися з подібної "світломузики"? :)
А ось - ще одне фото, гігабітного мережного адаптера фірми «ATI»:
Тут на кожен режим роботи (10, 100 і 1000 мегабіт в секунду) - свій індикатор.
Отже, дядько пам'ятає, де він зупинився і що хотів сказати, тому продовжуємо! :) Висмикнувши черговий лінк (мережевий кабель) з хаба, я побачив що індикатор колізії згасло, а колега, який тримає руку "на пульсі" нашого керованого комутатора D-Link, повідомив: "трафік - в нормі!".
Ми знайшли остання ланка в ланцюзі (той єдиний лінк, що генерує широкомовний трафік). Залишилося пройти по ньому і опинитися біля комп'ютера, який і став причиною всього цього неподобства!
Треба сказати, що цей комп'ютер взагалі рідко використовувався, в основному, виступав у ролі принт-сервера, що знаходиться поруч з ним ПК. Першим ділом, підійшовши до системного блоку, я витягував кабель з мережевої карти (колізії припинилися), вставив кабель - почалися знову. Як каже в таких випадках один мій знайомий байкер: «Щасливий кінець знайдений!» :)
Отже, розслідування ми провели, наслідки проблеми у повній мірі відчули, тепер хотілося б відповісти на два таємних питання: "хто винен?" (причини виникнення широкомовного трафіку і колізій в мережі) і "що робити?" (які існують заходи захисту від цього явища).
Почнемо з першого: можливі причини виникнення широкомовного шторму.
Оскільки перший варіант сьогодні - не наш, другий - не схоже, залишається - третій. Залізна логіка! :) Іноді трапляється так, що мережева карта, замість того щоб спокійно "померти", починає з максимально доступною їй швидкістю розсилати по всій мережі широкомовні пакети.
Це - широкомовний трафік канального рівня, а він має свої особливості. По-перше, він поширюється не тільки в межах одного домену колізій, але і в межах всієї мережі, побудованої з використанням комутаторів і повторювачів (хабів). Принципи роботи цих пристроїв зобов'язують їх передавати кадр з широкомовним адресою (пам'ятаєте: FF-FF-FF-FF-FF-FF) на всі порти, крім того, звідки цей кадр прийшов. Що з цього виходить, ми розглядали в попередній частині статті.
Друга особливість, яка і призводить до лавиноподібного або поступового (як пощастить) наростання сміттєвого трафіку в мережі - аж до повного ступору, полягає в тому, що в заголовку пакетів канального рівня (Ethernet) не зазначено час життя пакету, як у випадку з IP-пакетами (мережевий рівень).
Примітка: часом життя пакету даних називається поле TTL - (time to live), яка зменшується на одиницю з проходженням кожного нового маршрутизатора на шляху проходження пакету.
Навіщо воно потрібно? А саме для того, щоб пакети, які не можуть знайти свого адресата, вічно, як неприкаяні, не блукали по лініях зв'язку і не займали їх смугу пропускання. Спочатку (на виході кадру з мережевого адаптера комп'ютера) полю TTL присвоюється значення 255, і при кожному "стрибку" (хоп) через новий маршрутизатор з нього віднімається одиниця. Якщо при просуванні пакету значення TTL зменшиться до нуля, то такий пакет, просто, відкидається на наступному маршрутизаторі (кажуть, що його час "життя" минув).
Є навіть такий бородатий анекдот:
Хлопчик сказав мамі: "Я хочу їсти".
Мама відправила його до тата.
Хлопчик сказав татові: "Я хочу їсти".
Папа відправив його до мами.
Хлопчик сказав мамі: "Я хочу їсти".
Мама відправила його до тата.
І бігав так хлопчик, поки в один момент не впав.
Що сталося з хлопчиком? TTL скінчився
За значенням цього поля можна побічно визначити, наскільки далеко знаходиться від нас той чи інший віддалений хост. Давайте розглянемо це на простому прикладі використання команди «ping». На фото нижче я запустив її до трьох різних серверів у мережі. (фото нижче - кликабельно)
На фото вище ми першою позицією бачимо приклад передачі пакетів (ping) між сервером yandex.ru (час життя TTL тут зменшилася до 57-ми одиниць). Трохи нижче - відповідь від сервера нашого місцевого провайдера ukrtelecom.ua (тут час життя більше, тому що сам сервер знаходиться ближче до мене, на Україні, - TTL одно 122 одиниці). І остання запис: ping 172.16.1.1 це - відповідь від маршрутизатора Cisco, який розташовується в нашій локальній мережі на роботі. Оскільки пакет через нього не пройшов, то у відповіді проставлено початкова (вихідна) значення поля TTL - 255 одиниць.
Ось ще один приклад:
Пингуемый нами сервер знаходиться зі мною в одному місті (Львові) і тому TTL тут такий високий - 252 одиниці. Пакет проходить всього три маршрутизатора (враховуючи той, що стоїть у мене вдома), поки доходить до адресата. Спробуйте протестувати зв'язок з цим сервером від себе (впевнений, що час життя пакету у Вас буде менше) - йому потрібно буде пройти більше вузлів на шляху прямування.
Рухаємося далі! Оскільки, в нештатної ситуації, широкомовний трафік генерується збійних пристроєм безперервно і, само по собі, його виникнення - непрогнозовано, то потрібно вживати адекватні заходи для його придушення або блокування.
Відразу скажу, що ми свій центральний керований комутатор D-Link DES-3550 спочатку не конфигурировали для боротьби з широкомовним штормом (тому мережа і "впала"), але після цього випадку - вжили відповідних заходів. Ось зараз про це і поговоримо!
Розберемо більш детально одну з секцій налаштувань нашого комутатори другого рівня. Нас буде цікавити пункт «Traffic Control»: (кликабельно)
У правій частині вікна ми бачимо налаштування модуля управління і контролю за трафіком. Зокрема, тут ми можемо силами самого комутатора боротися з широкомовним штормом в мережі. Ми повинні запрограмувати комутатор на відповідну реакцію з її боку при виявленні широкомовного шторму на будь-якому з портів. Ось давайте це зробимо!
На фото вище, зверніть увагу на рядок «Storm Type» (тип шторму). Тут зі списку вибираємо «Broadcast», (широкомовна, там є ще «Multicast» - групова розсилка і «Unicast» - однонаправлена передача). У полі «State» (статус) вибираємо «Enable» (задіяти).
У наступній строчці «Action (дія) вибираємо що потрібно зробити при виявленні broadcast storm? Тут два варіанти: «drop» (відкидати широкомовні пакети) і «shutdown» (повністю відключити порт). Для себе ми вибрали перший варіант.
І ще одна важлива рядок, на яку треба звернути увагу «Treshold (pps)» (поріг PPS - packet per second - пакетів в секунду). Це - гранично допустиме значення кількості пакетів, які потрапляють на порт комутатора за одну секунду. Тут за умовчанням встановлено число 128 000 пакетів.
Хочете дізнатися чому саме це значення? Давайте розбиратися разом! :)
Пропускна здатність будь-якого каналу локальної мережі обмежується максимальною ефективною пропускною здатністю використовуваного канального протоколу. Це - логічно! Враховуючи всі тимчасові затримки, необхідні комутатора для буферизації, прийняття рішення про подальше його просування (forwarding) і відправлення надійшло кадру в мережу, ми маємо точне максимальне значення кількості пакетів, що припадають на один його порт в одиницю часу.
Це - межа самої технології Ethernet, так і світч, швидше за все, почне "захлинатися" приходять з такою інтенсивністю пакетами. Враховуючи, що наш керований комутатор D-Link це 100 мегабітні пристрій (його межа - значення 148 800), то й цифра, проставлена в полі «Treshold» (поріг) тепер виглядає досить логічною: трохи менше максимуму (128 000).
Після того, як ми натиснемо кнопку «Apply» (застосувати), весь вхідний трафік, який перевищить цифру 128 000 пакетів в секунду буде просто відкидатися.
Це - необхідна робота на перспективу! А в нашому випадку, боротьба з широкомовним штормом, причиною якого була несправна мережева карта, закінчилася тим, чим і повинна була - її заміною. Зараз графік завантаження порту під номером 19 виглядає ось так: (кликабельно)
Всього 3% від максимуму. Це - його нормальний штатний режим роботи.
Як ми могли переконатися, спеціальні функції комутаторів обмежують кількість широкомовних пакетів у мережі. І кожен вендор (виробник) намагається цей функціонал всіляко розширювати, придумуючи нові заходи боротьби з цією напастю.
Але є і стандартні алгоритми, покликані вирішувати ті ж завдання. Так у 1997-му році був прийнятий стандарт IEEE 802.3 x, для управління потоком даних канального рівня в протоколі Ethernet. Він визначає просту процедуру управління трафіком: наявність двох команд - «призупинити передачу» і «відновити передачу», які, при необхідності, передаються кінцевого вузла.
Причому, ці команди реалізуються на рівні кодів фізичного рівня моделі OSI, тому "зрозумілі" для будь-якого, навіть самого распоследнего, мережевого адаптера :)
До стандартних методів управління трафіком відносяться такі прийоми як: «Метод зворотного тиску на сайт» (backpressure) і «Метод захоплення середовища». Давайте коротко розглянемо їх!
У комутатора завжди є можливість впливати на кінцевий вузол за допомогою правила алгоритму доступу до середовища, який кінцевий вузол зобов'язаний дотримуватися (пам'ятайте про CSMA/CD?). Точніше, вплив відбувається за допомогою усіляких, найбільш безсоромних, порушень цих правил! :) Кінцеві вузли (комп'ютери) строго дотримуються всі приписи, описані в стандарті алгоритму доступу до середовища, а ось комутатори - ні!
Метод зворотного тиску полягає у створенні видимості колізії в сегменті мережі, який дуже інтенсивно генерує трафік. Для цього комутатор, на потрібному порте, виводить jam-послідовність (з першої частини статті ми повинні пам'ятати, що це таке). За фактом - колізії немає, але подібний трюк дозволяє, на деякий час, "заткнути рот" кінцевого комп'ютера :) Подібні "фокуси" світч може робити і тоді, коли перебуває в режимі, близькому до перевантаження і йому потрібен час, щоб розвантажити переповнену чергу внутрішніх буферів портів.
Другий метод "гальмування" хоста заснований на так званій агресивній поведінці порту комутатора при захопленні середовища. Давайте, розглянемо його!
Наприклад, комутатор закінчив передачу чергового кадру і замість технологічної паузи, передбаченої регламентом протоколом, зробив паузу трохи меншу (на кілька мікросекунд) і тут же почав передачу нового кадру. Підключений до комутатора ПК, який не чекав такого "нахабства", просто не зміг отримати доступ до середовища, так як він витримав покладений тайм-аут і виявив після цього, що лінія вже зайнята. Комутатор може користуватися подібними механізмами управління потоком даних на свій розсуд, збільшуючи ступінь своєї "агресивності" в залежності від ситуації.
Що ще нам потрібно запам'ятати наостанок? Те, що надійною перешкодою на шляху широкомовного шторму стають маршрутизатори (роутери). Вони просто ігнорують весь широкомовний трафік канального рівня і не передають його в сусідню мережу або її сегмент. Але це вже - зовсім інша історія :)