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

  Если помните, в первой части статьи мы говорили о коллизии в локальной сети. Рассматривали механизм и причины ее возникновения и варианты предотвращения. Теперь - другая история:

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

  На днях, неожиданно (как это всегда и бывает) один из участков нашей локальной сети начал жестко "глючить". Из двух отделов, расположенных в нем, стали звонить и жаловаться, что сеть "тормозит", из Интернета периодически "выбрасывает" и прочее в том же духе.

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

  Пока прикидывали, оказалось, что сеть начала пропадать и у нас! Команда «ping» показывала огромные временные задержки передачи пакетов, а некоторые из них - вообще терялись! Поскольку весь наш IT отдел подключен к центральному коммутатору сети 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 по сети:

 

  В колонке слева мы видим раскрывающееся "дерево" настроек. Сейчас мы находимся папке "Configuration" подраздел "IP Address".

  В правой части окна на скриншоте выше можно видеть сетевые настройки коммутатора. Как видим, в нашей локальной сети он имеет IP адрес 172.16.4.13. Естественно, что адрес можно изменить по своему усмотрению, установить пароль доступа, даже - создать несколько пользователей и делегировать им разные права.

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

  Посмотрите на фото ниже:

 

  Что мы здесь видим? В самом верху таблицы - уже знакомый нам широковещательный адрес канального уровня: 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:

 

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

  Но это так - к слову :) Возвращаемся к нашему случаю: широковещательные пакеты и широковещательный шторм! Под "прицелом" у нас, если помните, - 19-й порт коммутатора! Именно он находится в состоянии перегрузки и именно на нем мы видим большое количество коллизий.

  На скриншоте ниже - наблюдаем однозначное наличие коллизий: параметр coll (фиолетовый график)

 

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

 

  Все это - в секции «Monitoring», подраздел «Port Utilization».

  Как видите, порт постоянно загружен на 50% (это - очень много для транка, к которому подключен только один компьютер)!

  Вот скриншот, сделанный где-то через минут 15-20 после возникновения широковещательного шторма у нас в сети:

 

  Видим, что "кардиограмма" графика стала более размашистой, загрузка опускается до 20-ти процентов и тут же - "взлетает" до 70-ти и постепенно - растет! Это - явный признак того, что в сети начался широковещательный шторм. Сеть постепенно переполняется широковещательными пакетами, которых становится все больше, и приходит в нерабочее состояние. Почему происходит именно так - читайте в следующей статье!

  Эксперимента ради, продолжили ждать. Сеть "легла" полностью еще минут через 10 :)

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

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