Broadcast storm

Broadcast storm (широковещательный шторм, широковещательная буря) — это сетевое явление, при котором в компьютерной сети происходит лавинообразное увеличение количества широковещательных (broadcast) или многоадресных (multicast) пакетов, приводящее к исчерпанию пропускной способности каналов связи и вычислительных ресурсов сетевых устройств. В результате сеть перестаёт выполнять свои функции, а подключённые к ней узлы могут терять связь или работать с критическими задержками.

Причины возникновения

Broadcast storm возникает в результате сбоев в работе протоколов канального уровня, ошибок конфигурации или вредоносных действий. Основные причины:

• Петли в топологии сети — наиболее распространённая причина. В сетях Ethernet, не использующих протокол Spanning Tree Protocol (STP), или при его некорректной работе широковещательный кадр, отправленный одним узлом, может бесконечно циркулировать по петле, каждый раз ретранслируясь коммутаторами. Каждый проход кадра порождает новые копии, что приводит к экспоненциальному росту трафика.
• Неисправность сетевого оборудования — дефектные сетевые карты (NIC) или коммутаторы могут генерировать бесконечный поток широковещательных пакетов (например, из-за повреждения драйвера или аппаратного сбоя).
• Ошибки в конфигурации протоколов — неправильная настройка протоколов динамической маршрутизации (например, RIP, OSPF) или протоколов разрешения адресов (ARP) может привести к массовой рассылке служебных широковещательных сообщений.
• Вредоносное ПО — некоторые типы компьютерных вирусов и червей (например, Blaster, Sasser) используют широковещательную рассылку для поиска уязвимых узлов, что создаёт высокую нагрузку на сеть.
• Атаки типа «отказ в обслуживании» (DoS) — злоумышленник может намеренно генерировать большое количество широковещательных пакетов, чтобы перегрузить сеть и вывести её из строя.

Механизм развития

Процесс развития broadcast storm можно описать на примере петли в сети Ethernet:

1. Узел A отправляет широковещательный кадр (MAC-адрес назначения FF:FF:FF:FF:FF:FF) на коммутатор 1.
2. Коммутатор 1, не имея записи о широковещательном адресе в своей таблице MAC-адресов, ретранслирует кадр на все порты, кроме порта, с которого он пришёл.
3. Если в сети существует петля, кадр достигает коммутатора 2, который также ретранслирует его обратно на коммутатор 1.
4. Коммутатор 1 снова получает кадр, считает его новым и опять ретранслирует на все порты. Цикл повторяется, и количество копий кадра увеличивается с каждым оборотом.
5. В течение короткого времени (секунды или доли секунды) трафик заполняет всю доступную пропускную способность каналов, и сеть перестаёт пропускать полезные данные.

Симптомы и последствия

Broadcast storm проявляется следующими признаками:

• Резкое падение производительности сети — время отклика (ping) возрастает до десятков секунд или соединение полностью теряется.
• Высокая загрузка процессора на сетевых устройствах — коммутаторы, маршрутизаторы и конечные узлы тратят ресурсы на обработку огромного числа широковещательных пакетов, что может привести к зависанию или перезагрузке.
• Срабатывание индикаторов активности — светодиоды Link/Act на коммутаторах начинают непрерывно мигать или горят постоянно, указывая на максимальную загрузку порта.
• Увеличение количества ошибок на канальном уровне — в статистике сетевых интерфейсов фиксируется рост числа коллизий, фреймов с ошибками CRC и отброшенных пакетов.
• Невозможность работы сетевых приложений — протоколы, зависящие от широковещательных запросов (например, DHCP, ARP, NetBIOS), перестают функционировать корректно.

Методы обнаружения и диагностики

Для выявления broadcast storm используются:

• Сетевые анализаторы (снифферы) — программы типа Wireshark, tcpdump или Microsoft Network Monitor позволяют захватывать трафик и анализировать долю широковещательных пактов. Нормальный уровень broadcast-трафика в сегменте Ethernet обычно не превышает 5–10% от общего объёма. При шторме эта доля может достигать 90–100%.
• Мониторинг сетевых устройств — протокол SNMP (Simple Network Management Protocol) позволяет снимать показатели загрузки портов, количества ошибок и broadcast-пакетов с коммутаторов и маршрутизаторов.
• Утилиты командной строки — команды ping, traceroute, arp -a помогают локализовать проблемный сегмент, хотя при сильном шторме они могут не отвечать.
• Логи коммутаторов — многие управляемые коммутаторы фиксируют события превышения порога broadcast-трафика (storm control) и могут отправлять предупреждения администратору.

Способы предотвращения и защиты

Протокол Spanning Tree (STP)

Основной метод защиты от петель в сетях Ethernet — использование протокола STP (IEEE 802.1D) или его улучшенных версий (RSTP — Rapid STP, MSTP — Multiple STP). STP автоматически блокирует избыточные порты, предотвращая образование петель, и активирует их только при отказе основного канала.

Storm Control (ограничение широковещательного шторма)

Функция, реализованная в большинстве управляемых коммутаторов. Администратор задаёт пороговое значение (например, не более 1000 broadcast-пакетов в секунду на порт). При превышении порога коммутатор автоматически отбрасывает избыточные пакеты или временно отключает порт.

Сегментация сети

Разделение сети на более мелкие широковещательные домены с помощью VLAN (Virtual Local Area Network) или маршрутизаторов. Широковещательный трафик не распространяется за пределы своего VLAN, что ограничивает радиус действия шторма.

Фильтрация на маршрутизаторах

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

Использование защищённых протоколов

Применение протоколов с аутентификацией и шифрованием (например, 802.1X для контроля доступа к портам) снижает риск подключения неисправных или вредоносных устройств.

Резервирование и мониторинг

Установка систем мониторинга (Zabbix, Nagios, PRTG) с оповещением администратора при резком росте broadcast-трафика. Регулярное тестирование топологии сети на наличие петель с помощью специальных утилит.

Примеры из практики

• Крупный сбой в сети провайдера — в 2010 году ошибка в конфигурации коммутатора одного из российских интернет-провайдеров привела к broadcast storm, который парализовал работу нескольких тысяч абонентов в течение нескольких часов. Причиной оказалось неправильное отключение протокола STP на одном из магистральных каналов.
• Атака на корпоративную сеть — в 2017 году злоумышленник, подключившись к незащищённому порту в офисе компании, запустил скрипт, генерирующий широковещательные ARP-запросы с высокой частотой. Это вызвало перегрузку коммутаторов и остановку работы внутренних сервисов на 40 минут.
• Бытовой случай — пользователь, подключивший к домашней сети два коммутатора, соединив их двумя кабелями (образуя петлю), столкнулся с полной потерей интернет-соединения. После отключения одного из кабелей сеть восстановилась.

Интересные факты

• Термин «broadcast storm» возник в начале 1990-х годов, когда сети Ethernet стали массово использовать коммутаторы, а не концентраторы. Концентраторы (хабы) физически не могли создавать петли, так как работали на физическом уровне, но с появлением коммутаторов проблема петель стала актуальной.
• В некоторых старых реализациях протокола STP восстановление сети после сбоя могло занимать до 30–50 секунд (время конвергенции). Современные версии (RSTP) сокращают это время до 1–3 секунд.
• Broadcast storm может быть вызван не только сетевым оборудованием, но и программными ошибками в драйверах сетевых карт. Например, в 2003 году массовые сбои в сетях Windows были связаны с червём Blaster, который рассылал широковещательные запросы на порт 135.

Источники

• IEEE 802.1D-2004 — Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges.
• Олифер В. Г., Олифер Н. А. «Компьютерные сети. Принципы, технологии, протоколы» — 5-е издание, 2016.
• Tanenbaum A. S., Wetherall D. J. «Computer Networks» — 5th edition, 2011.
• Документация Cisco Systems: «Configuring Storm Control» — Catalyst 3750 Switch Software Configuration Guide, 12.2(55)SE.
• Материалы курса «Сети и телекоммуникации» — НИУ ВШЭ, 2020.