Storm control: как не положить сеть собственной защитой В прошлый раз разобрали RSTP. Он позволяет оставить резервные соединения и не получить активную петлю. Но устроить шторм можно и без петли: достаточно устройства, которое начинает массово рассылать кадры. Здесь пригодится storm control. Коммутатор измеряет интенсивность определённого трафика и при превышении порога ограничивает его. В зависимости от модели доступны отбрасывание кадров, уведомление, иногда отключение порта. Но сначала нужно понять, что именно мы ограничиваем. Broadcast — широковещательные кадры. Обычный пример: ARP-запрос, с помощью которого устройство узнаёт MAC-адрес соседа по IP. Такие кадры нужны для нормальной работы сети. Multicast — кадры для группы получателей. Здесь могут быть IPTV, обнаружение сервисов и служебный обмен. Одно оборудование ограничивает весь multicast, другое позволяет отдельно учитывать неизвестный multicast. Unknown unicast — кадр конкретному получателю, MAC-адрес которого коммутатор пока не нашёл в своей таблице. Тогда кадр обычно рассылается по разрешённым портам соответствующего VLAN, кроме входного. Это штатное поведение, которое само по себе ещё не означает аварию. Поддерживаемые категории и способы ограничения зависят от оборудования. А теперь любимый рецепт из интернета: «Поставь один процент на всех портах». Один процент чего? Если порог считается от скорости соединения, получаем: • порт 100 Мбит/с — 1 Мбит/с; • порт 1 Гбит/с — 10 Мбит/с; • порт 10 Гбит/с — 100 Мбит/с. Процент одинаковый, разрешённый поток отличается в сто раз. Например, у MikroTik с Marvell Prestera параметр storm-rate действительно привязан к скорости линка. При этом мегабиты не показывают количество кадров. Мелких кадров при той же полосе будет гораздо больше. Поэтому пороги в битах в секунду и пакетах в секунду решают несколько разные задачи. Представим обычную офисную сеть. На порту одного компьютера широковещательного трафика немного. На соединении между коммутаторами собирается трафик множества устройств, иногда нескольких VLAN. Копировать туда порог абонентского порта без измерений — отличный способ самому устроить загадочные отказы. Чрезмерно низкий лимит broadcast может начать отбрасывать нужные ARP-запросы. Слишком жёсткий multicast-лимит способен задеть полезный групповой трафик. Линк при этом зелёный. Коммутатор работает. Пользователи ругаются. Поэтому я бы начинал с измерений. Посмотреть обычный уровень и пики, в том числе при массовом включении компьютеров и восстановлении связи. Уточнить, считает устройство категории отдельно или суммарно, на входе или выходе, за какой интервал. Пятиминутное среднее в мониторинге короткий всплеск может просто спрятать. После настройки смотреть счётчики отбрасываний, события срабатывания и работу сервисов. Порог должен пропускать штатные всплески, а его превышение должно быть заметно администратору. С автоматическим отключением порта особенно аккуратно. На межкоммутаторном соединении такая реакция может отрезать целую площадку. И ещё: storm control не устраняет петлю. Он ограничивает выбранные категории трафика. Петля, перемещение MAC-адресов между портами и другие последствия могут остаться. RSTP и storm control полезны вместе, но даже они не делают растянутую на несколько площадок сеть неуязвимой. Дальше разберём VLAN: где заканчивается распространение широковещательных кадров и почему разные номера VLAN ещё не гарантируют независимость от аварий. Communicatio est victoria. — Душнила t.me/zas_svo vk.com/zas_svo #СВО #связь #сети #StormControl
Хроники связи СВО
Subscribers
9.7K
+0 24h
Reach per post (ERR)
27.4%2.7K avg views
Posting
2.0/day
last 1 day ago
Reactions per 1K views
13.5
👍 💯 🔥
Views over time
| When | Views |
|---|---|
| 4 Nov 2026, 14:32 | 0 |
| 10 Nov 2026, 13:50 | 2.2K |
| 10 Nov 2026, 15:10 | 2.2K |
Who shared this post
Posts in other channels we index that link to this one. (Forwards with a hidden source can't be traced.)
Nobody yet.