Широкомовний шторм

Рекламний блок

Broadcast storm


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

Сьогодні я хочу розібрати з Вами поняття: широкомовний шторм. І на реальному прикладі показати, що буває, коли цей самий Broadcast шторм відбувається?

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

Стали у відділі не кваплячись прикидати варіанти: згадувати, що куди останнім часом підключалося, які кабелі простягалися? Кабельна структура у нас - досить велика, часом такого надивишся! :)

Поки прикидали, виявилося, що мережа почала пропадати і у нас! Команда «ping» показувала величезні часові затримки передачі пакетів, а деякі з них взагалі не знали! Оскільки весь наш IT відділ підключений до центрального комутатора мережі D-Link DES-3550,


Наш центральный коммутатор D-Link DES-3550

до якого сходяться всі основні кабелі передачі даних і підключені всі сервери, то виходило так, що дуже скоро "глюк" поширився далі і вся мережа прийшла у неробочий стан! Але це, все ж, сталося не відразу і ми встигли з'ясувати деякі цікаві подробиці :)

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

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

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

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

Що цікаво: виділений широкомовна адреса присутній як на канальному рівні (на рівні MAC адрес), так і на більш високому - мережевому. На рівні фізичної адресації це буде трансляція MAC адресу FF-FF-FF-FF-FF-FF, а на рівні логічної адресації (IP) адреса може мати вигляд: 192.168.0.255 (для нашої мережі на роботі він - 172.16.255.255).

Примітка: я накидав для Вас таблицю з класами мереж. Хто не в темі, - обов'язково подивіться і вникніть :)

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

Примітка: що таке MAC-адресу ми також розглядали в статті про мережевої карти комп'ютера.

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

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

Що ж є нормою? Вважається, що прийнятна частка широкомовного трафіку повинна складати 10% від трафіку всій мережі. Значення в 20% і вище повинно класифікуватись як нештатна ситуація, що носить назву «широкомовний шторм» (broadcast storm).

У першій частині статті ми з'ясували, що з широкомовним штормом можна боротися за допомогою інтелектуальних керованих комутаторів. Що ми, власне, і спробували зробити у себе в організації! Давайте я зараз наведу підбірку скріншотів з нашого комутатора і покажу Вам основні його параметри. Їх там реально дуже багато, але ті що я відібрав, допоможуть Вам краще зрозуміти, що з себе представляють пристрої подібного класу і як з їх допомогою можна діагностувати широкомовний шторм?

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

Отже, підключаємося до нашого D-Link DES-3550 по мережі:


Веб-интрфейс D-Link DES-3550

В колонці зліва ми бачимо спадне "дерево" налаштувань. Зараз ми знаходимося папці "Configuration" підрозділ "IP Address".

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

Одна з налаштувань дозволяє нам переглянути ARP-таблиці комутатора. ARP (Address Resolution Protocol - протокол визначення адреси вузла). Подібні таблиці потрібні, насамперед, потім, що дозволяють чітко співвіднести IP і MAC адреси сайту. Давайте подивимося на прикладі.

Подивіться на фото нижче:


ARP таблица коммутатора

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

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

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

Подивіться ще на одне фото і його розділ «Port Configuration»:


Скорость работы портов свитча

На ньому ми бачимо, в якому режимі і з якою швидкістю працюють ті чи інші порти нашого комутатора. Зверніть увагу на два з них (під номерами 12 і 13), позначені червоним. Як бачите, обидва вони працюють на швидкості до 10 мегабіт в секунду, хоча всі інші мають швидкість в 100 мегабіт!

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

Наступний пункт «Loopback Detection» (виявлення петлі) дозволяє нам, не бігаючи по всіх поверхах, відстежити освіта петлі в локальній мережі:


Защита от петлей в сети

Якщо «Loop Status» - normal, значить - все в порядку :)

У комутатора D-Link DES-3550 є набір різних моніторів, які в режимі реального часу можуть показати нам той чи інший параметр або значення навантаження. На фото нижче, ми бачимо графік використання (utilization) центрального процесора пристрою (у середньому навантаження становить 19%).


Загрузка процессора коммутатора

Є також дуже наочні лічильники по кожному з 50-ти портів, на яких ми можемо побачити ступінь завантаження кожного з них, з'ясувати, трафік якого характеру за ним передається (широкомовна, групова передача, тільки одного вузла і т. д.)

Ось, наприклад, як виглядає подібний графік для порту комутатора під номером 11:


Unicast трафик на одном из портов

Бачимо, що порт №11 завантажений наполовину Unicast трафік (адресованим лишень одному ПК). Чому так відбувається? Справа в тому, що саме на нього у нас знаходяться декілька IP камер, які ведуть трансляцію, і один мережевий відеореєстратор (DVR), які генерують такий потужний потік даних. Всі ці відео потоки потім зводяться один потужний сервер відеоспостереження, де і зберігаються на його жорсткі диски.

Але це так - до слова :) Повертаємося до нашого випадку: широкомовні пакети і широкомовний шторм! Під "прицілом" у нас, якщо пам'ятаєте, - 19-й порт комутатора! Саме він знаходиться в стані перевантаження і саме на ньому ми бачимо велику кількість колізій.

На скріншоті нижче - спостерігаємо однозначне наявність колізій: параметр coll (фіолетовий графік)


Пример коллизии

Давайте тепер подивимося на загальну завантаження порту №19. Зверніть увагу, що просто натиснувши на графічному зображенні комутатора по відповідному порту, можна відразу ж побачити його графік в середній частині вікна (дуже зручно!):


Перегрузка порта

Все це - в секції «Monitoring», підрозділ «Port Utilization».

Як бачите, порт постійно завантажений на 50% (це - дуже багато для транк, до якого підключений тільки один комп'ютер)!

Ось скріншот, зроблений десь через 15-20 хвилин після виникнення широкомовного шторму у нас в мережі:


Широковещательный шторм

Бачимо, що "кардіограма" графіка стала більш розмашисто, завантаження опускається до 20-ти відсотків і тут же - "злітає" до 70-ти і поступово зростає! Це - явна ознака того, що в мережі почався широкомовний шторм. Мережа поступово наповнюється широкомовними пакетами, яких стає все більше, і приходить в неробочий стан. Чому відбувається саме так - читайте в наступній статті!

Заради експерименту, продовжили чекати. Мережа "лягла" повністю ще хвилин через 10 :)

Оскільки було зрозуміло, що широкомовний шторм поширюється через порт №19, то залишилося тільки виправити цю ситуацію. Про те, як ми це робили і що зробили, щоб подібних ситуацій не виникало в майбутньому, - читайте в наступній статті!

Також подивіться на модель broadcast storm, яка допоможе Вам краще уявити картину того, що відбувається.





Рекламний блок