Источник широковещательного шторма выдает входящий трафик

Широковещательный шторм ищут не по самому громкому коммутатору, а по направлению, откуда на его порты приходит аномальный поток кадров. Коммутатор в центре сети часто выглядит хуже всех, хотя он лишь размножает трафик, который возник этажом ниже, за настенным портом, дешевым мини-коммутатором или ошибочно соединенными розетками.

Когда сеть уже стоит, порядок важнее глубины анализа. Сначала сохраните несколько показаний, затем разорвите петлю на минимально возможном участке, восстановите связь и только после этого разбирайте конфигурацию. Если сразу выключить все аплинки, офис оживет, но вы уничтожите маршрут к причине и получите повтор аварии при следующем подключении кабеля.

Шторм виден сразу на трех уровнях

Широковещательный шторм проявляется одновременно у пользователей, на портах и в работе самого коммутатора. Один признак легко спутать с другой неисправностью, а совпадение признаков дает рабочую гипотезу о петле второго уровня.

Пользователи жалуются, что шлюз то отвечает, то пропадает, DHCP долго выдает адреса, телефония заикается, а доступ к серверам внутри того же офиса нестабилен. Задержка до шлюза скачет, появляются потери, но физические индикаторы портов продолжают гореть. Перезапуск одного компьютера ничего не меняет, потому что проблема охватывает весь широковещательный домен, обычно одну VLAN или набор VLAN на общем транке.

На коммутаторах растет загрузка нескольких линий, причем поток состоит в основном из широковещательных и часто многоадресных кадров. В таблице MAC-адресов один и тот же адрес может быстро появляться то на одном, то на другом порту. Журнал сообщает о частых изменениях топологии STP, переполнении очередей, отбрасывании кадров или срабатывании storm control. Управление по SSH и веб-интерфейс отвечают медленно, потому что управляющий процессор занят обработкой служебных событий, хотя пересылка кадров выполняется аппаратно.

Не всякая высокая загрузка означает шторм. Резервное копирование способно занять линию одноадресным трафиком и не повредить соседям. Массовый ARP после восстановления питания создает короткий всплеск, который сам затихает. Ошибка дуплекса дает CRC, late collisions и низкую полезную скорость, но не заставляет один исправный кадр бесконечно циркулировать. Проверяйте состав трафика, область поражения и скорость роста счетчиков вместе.

Граница поражения помогает определить VLAN до входа на первый коммутатор. Если проводные пользователи одного отдела потеряли связь, а гостевой Wi-Fi и телефоны работают, сравните их VLAN и шлюзы. Если одновременно пропали несколько VLAN, ищите общий транк, неверно собранный агрегированный канал или петлю на устройстве, которое переносит все эти VLAN. Шторм в одной VLAN не обязан загрузить каждый порт физического коммутатора, однако он способен сделать недоступным управление устройством и создать впечатление общей аварии.

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

RFC 919 объясняет неприятную экономику широковещания: каждый узел, который слышит такой пакет, тратит на него ресурсы. В исправной сети эта цена ограничена одним доменом и конечным числом копий. В петле Ethernet у кадра второго уровня нет аналога IP TTL, поэтому коммутаторы продолжают копировать его, пока петлю не разорвет STP, защитный механизм или инженер.

Петля и шумный узел требуют разных решений

Петля второго уровня размножает уже существующие кадры, а шумный узел генерирует чрезмерное число новых кадров. Оба случая поднимают счетчик broadcast, но поиск и окончательное исправление различаются.

При петле несколько связанных портов показывают большие входящие и исходящие скорости. Один и тот же исходный MAC-адрес скачет между портами, потому что его кадры возвращаются с другой стороны. Захват трафика часто содержит повторяющиеся ARP-запросы или другие одинаковые кадры. Выключение одного ребра кольца почти сразу снижает поток по всему домену.

При шумном узле основная входящая скорость сосредоточена на одном access-порту. Исходные MAC-адреса стабильны, STP не меняет роли, а пакеты в захвате различаются или выходят от одного отправителя с новой последовательностью. Отключение этого порта тоже прекращает аварию, но причина окажется в сетевой карте, драйвере, программном обеспечении или неверно настроенном устройстве, а не в кабельном кольце.

Есть и третий случай: многоадресный поток разливается как широковещательный из-за отсутствия или сбоя IGMP snooping. Он может заполнить access-порты, хотя петли нет. Смотрите отдельные счетчики broadcast и multicast, таблицу MAC и повторяемость кадров. Фраза «все лампочки мигают» не различает эти неисправности.

Практическое различие простое: при петле вы ищете замкнутый путь, при генераторе вы ищете один источник. Storm control сдерживает оба явления на конкретном порту, но он не объясняет, почему трафик появился, и не чинит кабельную схему.

Снимок до отключения экономит часы после аварии

Перед изменением состояния портов сохраните короткий снимок фактов, если управление коммутаторами еще отвечает. На это нужно не больше пары минут, а данные покажут направление поиска после восстановления связи.

Запишите время, пораженные VLAN, доступность шлюза и коммутаторы, на которых управление еще работает. Снимите состояние STP, скорости на интерфейсах, счетчики broadcast и multicast, сообщения журнала, соседей LLDP или CDP и перемещения MAC-адресов. Не очищайте счетчики, пока не сохранили исходные значения.

Для Cisco IOS XE минимальный набор может выглядеть так:

show clock
show spanning-tree vlan 120
show interfaces counters
show interfaces | include is up|input rate|output rate
show mac address-table notification mac-move
show logging
show lldp neighbors

Названия команд зависят от производителя и версии. На других коммутаторах ищите эквиваленты interface statistics, Ethernet switching table, spanning tree status, log buffer и LLDP neighbors. Не вставляйте незнакомую команду очистки или перезапуска в аварийную консоль, пока не проверили ее действие.

На стеке коммутаторов записывайте номер участника вместе с портом. Запись Gi1/0/24 и Gi3/0/24 указывает на разные физические шкафы, хотя последние цифры совпадают. Проверьте состояние внутренних stack-links: их перегрузка или разрыв меняет путь трафика и может сделать внешние счетчики неожиданными. В виртуальном шасси аналогично фиксируйте слот и владельца интерфейса.

Сделайте два снимка с интервалом 10-20 секунд. Абсолютный счетчик, накопленный за год, почти бесполезен. Разница между двумя значениями показывает скорость. Если broadcast на порту вырос с 18 240 100 до 18 690 100 за 15 секунд, это 30 000 кадров в секунду:

(18 690 100 - 18 240 100) / 15 = 30 000 pps

Сравнивайте порты одного класса. Аплинк этажа естественно несет больше трафика, чем порт принтера. Подозрителен не просто высокий счетчик, а резкий рост относительно обычной нагрузки и соседних линий той же роли.

Cisco в руководстве по диагностике петель Catalyst 9000 советует смотреть прежде всего входящую скорость, долю broadcast и multicast и средний размер пакета. Это полезнее хаотичного преследования уведомлений об изменении STP: перегруженные коммутаторы сами создают много таких уведомлений, поэтому событие указывает на пострадавшее место, но не обязательно на источник.

По входящим счетчикам идите против потока

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

Представим сеть с ядром CORE-1, этажными коммутаторами FLOOR-2 и FLOOR-3 и VLAN 120. На CORE-1 два аплинка отдают почти линейную скорость, но входящий broadcast на порту к FLOOR-2 намного выше. Переходим на FLOOR-2. Там большой входящий поток приходит с Gi1/0/47, который по LLDP ведет к малому коммутатору переговорной. На нем два порта одновременно показывают поток, а MAC-адреса перескакивают между ними. Физическая проверка обнаруживает два патч-корда, соединяющие этот коммутатор с двумя розетками одной VLAN.

Этот маршрут важен: большая исходящая скорость часто ведет от источника к очередной жертве. Большая входящая скорость указывает, откуда устройство получает копии. Исключения бывают при асимметричной топологии, агрегированных каналах и аппаратных особенностях счетчиков, поэтому сопоставляйте показания на обоих концах линии.

Рабочая последовательность состоит из пяти действий:

1. Найдите коммутатор, где видны последствия, и определите VLAN шторма.
2. Сравните прирост входящих broadcast и multicast на активных портах.
3. Для порта с аномальным приростом определите соседа через LLDP, CDP, описание или схему.
4. Перейдите на соседа и повторите измерение тем же интервалом.
5. На границе сети сопоставьте MAC-адрес, патч-панель, розетку и реальное устройство.

Не доверяйте описанию порта как единственному доказательству. После переездов подпись «принтер бухгалтерии» нередко ведет к неуправляемому коммутатору под столом. LLDP тоже может исчезнуть во время перегрузки. Сверяйте минимум два признака: счетчики и соседа, либо счетчики и физическую трассу.

Если доступен захват с зеркального порта, проверьте, повторяются ли одинаковые кадры. Совпадающие исходный и целевой адреса, EtherType, содержимое ARP и близкое время прихода усиливают диагноз петли. Захват не должен задерживать разрыв аварии: когда весь офис недоступен, счетчики и аккуратное отключение подозрительного ребра обычно дают ответ быстрее.

Полезно отдельно проверить unknown unicast. Коммутатор разливает кадр с неизвестным целевым MAC по VLAN почти как broadcast. Во время нестабильности таблицы MAC объем такого трафика растет и усиливает перегрузку, хотя счетчик broadcast не показывает всей картины. Если общая входящая скорость высока, а broadcast умерен, сравните unknown unicast, возраст записей MAC и скорость их обучения.

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

STP показывает, почему защита не остановила петлю

Spanning Tree Protocol должен оставить один активный путь и заблокировать избыточный, но наличие STP в конфигурации еще не означает, что он видит конкретную петлю. Проверяйте роли портов, корневой мост, прием BPDU и границы каждой VLAN.

Сначала сравните фактический root bridge с проектным. Неожиданно выбранный корень часто указывает на подключенный коммутатор с более выгодным приоритетом. Затем найдите порты в состояниях forwarding и discarding или blocking. Если два параллельных пути пересылают одну VLAN и ни один не блокируется, выясните, получают ли оба конца BPDU и совпадает ли конфигурация VLAN на транках.

Частая причина в офисе скрывается за edge или PortFast. Эта настройка уместна на порту конечного устройства, потому что позволяет не ждать обычного перехода STP. Она не превращает порт в безопасный. Если сотрудник подключит к двум edge-портам маленький коммутатор, возникает путь, который проектировщик не планировал. BPDU Guard должен отключить такой access-порт при получении BPDU, но механизм сработает только там, где он включен и где подключенное устройство действительно передает BPDU.

Проверьте четыре защитных механизма и не смешивайте их назначения:

• BPDU Guard закрывает edge-порт, если на нем появился BPDU, и защищает границу доступа.
• Root Guard не дает порту привести посторонний коммутатор к роли корня.
• Loop Guard удерживает некорневой порт от перехода в forwarding, когда ожидаемые BPDU пропали.
• Storm control ограничивает broadcast, multicast или unknown unicast по порогу и снижает ущерб.

Storm control не заменяет STP. Слишком высокий порог позволит петле перегрузить сеть, а слишком низкий отрежет законные всплески ARP, DHCP или обнаружения устройств. Выбирайте пороги по измеренной базовой нагрузке для разных типов портов и заранее определяйте действие: отбрасывание, уведомление или отключение. После срабатывания инженер должен видеть порт, вид трафика, порог и время, иначе защита лишь превращает общую аварию в загадочный локальный обрыв.

Отдельно проверьте агрегированные каналы. Если один конец считает две линии единым LAG, а другой видит их как независимые порты, STP и таблица пересылки получают противоречивую картину. Сверьте состав port-channel, протокол согласования, VLAN и состояние каждого участника с обеих сторон.

Односторонняя линия создает еще один опасный сценарий. Один конец принимает BPDU, а другой перестает их видеть из-за неисправного передатчика, оптики или фильтрации. Порт, который раньше блокировался, может решить, что путь к корню исчез, и перейти к пересылке. Сравните прием BPDU, LLDP-соседа и входящую скорость на обоих концах. Ситуация, где каждый конец считает себя designated, а сосед виден только с одной стороны, требует проверки физической линии и Loop Guard.

Когда сеть стоит, разрывайте минимальное ребро

При полной недоступности приоритетом становится восстановление связи, но отключать следует одно подтвержденное или наиболее вероятное ребро петли. Начинайте с периферии, если счетчики указывают туда, и избегайте одновременного отключения всех магистральных связей.

Перед командой shutdown зафиксируйте порт, время, текущие счетчики и причину выбора. Проверьте, не является ли линия единственным аплинком критичного сегмента, телефонной станции, системы контроля доступа или медицинского оборудования. Если риск допустим, отключите порт и сразу наблюдайте за входящей скоростью на вышестоящем коммутаторе.

Правильное ребро дает резкий и устойчивый спад broadcast, возвращение управления и нормализацию задержки до шлюза. Подождите не меньше двух периодов измерения, потому что очереди должны опустеть, а STP может перестроиться. Если показатели не изменились, верните порт в исходное состояние, запишите результат и переходите к следующему кандидату. Не оставляйте за собой случайный набор выключенных портов.

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

Порядок аварийных действий удобно держать в короткой памятке:

1. Объявите инцидент и запретите несогласованные переключения.
2. Сохраните доступные счетчики, STP, журнал и время.
3. Выберите одно ребро по входящему потоку и карте соседей.
4. Отключите его, проверьте спад и доступность контрольных узлов.
5. Зафиксируйте временную схему и не включайте порт до проверки причины.

После восстановления проверьте не только ping. Клиенты должны получать DHCP, разрешать DNS, видеть шлюз и основные внутренние сервисы. Голосовая VLAN, Wi-Fi и гостевой сегмент могут восстанавливаться иначе, чем рабочие станции. Один успешный ответ от шлюза не доказывает, что офис вернулся в штатный режим.

Назначьте одного человека руководить переключениями и одного вести журнал. Когда три администратора одновременно закрывают разные порты, нельзя связать падение счетчиков с конкретным действием. Журнал должен содержать точное время, устройство, интерфейс, состояние до и после, имя исполнителя и результат контрольных проверок. Такой порядок звучит медленнее, но обычно сокращает простой, потому что команда не повторяет уже опровергнутые гипотезы.

MAC-flapping и изменения STP дают маршрут, а не приговор

Частые перемещения MAC-адреса между портами помогают очертить петлю, но сами по себе не доказывают ее. В беспроводной сети клиент законно перемещается между точками, кластер может использовать общий виртуальный MAC, а гипервизор переносит виртуальную машину между хостами.

При петле картина обычно массовая: много MAC-адресов меняют порты быстро и по одной паре интерфейсов или по нескольким линиям одного кольца. Сопоставьте время этих событий с ростом broadcast. Один плавающий адрес без шторма требует проверки конкретного устройства, а не отключения этажа.

Topology Change Notification тоже не указывает пальцем на источник. В RSTP изменение появляется, когда некраевой порт переходит в forwarding. Во время шторма управляющий процессор может задерживать BPDU, порты меняют состояние, и журналы заполняются вторичными событиями. Cisco отдельно предупреждает, что погоня за TCN может привести к пострадавшим коммутаторам, а не к месту возникновения петли.

Полезнее построить временную линию: какой порт первым показал резкий входящий поток, где начались MAC moves, какой интерфейс изменил роль STP и какое действие остановило рост. Время на коммутаторах должно быть синхронизировано. Без синхронизации запись «событие было раньше» превращается в догадку.

Сравнивайте журналы с последними разрешенными изменениями, но не объявляйте последнее изменение причиной автоматически. Новый access point может совпасть по времени с петлей, созданной старым кабелем после уборки помещения. Изменение становится подозреваемым, когда его VLAN, порт и время совпадают с направлением входящего потока. Такой фильтр защищает от удобной, но неверной истории.

Ошибки CRC, drops и no buffer добавляют контекст. CRC чаще указывает на физическую линию или несогласованный дуплекс, drops и no buffer появляются при перегрузке. Они могут идти вместе со штормом, но устранение плохого патч-корда не разорвет логическую петлю, если второй путь остается активным.

После восстановления нужно доказать первопричину

Авария не закрыта, пока команда не воспроизвела путь петли по схеме и не объяснила, какой контроль должен был ее остановить. Формулировка «перезагрузили коммутатор, помогло» описывает действие, а не причину.

Сохраните конфигурации затронутых портов, журналы, счетчики до и после отключения, таблицу MAC и фотографии коммутации. Проследите оба конца каждого кабеля. Если найден маленький неуправляемый коммутатор, проверьте все его порты: петля может проходить через две розетки, IP-телефон с проходным портом или док-станцию.

Затем ответьте на четыре вопроса:

• Какой физический или логический путь замкнулся?
• Почему STP не заблокировал один из путей?
• Почему BPDU Guard, Loop Guard или storm control не ограничили событие?
• Какое изменение предотвратит повтор без создания новой точки отказа?

Исправление должно соответствовать ответу. Уберите лишний кабель и заблокируйте неиспользуемую розетку. Назначьте edge только пользовательским портам и включите BPDU Guard согласно политике производителя. Исправьте allowed VLAN и согласование LAG на обоих концах. Настройте storm control по реальным измерениям. Добавьте описания портов и обновите схему, чтобы следующий инженер не шел по устаревшим подписям.

Отчет об инциденте должен различать инициирующее событие, недостаток защиты и последствия. Например, инициирующим событием были два кабеля между переговорной и этажным коммутатором. Недостатком стало отсутствие BPDU Guard на пользовательских портах. Последствиями стали переполнение очередей и недоступность VLAN 120. Если записать все это одной фразой «широковещательный шторм», команда не поймет, какой контроль менять.

Не включайте аварийный порт «для проверки» в рабочее время без наблюдения за счетчиками и готовой команды отключения. Безопаснее воспроизвести схему в изолированном сегменте или подключать по одному кабелю, каждый раз проверяя STP и прирост broadcast.

Для организаций, где коммутационная сеть связана с серверной и пользовательской инфраструктурой, GSE.kz может спроектировать и сопровождать решение как системный интегратор с круглосуточной технической поддержкой и сервисной сетью по Казахстану. Это не отменяет внутреннюю схему, базовые метрики и доступ команды к консоли: подрядчик тоже ищет петлю по фактам.

Защита работает только после проверки отказом

Предотвращение начинается с четкой границы: пользовательские порты не должны становиться транками, принимать чужую роль корня или образовывать незапланированные кольца. Одинаковый шаблон конфигурации на access-коммутаторах уменьшает число исключений, которые никто не помнит.

Включите RSTP или MSTP последовательно во всем домене, назначьте корневые и резервные мосты осознанно, ограничьте разрешенные VLAN на транках. На edge-портах примените BPDU Guard, на подходящих резервных путях рассмотрите Loop Guard, а на границах задайте проверенные пороги storm control. Не копируйте один процент на все интерфейсы: телефон, точка доступа, аплинк и принтер имеют разный нормальный профиль.

Мониторинг должен хранить скорость входящего broadcast и multicast, загрузку порта, MAC moves, изменения STP и срабатывания защит. Нужна базовая линия по времени суток, иначе тревога на «высокий трафик» будет либо молчать во время аварии, либо будить дежурного при каждом утреннем включении компьютеров.

Проведите контролируемую проверку на стенде или в изолированной VLAN. Подключите тестовый коммутатор к защищенному edge-порту, убедитесь, что BPDU Guard дает ожидаемое состояние и понятную запись журнала. Подайте ограниченный broadcast-поток генератором трафика и проверьте порог storm control без воздействия на рабочую сеть. Зафиксируйте команды восстановления, потому что автоматическое отключение без понятной процедуры иногда продлевает простой.

И наконец, отрепетируйте поиск по двум снимкам счетчиков. Дежурный инженер должен уметь за несколько переходов пройти от ядра к access-порту, не очищая доказательства и не отключая полсети. Во время настоящего шторма сложные панели мониторинга могут зависнуть вместе с сетью, а консоль, карта LLDP и разница счетчиков останутся рабочими инструментами.