Привет, Хабр! Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги. Полагаю, многим сетевым инженерам знакома ситуация, когда вам сообщают о том, что сеть «легла».

Вы заходите на коммутатор и видите, что все порты мигают, как ёлочные гирлянды, а нагрузка на процессор прыгает под 100 процентов. Пользователи не могут подключиться к ресурсам, потому что DHCP‑запросы теряются в бесконечном цикле где‑то в недрах вашей сети. Обычно причиной такого сетевого апокалипсиса является петля в сети. Сегодня мы поговорим о том, как находить и уничтожать L2-петли без дорогого софта и длительных расследований.

Петля — это не «тормоза», а системный коллапс

Давайте сразу поймём физику данной проблемы. В IP‑сетях у каждого пакета есть TTL (Time To Live) — счётчик, который уменьшается на каждом маршрутизаторе. Достиг нуля — пакет умер. Это защита от зацикливания на L3.

На втором уровне модели OSI (Ethernet) нет TTL. Кадр, попавший в петлю, будет циркулировать по кругу вечно, плодясь и размножаясь, пока кто‑нибудь физически не разорвёт кольцо. Именно поэтому L2-петля убивает сеть не за минуты — за секунды.

Представьте: коммутатор получает широковещательный кадр (broadcast). Свитч должен разослать его на все порты, кроме того, с которого он пришёл. В нормальной сети это один кадр на все порты. В петле этот кадр возвращается на тот же коммутатор через другой порт, и он отправляет его снова. И снова. И снова.

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

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

Первые симптомы: как распознать петлю до того, как вырубится всё

Опытный инженер чувствует петлю ещё до того, как открыл консоль. Вот классический набор симптомов, по которым ставят диагноз «L2 loop».

  • Первый симптом — лавинообразный рост broadcast‑трафика. Вы заходите на любой коммутатор, команда show interfaces показывает, что input rate на нескольких портах превышает разумные значения. Если вы видите на аплинке 2–3 гигабита входящего трафика, хотя в час пик там было 200 мегабит — это не внезапная популярность, это проблема.

  • Второй симптом — MAC‑адреса пляшут. Команда show mac address-table начнёт показывать странное: один и тот же MAC‑адрес появляется то на одном порту, то на другом, меняясь каждые несколько секунд. Это называется MAC flapping — коммутатор не может запомнить, где находится устройство, потому что кадры от него приходят отовсюду.

  • Третий симптом — протоколы сходят с ума. Если в сети есть HSRP или VRRP (резервирование шлюзов), они начнут флапить — активный шлюз будет меняться каждые несколько секунд. Логи будут полны сообщений «duplicate IP address». Это потому, что петля создаёт иллюзию, что устройство находится в нескольких местах одновременно.

  • Четвертый симптом — CPU на коммутаторах зашкаливает. Управляющий процессор коммутатора начинает задыхаться, пытаясь обработать лавину пакетов и постоянно перестраивая таблицу MAC‑адресов. Команда show processes cpu покажет процесс HULC L2FIB или spanning-tree на 90–100 процентах.

  • Пятый симптом — пользователи не могут получить IP по DHCP. Клиент шлёт DHCP Discover, сервер шлёт Offer, но в петле ответ либо теряется, либо приходит с огромной задержкой. Или приходит несколько раз. Или приходит непонятно откуда.

Если вы наблюдаете хотя бы три из пяти симптомов одновременно — петля есть на 99 процентов. Вопрос только в том, где именно.

Трехуровневая диагностика: находим источник

Методология поиска петель, отработанная TAC‑инженерами Cisco на тысячах инцидентов, удивительно проста. Она не требует сложных анализаторов или глубоких знаний STP — только системный подход.

Уровень 1: Поиск портов с аномальным входным трафиком

Первый шаг — найти порты, которые участвуют в петле. Их выдают аномально высокие показатели входящего трафика (input rate). Исходящий трафик вводит в заблуждение — он может быть высоким из‑за того, что коммутатор просто ретранслирует шторм дальше. Нам нужен именно вход.

Вот магическая команда, которая сэкономит вам часы:

show interfaces | include line|input rate

Она показывает только название интерфейса и скорость входящего трафика. Выглядит это так:

Видите два верхних интерфейса? По 2.8–2.9 гигабита входящего трафика. Это не нормально. Это порты, которые находятся в центре шторма. Именно их нужно исследовать в первую очередь.

Дальше мы выясняем, что подключено к этим портам. Команда show cdp neighbors (если сеть Cisco) или show lldp neighbors (для мультивендорной среды):

ACCESS-SWITCH1#show cdp neighbor twe1/1/1

Отлично. Мы знаем, что порт ведёт на ACCESS‑SWITCH2. Теперь идём на ACCESS‑SWITCH2 и повторяем процедуру.

Таким образом, двигаясь от коммутатора к коммутатору по цепочке портов с аномальным input rate, вы выйдете на источник петли. Это как игра «холодно‑горячо»: чем выше input rate, тем ближе вы к проблеме.

Уровень 2: STP‑диагностика — кто должен блокировать, но не блокирует

После того как вы нащупали подозрительный сегмент сети, пора проверить, что думает о нём spanning‑tree. Команда show spanning-tree покажет текущее состояние портов:

В нормальной сети вы должны увидеть хотя бы один порт в состоянии BLK (Blocking) для каждого VLAN — это тот самый порт, который STP держит закрытым, чтобы разорвать петлю.

Если все порты в статусе FWD (Forwarding) и нет ни одного BLK — STP не справился, и петля образовалась.

Но бывает хитрее. Иногда STP показывает блокирующий порт, но петля всё равно есть. Это значит, что проблема либо в другом VLAN (STP работает отдельно для каждого), либо BPDU‑пакеты, которыми STP обменивается, не доходят до места назначения.

Уровень 3: Поиск MAC‑флапинга — точный прицел

Метод, который позволяет найти порт‑виновник с точностью до интерфейса. Команда show mac address-table dynamic покажет активные MAC‑адреса. Если вы видите такое:

Один и тот же MAC‑адрес на двух разных портах — классический признак петли. Коммутатор просто не может решить, где на самом деле находится устройство.

Некоторые современные IOS (на Catalyst 9000) даже логируют это событие. Команда show mac address-table flapping покажет историю перемещений MAC‑адресов.

Если вы видите, что конкретный порт постоянно фигурирует в логах флапинга — очень похоже, что именно он ведёт в петлю. Или на нём висит то самое злополучное устройство (тупой хаб, неправильно подключенный свитч, или просто два порта одного коммутатора, соединённые одним кабелем).

Разрыв петли: операция по спасению сети

Методология предельно проста, но требует хладнокровия. Вы нашли подозрительный порт (или несколько). Ваша задача — разорвать цепь.

Экстренный протокол (когда всё горит):

Переходим в конфигурационный режим и выключаем порт:

configure terminal

interface TwentyFiveGigE1/1/1

shutdown

После этого мониторим ситуацию. Если input rate на остальных портах упал до нормальных значений, а пользователи задышали — вы нашли правильный порт.

Важнейшее предупреждение: не гадайте. Если вы отключили порт и ничего не изменилось — включите его обратно командой no shutdown. Возможно, петля в другом месте, и вам нужно продолжить поиски.

После того как петля разорвана, у вас есть время спокойно разобраться, почему она возникла. Типичные причины:

  1. Unidirectional link — оптоволоконный кабель, где передача работает, а приём — нет. BPDU‑пакеты, которые STP шлёт для синхронизации, теряются, и коммутатор, не получая сигнала от соседа, переводит блокирующий порт в форвардинг.

  2. Ручное отключение STP — кто‑то решил, что «STP только замедляет», и выключил его на каком‑то порту или вообще на всём коммутаторе. Такое бывает чаще, чем хотелось бы.

  3. Rogue device — пользователь принёс из дома маленький свитч или хаб и подключил его двумя кабелями к разным розеткам в офисе. Устройство не понимает STP, не передаёт BPDU, но создаёт петлю на своей стороне.

  4. Misconfigured PortFast — на порту, где включён PortFast (режим для подключения конечных устройств, который пропускает STP‑инициализацию), оказался свитч, а не компьютер. PortFast проигнорировал BPDU и немедленно перевёл порт в форвардинг, создав петлю.

Как не допустить повторения

Вы потушили пожар и теперь самое время закрутить гайки, чтобы это не повторилось. Включите BPDUguard на access‑портах. Это железобетонная защита от rogue‑устройств. Команда на порту, куда подключены пользователи:

spanning‑tree bpduguard enable

spanning‑tree portfast

Если на этот порт вдруг придёт BPDU (а значит, кто‑то подключил там свитч или хаб), порт перейдёт в состояние err‑disable и автоматически отключится, предотвращая петлю.

  • Включайте Root Guard на портах, которые не должны стать корневыми. Это защищает от ситуации, когда кто‑то подключает свой коммутатор с меньшим bridge priority и «перетягивает одеяло» STP на себя, меняя топологию сети:

spanning‑tree guard root

  • Включайте Loop Guard на портах, где есть риск unidirectional link. Эта функция защищает от ситуации, когда BPDU перестают поступать из‑за проблем с кабелем — порт переходит в состояние «неопределённость», а не в форвардинг.

  • Проверяйте настройки STP. Убедитесь, что корневой мост для каждого VLAN — это тот коммутатор, который вы ожидаете, и что у него наименьший priority (например, 4096). Остальные коммутаторы должны иметь приоритет выше (32768 и так далее).

  • Используйте Loop Detection на недорогом оборудовании. Если у вас не Cisco или старые коммутаторы, где нет продвинутых STP‑защит, во многих устройствах есть встроенный механизм Loop Detection. Он работает просто: коммутатор периодически шлёт специальные probe‑пакеты на порт. Если пакет вернулся на тот же порт — значит, петля, и порт надо отключить. По умолчанию эта функция обычно выключена, и её надо включить вручную.

Итог

В завершение дадим несколько советов. Иногда консольный доступ к коммутаторам ограничен, а проблема есть. Для начала посмотрите на светодиоды. Если на коммутаторе все порты мигают одновременно с бешеной скоростью и синхронно — это с высокой вероятностью broadcast storm. В нормальной работе трафик распределён неравномерно.

Далее проверьте время отклика. Пинг до шлюза будет давать хаотичные значения — от 1 мс до 3000 мс с огромными выбросами. Это не проблемы с каналом, это признаки переполненных очередей. Также для диагностики используйте Traceroute. Если на каком‑то хопе время резко возрастает и затем падает — возможно, этот коммутатор находится на пути шторма.

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

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

Разобраться с базой можно на бесплатных уроках OTUS от преподавателей‑практиков:

  • 1 июля в 20:00 — «Что нужно знать для настройки стабильного интернета? OSPF и протоколы динамической маршрутизации». Записаться
    Объясним, как работает OSPFv2, чем отличаются разные типы сетевых сегментов и как динамическая маршрутизация помогает поддерживать устойчивость инфраструктуры.

  • 22 июля в 20:00 — «VLAN на пальцах: изоляция трафика и маршрутизация». Записаться
    На уроке разберем логику пересылки кадров в VLAN, изоляцию трафика и правила настройки Access‑ и Trunk‑портов в коммутируемой сети.

Если хочется шире пройтись по инфраструктурным темам, посмотрите дайджест. Внутри — открытые уроки, статьи и курсы по Linux, Docker, Kubernetes, CI/CD, PostgreSQL, сетям и безопасности.