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


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, которая поможет Вам лучше представить картину происходящего.


 


Понравилась статья?
Нажмите на кнопки ниже или оставьте комментарий !


Андрей
А такие устройства как демаркационные устройства Ethernet помогут основную сеть провайдера защитить?

[Ответить]
Андрей
Думаю, при правильной настройке, - да.

[Ответить]
Виктор Василич
Зачетная статья по сетевым технологиям!

[Ответить]
Андрей
Спасибо! Ссылка не по теме (я удалил).

[Ответить]
MariaMiller
Андрей, хочу выразить Вам искреннюю благодарность за Ваш труд в таком сложном деле как передача знаний, к тому еще в таком прекрасном формате. Очень полезные статьи, очень рада, что нашла Ваш сайт. Вы действительно герой  :like:

[Ответить]
Андрей
Искренне рад, что наш сайт Вам понравился! Заходите при случае   !;)

[Ответить]
Александр
Автору очень повезло, что свитч управляемый. Сегодня увлекательная беготня 1.5 часа была, пока не разобрался какой сегмент сеть вешает.

[Ответить]
Андрей
Да, у нас начальство любит чтобы все можно было удаленно настроить. Вообще не вставая с табуретки  =)

[Ответить]
Асылбек
Как доступно и понятно все объяснено. Большое спасибо!  :)

[Ответить]
Андрей
Пожалуйста, Алылбек. Заходите к нам еще и приглашайте друзей   !;)

[Ответить]
Дима
Я студент. Через год надо устраиваться на работу, сисадмином, а я в нем почти ноль. Поднял свои знания благодаря этому сайту  :) Андрей - Вы герой  :)
А статьи про почтовые сервера будут? Ну там sendmail, postfix, exim...

[Ответить]
Андрей
Спасибо, Дмитрий за положительный отзыв о нашем сайте. За "героя" - отдельное! По поводу NIX систем и почтовых серверов для них - вся надежда на Вадима (раздел по Linux/Unix)

[Ответить]
Артем
Статья,как в сериалах на самом интересном месте-конец

[Ответить]
Андрей
Ну, так нажмите ссылку "продолжение" и - читайте дальше!   !;)

[Ответить]
Эльдар
Андрей, спасибо! Очень интересные статьи. Только вот жаль, что еще не активна ссылка на третью статью. Хорошо, что приходят на почту сообщения о новых статьях. Всего доброго.

[Ответить]
Андрей
Спасибо, Эльдар! Третью часть сейчас пишу, надеюсь, скоро будет готова.

[Ответить]
Георгий Николаевич
Благодарю Вас за статью.Каждая из полученыых статей позволяет всё больше и больше узнать нового и интересного, чего не найдёшь в литературе, особенно когда не знаешь где искать.

[Ответить]
Андрей
Пожалуйста, именно так и задумывалось! Знания, - как слои краски, их нужно наносить постепенно  :)

[Ответить]

Страницы: [1]

Оставить комментарий

Ваше имя:

Комментарий:
Введите символы: *
captcha
Обновить


Поиск по сайту
ФОРУМ нашего сайта !




Ресурсы по теме !