Что изобрела Радия Перлман и как Spanning Tree предотвращает петли и сбои в Ethernet. Простое объяснение STP, RSTP, практики и ошибки.
Ethernet-сети любят резервирование: если один кабель или коммутатор выйдет из строя, трафик должен пойти по запасному пути. На схемах это выглядит как «больше связей = больше надёжности». На практике у Ethernet есть неприятная особенность: когда вы добавляете лишние соединения между коммутаторами, вы почти неизбежно создаёте петлю.
В IP-маршрутизации петли обычно ограничены временем жизни пакета (TTL). А вот Ethernet-коммутаторы пересылают кадры на основе таблицы MAC-адресов и особенно «не любят» широковещательные и неизвестные кадры (broadcast/unknown unicast). Такие кадры коммутатор раздаёт во все порты — это нормальный механизм, благодаря которому сеть «узнаёт» устройства.
Но если есть петля, широковещание начинает ходить по кругу и размножаться. Таблицы MAC-адресов «скачут» (MAC flapping), каналы забиваются, задержки растут — и сеть может буквально задохнуться, даже если физически ничего не сломалось.
Spanning Tree Protocol (STP) — это способ сделать сеть одновременно:
Идея проста: коммутаторы договариваются, какие порты временно «приглушить», чтобы сохранить единственную логическую топологию без циклов, но оставить запасные линии на случай аварий.
STP — почти неизбежный спутник L2-сетей на коммутаторах: в офисах, кампусных сетях, в серверных и ЦОД (особенно в классических схемах агрегации/доступа). В этом материале разберём базовые термины, логику работы STP и практические советы, как сделать его поведение предсказуемым (см. также /blog).
Радия Перлман — американский инженер и исследователь в области сетей, чьё имя чаще всего связывают со Spanning Tree Protocol (STP). Её вклад важен не «громкими» продуктами, а тем, что она помогла сделать Ethernet‑сети предсказуемыми и живучими при реальных сбоях и ошибках подключения.
Большинство пользователей никогда не слышали о Перлман — и это показательно. Когда сеть работает, она не привлекает внимания. STP относится к тем технологиям, которые редко обсуждают вне инженерных команд, но от которых зависит повседневная связность: офисные сети, кампусы, дата‑центры (в классических схемах), промышленные сегменты.
Если в сети появляются лишние «кольца» и обходные пути, STP помогает избежать катастрофических последствий и сохранить сервисы доступными.
В период, когда Ethernet активно распространялся, сети усложнялись: появлялось больше коммутаторов, резервных соединений и «страховочных» кабелей между стойками и этажами. Резервирование полезно, пока оно управляемо. Без специального механизма лишняя перемычка могла превратить локальную сеть в источник самоподдерживающегося хаоса из повторяющихся кадров.
Перлман работала над алгоритмической основой STP: сеть из множества физических связей должна автоматически выбирать дерево — набор путей без петель — и при этом уметь перестраиваться при отказах. В этом ценность подхода: меньше ручной магии, больше чётких правил, которые коммутаторы могут выполнять сами.
Ethernet устроен так, что коммутаторы стараются «доставить кадр куда надо», а если не знают — рассылают его всем. Это нормально, пока в сети нет петель.
Петля возникает, когда между двумя (или несколькими) коммутаторами есть два и более активных пути одновременно. Например, вы подключили запасной кабель «на всякий случай», и оба кабеля работают параллельно. Кадр может пойти по одному пути, вернуться по другому и начать циркулировать по кругу.
На уровне IP у пакетов есть TTL, который ограничивает «жизнь» пакета. У обычных Ethernet-кадров такого ограничителя нет, поэтому при неудачном сценарии они могут множиться и ездить по сети бесконечно.
Широковещательные кадры (broadcast) коммутатор обязан отправить во все порты в рамках VLAN. При петле такой кадр возвращается, снова рассылается «во все стороны», затем возвращается ещё раз — и так далее. В итоге сеть сама генерирует всё больше копий одного и того же трафика. Это и называют широковещательным штормом.
Обычно это не похоже на «аккуратную» поломку одного сервиса. Скорее вы увидите:
Если шторм начинается в одном сегменте, он быстро забивает uplink’и, и страдают все: корпоративный Wi‑Fi, телефония, доступ к облакам, сайты — хотя внешний канал может быть исправен. Поэтому инцидент часто воспринимается как «проблема у провайдера», хотя корень — в локальной Ethernet-петле.
Смысл Spanning Tree Protocol (STP) проще, чем кажется: в сети может быть сколько угодно физических соединений «на всякий случай», но в каждый момент времени между любыми двумя узлами должен оставаться только один активный логический маршрут для кадров Ethernet. Тогда сеть не зациклится и не начнёт бесконечно «гонять» трафик по кругу.
Представьте схему дорог между городами. Если на развязках нет правил, машины могут попадать в бесконечные круги. STP строит «остов» — набор связей, который соединяет все коммутаторы без петель. Всё, что не входит в этот остов, временно переводится в блокировку.
STP не «отрубает» резерв навсегда. Лишние пути не удаляются физически и не ломают отказоустойчивость — они остаются подключёнными, но один (или несколько) портов переводится в состояние, при котором он не пересылает пользовательские кадры.
Если активный линк падает или кто-то выдернул кабель, протокол пересчитает остов и разблокирует ранее «лишний» путь. Для пользователя это выглядит как автоматическая перестройка маршрута внутри L2-сети.
Участники простые:
«Конвергенция» — это время, за которое сеть успевает заметить изменение (например, обрыв связи) и снова прийти к согласованному состоянию: где теперь проходит единственный логический путь, а какие порты должны подождать в резерве. Чем быстрее конвергенция, тем меньше «пауза» в работе приложений при авариях.
STP можно представить как «диспетчера», который смотрит на сеть из коммутаторов и решает: какие соединения оставить активными, а какие временно притормозить, чтобы не возникла петля. При этом физически кабели остаются на месте — меняется только логика пересылки.
Сначала коммутаторы выбирают root bridge — опорную точку, относительно которой строится всё дерево. Обычно root становится устройство с меньшим Bridge ID (приоритет + MAC-адрес).
Почему это важно: если root выбран случайно (например, «краевой» коммутатор в офисе), пути могут получиться неочевидными, а переключения — менее предсказуемыми. Поэтому root обычно назначают ближе к ядру сети, задавая меньший приоритет.
Дальше каждый коммутатор выбирает лучший путь к root. «Лучший» — это путь с минимальной стоимостью, которая зависит от скорости линка: быстрые соединения считаются дешевле, медленные — дороже.
Важно, что STP не пытается балансировать трафик по всем линкам. Его цель — оставить один логически безопасный маршрут и держать остальные как резерв.
У каждого сегмента определяется порт, который будет пересылать кадры (designated), а на каждом не-root коммутаторе выбирается порт, ведущий к root (root port). Остальные порты, способные создать петлю, переводятся в состояние блокировки: они не пересылают пользовательский трафик, но продолжают «слушать» служебные сообщения STP.
Когда активный путь пропадает, STP пересчитывает дерево и один из ранее заблокированных портов становится рабочим. В результате резервный кабель «оживает» автоматически — без ручного переключения, но с паузой на согласование.
Чтобы Spanning Tree работал, коммутаторам нужно «обменяться мнениями» о том, какая топология сейчас лучшая и какие порты стоит временно заблокировать. Для этого STP использует BPDU (Bridge Protocol Data Units) — служебные сообщения, которые регулярно отправляются между соседними коммутаторами.
BPDU можно представить как короткую записку: «вот кто у нас главный, вот как до него добраться, вот мои параметры». Внутри — идентификатор корневого коммутатора (root), стоимость пути до него, идентификатор отправителя и информация о таймерах. На основе этих сообщений каждый коммутатор сравнивает варианты и выбирает:
STP — командная игра. Если в одном сегменте STP выключен, а в другом включён, сеть может попасть в странное состояние: часть устройств будет ждать блокировок, а часть — свободно разливать широковещание по кольцу. Итог — рост задержек, «штормы» и нестабильность, которую сложно воспроизводить.
Опасный сценарий — кто-то подключает небольшой коммутатор «для удобства», замыкает два порта патч-кордом или добавляет второй аплинк. Такой узел начинает участвовать в обмене BPDU и может неожиданно стать root (например, из‑за более низкого приоритета), изменив поведение всей L2-сети.
Если в инфраструктуре есть разные поколения оборудования, важно убедиться, что режимы STP совпадают (STP/RSTP/MSTP) и корректно согласованы на стыках. Иначе быстрые ожидания RSTP могут “упереться” в более медленную логику классического STP, а время сходимости — неприятно вырасти.
Классический STP (802.1D) решает главную задачу — убирает петли, оставляя один логический путь при наличии резервных линков. Но у него есть практический минус: заметная задержка при перестроении.
В традиционном STP порты проходят последовательные состояния, прежде чем начать передавать трафик. При обрыве линка или смене топологии сеть «думает» ощутимое время: пользователи видят подвисания, VoIP может обрываться, а приложения — терять соединения. В небольшой сети это терпимо, но в офисе с множеством коммутаторов и критичными сервисами задержки быстро становятся проблемой.
RSTP (802.1w) — это STP, адаптированный под реальные ожидания от отказоустойчивости. Он сокращает время восстановления за счёт более «прямого» обмена служебной информацией и быстрых переходов портов в рабочее состояние там, где это безопасно.
На практике это означает: при отказе одного линка резервный путь активируется значительно быстрее, а кратковременные обрывы менее заметны для пользователей. В большинстве современных сетей именно RSTP становится «режимом по умолчанию», если нет особых требований.
MSTP (802.1s) полезен там, где много VLAN, а держать отдельное дерево на каждую (как в некоторых вариантах STP) — слишком накладно и сложно в сопровождении. MSTP позволяет группировать VLAN в несколько экземпляров деревьев, распределяя нагрузку и сохраняя предсказуемость.
Если сеть небольшая и простая, а простои некритичны — STP может быть достаточно, но чаще это выбор «по наследству».
Если нужна быстрая реакция на изменения и обычная L2-архитектура без сложной сегментации — выбирайте RSTP.
Если VLAN много, есть требования к управляемому распределению путей и хочется контролировать, какие группы VLAN идут по каким резервам — смотрите в сторону MSTP.
STP часто обвиняют в «тормозах» и внезапных обрывах связи, но в большинстве случаев протокол не мешает — он честно реагирует на ошибки проектирования и настройки. Ниже — типовые сценарии, из‑за которых сеть начинает жить своей жизнью.
Если не назначить корневой коммутатор (root bridge) явно, им может стать любой — тот, у кого ниже приоритет/идентификатор. После перезагрузки, замены оборудования или подключения нового свитча root внезапно «переедет», и STP начнёт перестраивать дерево. Итог: кратковременные потери связи, неожиданная блокировка портов и ощущение, что «STP сломался».
Правильная практика — заранее выбрать 1–2 устройства как root и secondary root, выставив приоритеты так, чтобы результат был предсказуемым.
STP принимает решения на основе стоимости пути до root. Если стоимости/приоритеты не продуманы, протокол может заблокировать «толстый» аплинк и оставить рабочим более слабый или перегруженный канал — формально всё корректно, но производительность падает.
Классика: сотрудник подключает ПК по кабелю и одновременно через док‑станцию/телефон, или принтер получает второй кабель «на всякий случай». Иногда второй порт появляется через маленький неуправляемый свитч под столом. Такие петли быстро приводят к широковещательным штормам, а STP, пытаясь спасти ситуацию, начинает блокировать порты — и страдают «невиновные».
Отключать STP на коммутаторах доступа из‑за мифических задержек — опасно. Один ошибочный патч‑корд или несанкционированный мини‑свитч, и сеть может деградировать до полной неработоспособности. Если нужны быстрые подъёмы портов для конечных устройств, это решают режимами edge/portfast и защитами, а не выключением STP.
Резервные связи должны быть спроектированы так, чтобы STP блокировал «правильную» ветку и быстро переключался при аварии. Для этого важно:
Когда резервирование продумано, STP перестаёт «мешать» и становится предсказуемым механизмом безопасности и отказоустойчивости.
STP хорошо работает «из коробки», но в реальных сетях его поведение стоит сделать управляемым: заранее определить, кто принимает ключевые решения, и где защита должна срабатывать автоматически. Тогда и расширения, и аварии проходят без сюрпризов.
Root bridge — это «центр тяжести» дерева: от него зависят активные пути. Если его не выбрать заранее, им может стать случайный коммутатор (например, новый в стойке).
Практика простая: назначьте основной root на самом устойчивом и центральном коммутаторе (обычно ядро/дистрибуция), а резервный root — на соседнем устройстве того же уровня. Делается это приоритетами STP: основной — самый низкий приоритет, резервный — чуть выше, остальные — выше обоих.
На портах, ведущих к конечным устройствам (ПК, принтеры, точки доступа), включают «быстрый старт» (PortFast/edge), чтобы устройства получали связь сразу.
Но быстрый старт безопасен только вместе с защитой от петель:
Поддерживайте актуальную схему L2 (какие порты куда, где trunk, где access) и короткий журнал изменений: «что переставили, когда, кто делал, какой порт/патч-панель». Это резко ускоряет поиск причин «штормов».
Если такой учёт хочется делать не в разрозненных таблицах, а как в небольшом внутреннем сервисе (инвентаризация линков, «кто root», какие порты edge, чеклист ввода нового коммутатора), его удобно быстро собрать на TakProsto.AI: описываете требования в чате — и получаете готовое веб‑приложение с хранением данных и возможностью дорабатывать и выгружать исходники.
Когда в L2-сети появляется петля, симптомы часто выглядят как «всё сломалось сразу»: пользователи жалуются на недоступность сервисов, телефония рвётся, Wi‑Fi «отваливается», а загрузка каналов внезапно становится 100% даже без видимой причины.
Типичные признаки петли — резкий рост широковещательного/многоадресного трафика (ARP, DHCP, неизвестные unicast), скачки задержек и массовые потери пакетов. Коммутаторы могут начать «шуметь» логами о частых изменениях топологии.
Быстрые шаги:
В первую очередь полезны три группы сигналов:
Состояние портов STP/RSTP: какие порты в Forwarding, какие заблокированы, нет ли неожиданно «Designated» там, где ожидали блокировку.
Изменения топологии: частые TCN/Topology Change и постоянные перерасчёты — индикатор нестабильного кольца или неправильной роли портов.
Счётчики: всплеск broadcast/multicast, рост unknown unicast, ошибки/дропы на uplink’ах. Если один порт «льёт» заметно больше остальных — это кандидат №1.
Самый надёжный способ — поочерёдно отключать подозрительные связи, начиная с access‑uplink’ов и неожиданных «дублирующих» патч‑кордов. После каждого отключения смотрите: упал ли широковещательный трафик, стабилизировались ли роли STP, прекратились ли изменения топологии.
После восстановления:
Так инцидент превращается из «мистики» в повторяемый процесс: обнаружили — локализовали — устранили — укрепили конфигурацию.
STP и его быстрые варианты (RSTP/MSTP) часто «просто работают», но иногда требования к предсказуемости и масштабу заставляют проектировать сеть так, чтобы зависимость от классического STP была минимальной.
Главная претензия не в том, что STP «плох», а в том, что он делает сеть менее детерминированной: путь трафика может зависеть от выборов протокола, а часть физических линий оказывается заблокированной «на всякий случай».
Типичные причины пересмотреть дизайн:
Самый практичный соседний инструмент — агрегация каналов (LACP/Port-Channel). Несколько физических линков объединяются в один логический: пропускная способность растёт, а для сети это выглядит как один «кабель», поэтому вероятность петель снижается.
Другой популярный ход — строить топологию, где петель нет по определению: например, делать больше маршрутизации (L3) ближе к краю сети, ограничивая размер L2-сегментов. Тогда широковещательные проблемы локализуются, а отказоустойчивость достигается за счёт маршрутизации, а не блокировок STP.
В крупных ЦОД и «фабриках» встречаются решения уровня SPB/TRILL или современные оверлеи вроде EVPN/VXLAN — они позволяют использовать несколько путей одновременно и лучше контролировать масштабирование. Но это уже другой класс архитектуры.
Если у вас небольшая или средняя сеть, умеренное число VLAN и ясная схема резервирования — RSTP/MSTP обычно достаточно.
Сигналы, что пора думать шире: регулярные широковещательные инциденты, постоянные изменения топологии, «простои при перекоммутации», желание задействовать все аплинки без блокировок.
Важно: «замена STP» — не галочка в настройках, а проектирование (топология, домены L2/L3, сценарии отказов, эксплуатация). И часто разумнее не «убрать STP», а сделать так, чтобы сеть редко ставила его в стрессовые условия.
Spanning Tree Protocol решает приземлённую, но критическую проблему Ethernet: избыточные физические связи нужны для отказоустойчивости, но в L2 они легко превращаются в петли. А петли быстро приводят к широковещательным «штормам», скачкам MAC-таблиц и ощущению, что «вся сеть легла» без явной причины.
Идея Перлман проста: пусть кабелей и резервных путей будет много, но логический путь для кадров — один. STP (и его более быстрые варианты) делает это автоматически: блокирует часть портов, оставляя дерево без петель, и при аварии перестраивает путь. Поэтому протокол редко заметен в обычной работе — и именно этим ценен.
Если хочется предсказуемости, STP лучше не «оставлять на волю случая»:
Полезно укрепить базу: различия L2/L3, почему маршрутизация снижает домен отказа, и как проектировать отказоустойчивость так, чтобы она не создавала скрытые риски.
Проведите небольшой аудит: где у вас корень STP, какие порты считаются edge, есть ли защиты, и совпадает ли текущая топология с тем, как вы представляете её на схеме. Часто одного такого просмотра достаточно, чтобы «штормы» так и не случились — особенно если результаты аудита превращаются в понятные чеклисты и живую документацию, которую команда реально обновляет.
STP (Spanning Tree Protocol) не даёт L2-сети «зациклиться», когда между коммутаторами есть лишние резервные связи.
У обычных Ethernet-кадров нет TTL, поэтому кадры broadcast/unknown unicast могут циркулировать и размножаться бесконечно.
Практические последствия:
Root bridge — опорный коммутатор, относительно которого строится всё дерево STP. Если root выбран случайно (например, на «краю»), активные пути могут стать неожиданными.
Чтобы сделать поведение предсказуемым:
STP сравнивает пути к root по суммарной стоимости (path cost), которая обычно зависит от скорости линков: быстрее = «дешевле».
Если стоимость/приоритеты не продуманы, возможны сюрпризы:
Минимальная практика — проверить, какие именно порты должны быть основными/резервными, и под это настроить приоритеты и/или cost.
BPDU — служебные сообщения STP, которыми коммутаторы обмениваются, чтобы договориться о root, стоимости пути и ролях портов.
Что полезно помнить:
Классический STP (802.1D) может сходиться заметно дольше при изменениях топологии. RSTP (802.1w) ускоряет переходы портов в рабочее состояние там, где это безопасно.
На практике:
MSTP (802.1s) полезен, когда VLAN много и нужно управляемо группировать их в несколько экземпляров деревьев, вместо «отдельного дерева на каждый VLAN».
Это помогает:
Типовые ошибки обычно не «в STP», а в том, как сеть собрана и защищена:
Для портов к конечным устройствам обычно включают edge/PortFast, чтобы линк поднимался быстро, но обязательно добавляют защиты.
Практичный минимум:
Действуйте по шагам, чтобы быстро сузить область проблемы:
Зафиксируйте время начала и какие сегменты пострадали (этаж/стойка/VLAN).
На коммутаторах проверьте:
Локализуйте, отключая по одному подозрительные подключения (в первую очередь access-сегменты и «дублирующие» патч-корды).
После восстановления закрепите root/secondary root и включите защиты на edge-портах, чтобы инцидент не повторился.
