бродкаст шторм что это
«Идеальный шторм» и как это лечится
Broadcast storm (широковещательный шторм) – это такой ночной кошмар сетевиков, когда в считанные секунды парализуется передача полезного трафика во всей сети ЦОД. Как это происходит и о чем надо было раньше думать – в нашем сегодняшнем посте.
Вначале была Ethernet, и не было в ней маршрутизации, и сейчас тоже нету, а посему приходится коммутатору отправлять пакеты данных во все порты – ну, чтобы наверняка. От адресата приходит ответ на определенный порт, коммутатор запоминает соответствие [порт — адресат] и следующая “посылка” отправляется уже не абы куда, а по памятным, так сказать, местам.
Если же ответа нет, а в момент отправки unknown unicast пара-тройка коммутаторов оказываются замкнуты в кольцо, посылка возвращается “отправителю”, который, понятно, снова забрасывает ее во все порты, поскольку ну а что ему еще делать. «Бесхозный» пакет данных опять возвращается и опять улетает. Каждый следующий виток “закольцованного” broadcast flood сопровождается экспоненциальным ростом количества пакетов в сегменте сети. Очень скоро эта лавина «забивает» полосу пропускания портов, на заднем плане красиво «вскипают» перегруженные процессоры коммутаторов – и ваша сеть превращается в памятник самой себе.
Причиной шторма может стать как хакерская атака, так и осечка вашего же инженера при настройке оборудования – или вовсе сбой протоколов. Иными словами, никто не застрахован.
В 2009 году в сети одного из наших клиентов случился бродкастовый шторм, который мгновенно перекинулся к нам, парализовав работу всей сети передачи данных компании. Отвалились почта, телефония и интернет, система мониторинга «сошла с ума» – и стало невозможно даже локализовать «первоисточник». Полная перезагрузка коммутатора не помогла. Нам ничего не оставалось, кроме как последовательно отключать ВСЕ порты, клиентские и свои собственные… Такой вот «черный понедельник».
Как позже выяснилось, один из сотрудников клиента перепутал порты оборудования – и закольцевал свою топологию на уровне бродкастового домена. Бывает.
Понятно, что в группе риска здесь, в первую очередь, коммерческие ЦОДы: резервированное подключение для каждого клиента само по себе уже означает избыточность соединений между коммутаторами. Однако сетевикам корпоративных дата-центров я бы также не рекомендовал расслабляться: замкнуть по рассеянности пару коммутаторов друг на друга можно и в серверной.
Хорошая новость заключается в том, что при грамотной подготовке вы можете отделаться легким испугом там, где в противном случае получили бы простой сервиса.
Начните с сегментирования сети посредством VLAN: когда сеть разбита на мелкие изолированные сегменты (fault domain), шторм, “накрывший” один из участков, этим участком и ограничивается. Ну, в идеале. В действительности мощный шторм, увы, способен “вбрасывать” пакеты и в так называемые независимые виртуальные сети тоже.
По-хорошему здесь нужно отказаться от “закольцованных” VLAN как внутри собственной инфраструктуры, так и при подключении клиентов к сети (если речь о коммерческом ЦОД). Например, использовать протоколы FHRP и U-образную топологию на уровне доступа.
U-образная топология позволяет избежать закольцованности
В ряде случаев, впрочем, от «закольцованности» при всем желании никуда не деться. Скажем, необходимо развернуть отказоустойчивую (2N) инфраструктуру для заказчика с подключением к нашему облаку. Клиентские VLAN’ы здесь приходится «пробрасывать» внутри облачной инфраструктуры между всеми ESXi хостами кластера виртуализации, – то есть само решение подразумевает полное дублирование всех сетевых элементов.
Смотрим в картинку – видим кольцо.
Кольцевая топология возникает при полном резервировании каналов связи и инфраструктуры заказчика
Что делать, если вы – «властелин колец»
Делать можно разное, и у каждого варианта, как водится, — свои преимущества и издержки.
Вот, например, протокол RSTP (модификация SpanningTreeProtocol) умеет быстро – в пределах 6 секунд – находить и «разбивать» бродкастовые петли. Находит он их посредством обмена BPDU (Bridge Protocol Data Unit) сообщениями между коммутаторами, а “разбивает” блокировкой резервных линков. В случае проблем с основным каналом RTSP перестраивает топологию, используя резервный порт.
Хорошая в целом штука, но есть нюанс. Под каждый VLAN выделяется один RSTP-процесс, при этом количество процессов, в отличие от VLAN, сильно ограничено, и при резком росте числа VLAN’ов в рамках одной сетки процессов RSTP может банально не хватить. То есть для корпоративного дата-центра пойдет, а для коммерческого – с постоянно растущим числом клиентов (VLAN) – уже не очень.
На этот случай имеется MSTP – улучшенное и дополненное издание RSTP. Умеет объединять несколько VLAN в один STP процесс (instance), что в хорошем смысле слова сказывается на масштабируемости сети: “потолок” здесь составляет 4096 клиентов (максимальное число VLAN). MSTP также позволяет управлять трафиком, распределяя MST процессы между основным линком и резервным, и дает возможность при необходимости разгружать “загнавшиеся” коммутаторы. Однако с MST нужно уметь работать, то есть это плюс как минимум один недешевый умник в штат (что доступно не всем).
Протоколы RSTP и MST «разрывают» петлю, блокируя трафик по одному из каналов
Из проверенных альтернатив MSTP можем посоветовать FlexLinks от Cisco, который мы используем, когда на стороне клиента находится один коммутатор или стек под единым управлением. FlexLinks умеет резервировать линки коммутатора без применения STP, “назначая” в каждой паре портов основной и резервный. Используется на уровне доступа (access) при подключении оборудования разных компаний по принципу Looped Triangle в коммерческом ЦОД. Очень простой в плане настройки инструмент, что и само по себе приятно, и позволяет рассчитывать на бОльшую стабильность сервиса (по сравнению, например, с STP). Вы полюбите FlexLinks за мгновенное переключение на резервные линки и балансировку нагрузки по VLAN – а потом, возможно, разлюбите за возможность применять его исключительно в топологии Looped Triangle.
В топологии Looped Triangle можно добиться мгновенного переключения трафика между каналами в случае сбоя
Теперь отвлечемся от техники. Любите ли вы экономическую эффективность так же, как люблю ее я? Тогда вам будет интересно узнать, что и MST \ RSTP, и FlexLinks, блокируя резервные линки, фактически исключают половину портов из круговорота трафика в природе.
А вот решения, которые так не делают: Cisco VSS (Virtual Switch System), Nexus vPC (virtual port-channel), Juniper virtual router и другие mLAG-подобные (multichassis link aggregation) технологии. Хороши тем, что задействует все доступные линки, объединяя их в один логический канал EtherChannel. Получается своего рода коммутирующий кластер, в котором модуль управления одного из коммутаторов (Control-plane) “рулит” всеми линками кластера (Data-Plane). В случае выхода текущего Control-plane из строя его полномочия автоматически передаются “оставшемуся в живых”. Мы используем Cisco Nexus vPC для балансировки нагрузки между линками клиентов, у которых по одному коммутатору или стеку. Если же на стороне клиента два отдельных коммутатора, связанных общим VLAN, добавляем в схему STP.
Объединение линков в один логический канал решает проблему со штормами и не сказывается на производительности
Виртуализация, катастрофоустойчивые облачные сервисы, распределенные между дата-центрами, и прочие кластерные решения – все это требует несколько иного подхода к организации Layer 2 сети. Убираем STP на антресоли – достаем TRILL.
TRILL использует механизм маршрутизации на Ethernet-уровне и сама строит свободный от петель путь для бродкастового трафика, тем самым предотвращая возникновение штормов. Ну не чудо ли?:) Еще TRILL позволяет равномерно распределять нагрузку между линками (до 16 линков), объединять распределенные дата-центры в единую L2-сеть и гибко управлять трафиком. TRILL – общепринятый стандарт, у которого быстро появились вендорские варианты: FabricPath от Cisco (который используем мы) и VCS от Brocade. Juniper разработал собственную технологию Qfabric, позволяющую создавать единую Ethernet фабрику.
Какой протокол даст вам 100% защиту от шторма? Правильно, никакой. Поэтому, возможно, вас заинтересуют следующие два инструмента:
• Storm-control
Позволяет установить посекундную “квоту” на количество бродкастовых пакетов, проходящих через один порт. Все, что сверх «квоты», – отбрасывается, и таким образом контролируется нагрузка. Некоторый нюанс заключается в том, что Storm-control не отличает полезный трафик от мусора.
• Control—plane policing (CoPP)
Этакий storm-control для процессора коммутатора. При бродкастовом шторме, помимо прочего, резко возрастает количество ARP-запросов. Когда это количество зашкаливает, процессор загружается на 100% – и сеть, понятно, говорит вам “до свиданья”. CoPP умеет “дозировать” количество ARP-запросов и таким образом управлять нагрузкой на процессор. Неплохо справляется и с броадкастовыми штормами со стороны точек обмена трафиком, и с различными DDoS-атаками — проверено.
Как построить death proof сеть
Итак, какие из возможных вариантов мы проверили на себе и используем в зависимости от вводных:
1. U, V и П-образные топологии + RSTP (MST) + storm control + CoPP.
Базовый набор, в первую очередь, для коммерческого ЦОД, в котором приходится подключать к собственной сети большое количество внешних (неконтролируемых) сетей – и потому крайне желательно не допускать возникновения «петель» вообще.
Если U, V и П-образные топологии не ваш случай, «сокращенный» вариант RSTP (MST) + storm control + CoPP тоже подойдет.
2. Если есть задача максимально использовать возможности оборудования и каналов, присмотритесь к варианту mLAG (VSS, vPC) + storm control + CoPP.
3. Если у вас уже имеется оборудование Cisco или Juniper и нет противопоказаний по топологии, попробуйте комбинацию Flex Links/RTG + storm control + CoPP.
4. Если у вас сложносочиненный случай с распределенными площадками и прочими изысками виртуализации и отказоустойчивости, ваш вариант TRILL + storm control + CoPP.
5. Если вы не знаете, какой у вас случай, – мы можем поговорить об этом:).
Главное – начать делать хоть что-то уже сейчас, даже если вам искренне кажется, что бродкастовый шторм это то, что бывает с другими. В реальности штормы «накрывают» сети самых разных масштабов, а нелепые ошибки совершают даже люди, которые, что называется, двадцать лет в искусстве. «И пусть это вдохновит вас на подвиг» (с).
Широковещательный шторм
Broadcast storm
Сегодня я хочу разобрать с Вами понятие: широковещательный шторм. И на реальном примере показать что бывает, когда этот самый Broadcast шторм происходит?
На днях, неожиданно (как это всегда и бывает) один из участков нашей локальной сети начал жестко «глючить». Из двух отделов, расположенных в нем, стали звонить и жаловаться, что сеть «тормозит», из Интернета периодически «выбрасывает» и прочее в том же духе.
к которому и сходятся все основные кабели передачи данных и подключены все серверы, то получалось так, что очень скоро «глюк» распространился дальше и вся сеть пришла в нерабочее состояние! Но это, все же, случилось не сразу и мы успели выяснить кое-какие интересные подробности 🙂
Давайте немного отвлечемся и определимся с тем, что это за шторм такой широковещательный? Мы уже знаем, что в сети информация передается пакетами. Каждая программа, файл или любые другие данные могут быть представлены в виде последовательности таких пакетов, каждый из которых содержит в себе, кроме всего прочего, адрес узла отправителя и адрес узла получателя.
Но иногда возникает необходимость отправить информацию (какое-то оповещение) сразу всем компьютерам локальной сети. Для этих целей и используются специальный широковещательный адрес. Согласно протоколу (правилам), все устройства в сети должны интерпретировать такой широковещательный адрес, как свой собственный и принимать любые данные, посылаемые на него.
В локальных сетях (таких как Ethernet) MAC адрес позволяет однозначно идентифицировать каждый узел сети и доставлять данные только ему. Таким образом, подобные физические адреса формируют основу сетей на канальном уровне, которую используют протоколы более высокого уровня (сетевого).
Примечание: что такое MAC адрес мы также рассматривали в статье о сетевой карте компьютера.
Что же является нормой? Считается, что приемлемая доля широковещательного трафика должна составлять 10% от трафика всей сети. Значение в 20% и выше должно классифицироваться как нештатная ситуация, носящая название «широковещательный шторм» (broadcast storm).
Скриншоты ниже будут кликабельны, так что Вы сможете рассмотреть все детально.
Итак, подключаемся к нашему D-Link DES-3550 по сети:
В колонке слева мы видим раскрывающееся «дерево» настроек. Сейчас мы находимся папке «Configuration» подраздел «IP Address».
Посмотрите на фото ниже:
Естественно, ARP-таблица динамически обновляется и перестраивается. Нередко бывает, что перенеся устройство в новый сегмент сети, мы должны ждать, когда коммутатор «опросит» все свои порты и выстроит новую таблицу для данного сегмента.
Посмотрите еще на одно фото и его раздел «Port Configuration»:
На нем мы видим, в каком режиме и с какой скоростью работают те или иные порты нашего коммутатора. Обратите внимание на два из них (под номерами 12 и 13) обозначенные красным. Как видите, оба они работают на скорости в 10 мегабит в секунду, хотя все остальные имеют скорость в 100 мегабит!
Следующий пункт «Loopback Detection» (обнаружение петли) позволяет нам, не бегая по всем этажам, отследить образование петли в локальной сети:
У коммутатора D-Link DES-3550 есть набор различных мониторов, которые в режиме реального времени могут показать нам тот или иной параметр или значение нагрузки. На фото ниже, мы видим график использования (utilization) центрального процессора устройства (в среднем нагрузка составляет 19%).
Есть также очень наглядные счетчики по каждому из 50-ти портов, на которых мы можем увидеть степень загрузки каждого из них, выяснить, трафик какого характера по ним передается (широковещательный, групповая передача, только одному узлу и т.д.)
Вот, к примеру, как выглядит подобный график для порта коммутатора под номером 11:
Видим, что порт №11 наполовину загружен Unicast трафиком (адресованным только одному ПК). Почему так происходит? Дело в том, что именно на нем у нас находятся несколько IP камер, ведущих трансляцию, и один сетевой видеорегистратор (DVR), которые и генерируют такой мощный поток данных. Все эти видео потоки затем сводятся на один мощный сервер видеонаблюдения, где и сохраняются на его жесткие диски.
Давайте теперь посмотрим на общую загрузку порта №19. Обратите внимание, что просто нажав на графическом изображении коммутатора по соответствующему порту, можно тут же увидеть его график в средней части окна (очень удобно!):
Вот скриншот, сделанный где-то через минут 15-20 после возникновения широковещательного шторма у нас в сети:
Эксперимента ради, продолжили ждать. Сеть «легла» полностью еще минут через 10 🙂
Также посмотрите на модель broadcast storm, которая поможет Вам лучше представить картину происходящего.
Что такое «броадкастный шторм»?
Иногда это явление еще называют «широковещательным штормом». Симптомы броадкастного шторма – сеть работает либо очень медленно, либо не работает вообще. Пользователи сети будут ощущать это на себе как невозможность отправить емэйл, отсутствие интернета, невозможность распечатать что-то на сетевом принтере или попасть на сетевой диск.
Если доля широковещательного трафика превышает 20%, то проблема в сети – это явно броадкастный шторм.
Что это за явление? Его корни в так называемом широковещательном (broadcast) трафике – который должны получить все компьютеры сети. Как правило – это служебный трафик, который предназначен для определения адреса компьютера в сети или поиск компьютера, на котором запущен необходимый сетевой сервис.
Причина броадкаст-шторма в том, что по каким-то причинам, сеть наполняется этим самым широковещательным трафиком. Причин этого может быть несколько.
Учитывая то, что большинство администраторов люди все-таки разумные и опытные, основной и наиболее вероятной причиной броадкастного шторма в корпоративной сети будет вирусная атака. Современные вирусы, попадая на машину, часто ищут другие машины в сети, которые можно заразить, в связи с чем могут рассылать широковещательные пакеты по сети в больших количествах. Несколько зараженных машин в сети могут оказаться способны уложить ее напрочь. Другая вероятная причина – DDOS-атака на сеть.
Среди прочих возможных причин, которые вызваны в основном криворукостью кого-то из «соучастников»: кольца (петли) в сети на основе концентраторов, некорректная настройка протокола Spanning Tree, NetBIOS- или IPX-трафик, кривые сетевые карты и драйверы, сервисы типа Bonjour или P2P-клиенты, которые любят искать пиров в своей сети.
В заключение стоит отметить, что сейчас множество так называемых «умных» маршрутизаторов умеют вычислять броадкастный шторм и подавлять его.
Боремся с широковещательным штормом
Итак, продолжим с места «обрыва» 🙂 После того, как сеть практически полностью «легла», я начал идти от ее центра (нашего управляемого коммутатора в серверной) по кабелю, который был подключен к 19-му порту устройства. Структуру сети на работе я, худо-бедно, знаю (иногда, она мне даже снится в тяжелых сновидениях) поэтому через два промежуточных свитча я оказался в одной каморке «папы Карло», возле старенького, но качественно выполненного, 16-ти портового хаба (концентратора) от фирмы «Compex», на котором явно наблюдались коллизии.
Как видите, индикатор «Collision» постоянно «горит» красным!
Проходя по сети, и находясь в режиме телефонной связи со своим коллегой, который удаленно мониторил центральный коммутатор, я отключал (и включал обратно) каждый свитч, встречавшийся мне на пути. Таки образом, коллега мог видеть, как коллизии пропадают и снова появляются, а я понимал, что причина не в этом сегменте сети и шел дальше.
На нормальной сетевой карте вендором устанавливались различные светодиоды, по работе которых можно было с легкостью определить, в каком режиме, на какой скорости работает карта, нет ли с ней проблем и т.д.?
На фото выше мы видим, что две карты одного класса кардинально отличаются набором светодиодных индикаторов. На верхней их целых четыре:
Мы нашли последнее звено в цепи (тот единственный линк, генерирующий широковещательный трафик). Осталось пройти по нему и оказаться возле компьютера, который и явился причиной всего этого безобразия!
Итак, расследование мы провели, последствия проблемы в полной мере ощутили, теперь бы хотелось ответить на два сокровенных вопроса: «кто виноват?» (причины возникновения широковещательного трафика и коллизий в сети) и «что делать?» (какие существуют меры защиты от этого явления).
Начнем с первого: возможные причины возникновения широковещательного шторма.
Зачем оно нужно? А именно для того, чтобы пакеты, которые не могут найти своего адресата, вечно, как неупокоенные, не блуждали по линиям связи и не занимали их полосу пропускания. Изначально (на выходе кадра из сетевого адаптера компьютера) полю TTL присваивается значение 255 и при каждом «прыжке» (хопе) через новый маршрутизатор из него вычитается единица. Если при продвижении пакета значение TTL уменьшится до ноля, то такой пакет, попросту, отбрасывается на следующем маршрутизаторе (говорят, что его время «жизни» истекло).
Есть даже такой бородатый анекдот:
Мальчик сказал маме: “Я хочу кушать”.
Мама отправила его к папе.
Мальчик сказал папе: “Я хочу кушать”.
Папа отправил его к маме.
Мальчик сказал маме: “Я хочу кушать”.
Мама отправила его к папе.
И бегал так мальчик, пока в один момент не упал.
Что случилось с мальчиком? TTL кончился
Вот еще один пример:
Разберем более детально одну из секций настроек нашего коммутатора второго уровня. Нас будет интересовать пункт «Traffic Control»: (кликабельно)
В правой части окна мы видим настройки модуля управления и контроля за трафиком. В частности, здесь мы можем силами самого коммутатора бороться с широковещательным штормом в сети. Мы должны как бы запрограммировать коммутатор на соответствующую реакцию с его стороны при обнаружении широковещательного шторма на любом из портов. Вот давайте это и сделаем!
Хотите узнать почему именно это значение? Давайте разбираться вместе! 🙂
После того, как мы нажмем кнопку «Apply» (применить), весь входящий трафик, который превысит цифру 128 000 пакетов в секунду будет просто отбрасываться.
Как мы могли убедиться, специальные функции коммутаторов ограничивают количество широковещательных пакетов в сети. И каждый вендор (производитель) старается этот функционал всячески расширять, придумывая новые меры борьбы с этой напастью.
Причем, команды эти реализуются на уровне кодов физического уровня модели OSI, поэтому «понятны» для любого, даже самого распоследнего, сетевого адаптера 🙂
К стандартным методам управления трафиком относятся такие приемы как: «Метод обратного давления на узел» (backpressure) и «Метод захвата среды». Давайте коротко их рассмотрим!
Второй метод «торможения» хоста основан на так называемом агрессивном поведении порта коммутатора при захвате среды. Давайте, рассмотрим и его!
Например, коммутатор окончил передачу очередного кадра и вместо технологической паузы, положенной по регламенту протоколом, сделал паузу чуть-чуть меньшую (на пару микросекунд) и тут же начал передачу нового кадра. Подключенный к коммутатору ПК, не ожидавший такой «наглости», просто не смог получить доступ к среде, так как он выдержал положенный тайм-аут и обнаружил после этого, что линия уже занята. Коммутатор может пользоваться подобными механизмами управления потоком данных на свое усмотрение, увеличивая степень своей «агрессивности» в зависимости от ситуации.