13 дек. 2025 г.·8 мин
Spanning Tree Радии Перлман: тихая основа Ethernet
Познакомьтесь с Радией Перлман и узнайте, как Spanning Tree Protocol предотвращает петли Ethernet, обеспечивает резервирование и сделал крупные сети стабильными и надёжными.
Познакомьтесь с Радией Перлман и узнайте, как Spanning Tree Protocol предотвращает петли Ethernet, обеспечивает резервирование и сделал крупные сети стабильными и надёжными.
Ethernet начинался как простой способ соединить компьютеры в одном здании. По мере того как он распространялся по офисам, кампусам и центрам обработки данных, ожидания изменились: локальные сети перестали быть просто «приятным дополнением» — они стали инфраструктурой для почты, общего доступа к файлам, принтеров, телефонов и, в конце концов, для целых бизнес‑процессов. Когда эта «трубопроводная» инфраструктура давала сбой, всё верхнее уровень также останавливалось.
Строители сетей получили жёсткий урок надёжности: если спроектировать сеть с единственным путём между устройствами, один оборванный кабель или коммутатор могут вывести из строя целую зону. Очевидный выход — резервирование: дополнительные каналы и коммутаторы.
На уровне 2 Ethernet, однако, резервирование имеет опасный побочный эффект: петли.
Радия Перлман разработала Протокол Spanning Tree (STP) — механизм, который позволяет сетям Ethernet иметь резервирование без катастрофического поведения при появлении петель. Её вклад — не «широкие трубы», а практический распределённый способ, с помощью которого коммутаторы координируются, приходят к согласию по безопасной структуре пересылки и автоматически адаптируются при изменениях топологии.
STP — это система, которую замечают только тогда, когда её нет или она неправильно настроена. Когда всё работает, ничего не выглядит особенным: трафик течёт, линков остаются активными, и сеть терпит отказы. Она тихо блокирует ровно столько путей, чтобы предотвратить петли, при этом сохраняя альтернативы готовыми на случай разрыва активного пути.
Мы сделаем проблему осязаемой: покажем, как выглядит петля Ethernet и почему она вызывает штормы и отказы. Затем пройдёмся по основной идее STP — как он сохраняет резервирование, но устраняет петли — и объясним простыми словами, как коммутаторы решают, какие порты пересылать, а какие оставлять в резерве. К концу вы получите интуитивную модель, почему STP стал фундаментом коммутации уровня 2 и почему дизайн Перлман до сих пор важен, даже когда Ethernet вырос далеко за пределы ранних офисных сценариев.
Ранние сети Ethernet часто были небольшими и простыми: несколько машин на общем сегменте или, позднее, несколько коммутаторов (и «мостов», старый термин), соединявших сегменты. Если один кабель был выдернут, люди это замечали — но отказ было легко понять.
По мере того как организации добавляли комнаты, этажи и здания, сеть редко росла по аккуратному плану. Она росла как живой организм: новый коммутатор здесь, «аварийная» прокладка кабеля там, временное решение, которое тихо стало постоянным.
Когда сеть расширяется так, добавляются дополнительные связи по практическим причинам:
По отдельности каждое изменение может казаться безвредным. В совокупности они могут создать несколько путей между одними и теми же коммутаторами.
Резервирование желанно, потому что повышает время доступности. Если один канал падает, трафик может пойти по другому пути и пользователи остаются продуктивными.
Но на уровне 2 (коммутация) Ethernet не был рассчитан на то, чтобы автоматически «выбирать» один путь и игнорировать остальные. Коммутаторы пересылают кадры, опираясь на изученные адреса, и без координации несколько путей могут создать петлю.
Вот в чём суть противоречия: больше кабелей может случайно разрушить сеть. Те самые соединения, которые добавляли для повышения безопасности, могут создать условия, при которых трафик бесконечно циркулирует, перегружая каналы и устройства. Spanning Tree был создан, чтобы сохранить преимущества резервирования и при этом предотвратить эти случайные, масштабные сбои.
Петля коммутации Ethernet возникает, когда существует два или более активных пути уровня 2 между одними и теми же коммутаторами — часто потому, что кто‑то добавил «резервный» кабель, подключил оба аплинка в одну сеть или соединил коммутаторы в кольцо без управляющего механизма. Кадры на уровне 2 не имеют ограничения по числу прыжков, поэтому они могут бесконечно циркулировать.
Некоторый трафик предназначен для рассыла: широковещательные сообщения (например, ARP‑запросы) и кадры с «неизвестным адресом назначения» (когда коммутатор ещё не знает, на каком порту находится MAC). В петле такой кадр многократно копируется и отправляется по кругу.
Простой пример: ПК спрашивает «Кто имеет 10.0.0.5?» через ARP (broadcast). В петле каждый коммутатор повторяет широковещание по нескольким портам, и повторяющиеся копии продолжают приходить обратно другим коммутаторам. Очень быстро каналы и CPU коммутаторов тратят почти всё время на обработку дубликатов, оставляя мало места для реального трафика.
Коммутаторы изучают, где находятся устройства, наблюдая, на каком порту приходит исходный MAC‑адрес. В петле кадры одного и того же устройства могут приходить на разные порты с интервалами в миллисекунды. Коммутатор постоянно «меняет решение» о том, где находится MAC, многократно перезаписывая таблицу. В результате трафик пересылается не на тот порт, затем падает в широковещание, затем снова неправильно изучается.
Эти эффекты складываются в симптомы, которые люди узнают: внезапные замедления сети по всей инфраструктуре, прерывания соединений, обрывы звонков, Wi‑Fi «работает, но непригоден», а иногда полный отказ, когда коммутаторы переполняются и перестают отвечать. Один случайный патч‑кабель может вывести из строя гораздо больше, чем два устройства, которые он связывает.
Устойчивость Ethernet обеспечивается тем, что существует более одного возможного пути между коммутаторами. Если кабель обрывается, трафик может пойти по альтернативе. Но лишние пути могут случайно сформировать круг — и кадры Ethernet не имеют поля «время жизни», чтобы остановиться.
Spanning Tree Protocol (STP) решает это просто: оставьте резервные соединения физически подключёнными, но логически отключите некоторые из них, чтобы активная сеть представляла собой безпетлевое дерево.
Представьте город, который строит дополнительные дороги, чтобы скорая помощь могла достичь любого района при закрытии улицы. Если открыть все дороги без правил, могут возникнуть запутанные круговые маршруты, где водители будут постоянно ездить по одним и тем же кварталам.
STP работает как регулировщик движения:
Ключевая часть дизайна Радии Перлман в том, что STP не опирается на контроллер, который командует всем коммутаторам. Каждый коммутатор участвует, обменивается небольшими сообщениями и независимо приходит к тому же выводу о том, какие ссылки должны пересылать, а какие должны ждать в резерве.
Это делает STP практичным в реальных сетях: вы можете добавлять коммутаторы, убирать ссылки или терпеть отказы, и сеть сходится к безопасному шаблону пересылки.
При правильной настройке STP обеспечивает две, казалось бы, конфликтующие вещи:
STP выполняет одно: сохраняет резервирование Ethernet, не допуская бесконечной циркуляции трафика. Он заставляет все коммутаторы согласовать один «лучший» набор ссылок для пересылки — называемый spanning tree — и переводит дополнительные ссылки в резервное состояние.
STP сначала выбирает root bridge — коммутатор, который служит эталоном для всей сети. Думайте о нём как о «центре карты». Корень определяется по значению приоритета (настроенному или по умолчанию) и уникальному идентификатору коммутатора; побеждает наименьшее значение.
Каждый коммутатор спрашивает себя: «Какой у меня лучший путь до корня?» STP назначает стоимость пути каждой ссылке (быстрые ссылки обычно имеют меньшую стоимость). Каждый коммутатор суммирует стоимости вдоль возможных маршрутов и выбирает маршрут с наименьшей суммарной стоимостью.
Порт, который ненулевой (не‑root) коммутатор использует для достижения корня по лучшему маршруту, становится его root port.
На каждом общем соединении между коммутаторами (сегменте) STP должен выбрать ровно один коммутатор, который будет пересылать трафик к корню. Такой пересылающий порт называется designated port для сегмента. Коммутатор, который объявляет наименьшую стоимость пути к корню на этом сегменте, получает роль designated.
Порты, которые не выбраны ни в root port, ни в designated port, переводятся в состояние blocking (STP) или в аналогичное невпресылочное состояние (в новых вариантах). Блокировка не снимает кабель и не уничтожает резервирование — она просто препятствует пересылке обычных Ethernet‑кадров, чтобы петля не могла сформироваться. Если активный линк падает, STP может разблокировать резервный путь и сохранить связность.
Рассмотрим маленькую сеть из четырёх коммутаторов:
STP стартует с выбора единой точки отсчёта: root bridge. Каждый коммутатор объявляет идентификатор (bridge ID), и наименьший ID выигрывает.
Предположим, что S1 имеет наименьший bridge ID. Теперь все соглашаются: S1 — корень.
Каждый ненулевой коммутатор выбирает один порт как root port — порт, который обеспечивает лучший путь обратно к S1.
Для каждого сегмента STP выбирает, какая сторона будет designated port и будет пересылать трафик к корню. Любой порт, который не является root port или designated port, станет blocking.
В нашем примере петля разрывается на звене S3–S4. Если S3 уже достигает корня через S2, STP может поместить порт S3 в сторону S4 (или порт S4 в сторону S3, в зависимости от правил) в состояние blocking.
Результат: все кабели остаются подключены, но между любыми двумя точками существует только один активный путь — петли нет.
Если активный путь разрывается (например, S2–S3 падает), STP пересчитывает роли. Ранее заблокированная связь S3–S4 может перейти в пересылку, восстанавливая связность по маршруту S3 → S4 → S1.
Это изменение не происходит мгновенно; STP требует времени для конвергенции, чтобы безопасно обновить состояния портов без повторного введения петель.
STP работает только если все коммутаторы в домене следуют одним и тем же правилам. Поэтому стандарты важны: реальные сети часто мультивендорные, составлены из устройств, купленных в разное время. Без общего протокола функция предотвращения петель у одного вендора может не пониматься устройствами другого, и вместо резервирования вы получите отказ.
Традиционный Spanning Tree Protocol описан в IEEE 802.1D. Читая стандарт детально, вы не обязаны знать все формулировки — суть в том, что 802.1D даёт вендорам общий язык для выбора корня, расчёта стоимости пути и определения, какие порты должны пересылать или блокировать.
Даже при переходе на более новые варианты (RSTP, MSTP) обновления возможны именно потому, что поведение стандартизовано, и устройства могут координироваться, а не гадать.
Коммутаторы координируются с помощью служебных кадров BPDU (Bridge Protocol Data Units). Думайте о BPDUs как о «приветственных сообщениях» STP: они несут информацию, необходимую коммутаторам для построения общего представления топологии — кто корень, какова стоимость до корня и детали тайминга.
Поскольку BPDUs постоянно обмениваются, STP может реагировать на изменения: если линк падает, диалог BPDU меняется, и коммутаторы сходятся на новой безопасной топологии.
Практическая загвоздка: вендоры часто дают разным настройкам разные имена. Опции вроде «port cost», «edge/PortFast» или «bpdu guard» могут находиться в разных меню или быть сформулированы по‑разному. Базовые концепции STP остаются прежними, но интерфейсная терминология может отличаться — полезно переводить настройку в понятия 802.1D.
Классический STP (IEEE 802.1D) решил проблему петель, но мог очень медленно «залечивать» сеть после отказа. Причина проста: STP был осторожен. Порты не переходили сразу в пересылку — они последовательно проходили состояния (blocking → listening → learning → forwarding). Со стандартными таймерами реконвергенция могла занимать десятки секунд (обычно ~30–50 с), что достаточно, чтобы звонки прервались, приложения таймаутились или пользователи решили, что сеть упала.
Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) сохраняет цель — отсутствие петель с резервированием — но меняет способ достижения согласия между коммутаторами.
Вместо ожидания длительных фиксированных таймеров RSTP использует более быстрый обмен для подтверждения, какие порты безопасно переводить в пересылку. Он также распознаёт, что некоторые порты могут переходить сразу:
Проще говоря: RSTP по‑прежнему блокирует ненужные ссылки, но перестаёт считать каждое изменение худшим сценарием.
По мере роста сетей запуск единого дерева для всего становился ограничением — особенно при большом количестве VLAN и сложной топологии. Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) позволяет создавать несколько инстансов остовного дерева и сопоставлять группы VLAN с каждым инстансом.
Это даёт возможность:
Общий итог развития STP → RSTP → MSTP: сохранять резервирование, предотвращать петли и восстанавливать пересылку быстрее и предсказуемо.
Наименее оценённое преимущество Spanning Tree — это то, как он превращает «лишние кабели и коммутаторы» в предсказуемую надёжность. В крупных предприятиях — множество стоек, множество коммутаторов доступа, постоянные перемещения и изменения — резервирование уровня 2 может быть благом или ловушкой. STP делает из этого скорее благо.
Крупные сети редко падают из‑за одного оборванного кабеля; они выходят из строя потому, что восстановление бывает хаотичным. STP помогает, задавая контролируемый способ реакции сети на изменения:
Многие организации держат STP включённым, даже если они думают, что их топология свободна от петель. Причина прагматична: люди ошибаются, документация ветшает, и неожиданные пути уровня 2 появляются. С включённым STP случайный дополнительный патч‑кабель скорее приведёт к заблокированному порту, чем к отказу всего здания.
Современные дата‑центры часто предпочитают маршрутизируемые leaf–spine‑фабрики (уровень 3) или специальные многопутевые технологии уровня 2, чтобы получить активный/активный пропускной канал без опоры на классическую конвергенцию STP. Тем не менее STP (или его варианты RSTP/MSTP) всё ещё широко используется в кампусных сетях, на краевых сегментах и там, где чистый уровень 3 непрактичен.
В масштабе главное достижение STP не столько техническое, сколько эксплуатационное: он делает резервирование управляемым для обычных команд, а не только для узких специалистов.
STP прост по концепции — предотвратить петли уровня 2 и сохранить резервные пути — но несколько устойчивых мифов заставляют людей отключать его, неправильно настраивать или «оптимизировать» до состояния отказа.
Действительно, современные сети часто опираются на маршрутизацию уровня 3, MLAG и оверлейные конструкции, которые уменьшают необходимость классического IEEE 802.1D. Но STP (или его быстрые/множественные варианты) всё ещё даёт страховку везде, где Ethernet может случайно сформировать петлю: коммутаторы доступа, временные сети для мероприятий, лаборатории, небольшие филиалы и любые среды, где кто‑то может подключить два порта вместе «просто чтобы проверить».
Отключение STP может превратить безобидную ошибку кабельщика в широковещательный шторм, который отключит целую VLAN.
Заблокированный порт не «мертв». Это заранее проверенный резервный путь. STP сознательно жертвует частью активной ёмкости ради стабильности: если основной канал упадёт, заблокированный станет новым активным путём без участия человека. Команды иногда пытаются заставить все ссылки работать, отключая STP, уплощая VLAN или добавляя неуправляемые коммутаторы. Это может выглядеть эффективно — до первой петли, которая «расплавит» сеть.
Резервирование полезно только если оно спроектировано. Добавление дополнительных кросс‑ссылок между коммутаторами без плана увеличивает число возможных сценариев петель и усложняет поведение STP. Результат — неожиданные пути трафика, заблокированные аплинки или удлинённая реконвергенция.
Даже при включённом STP неправильные параметры могут причинить вред:
Вывод: STP — не просто галочка в настройках. Это компонент плоскости управления. Относитесь к нему соответствующе: документируйте намерения и валидируйте изменения перед массовым развёртыванием.
Проблемы со Spanning Tree часто проявляются как «сеть тормозит», прежде чем кто‑то поймёт, что это проблема уровня 2. Пара целенаправленных проверок может сэкономить часы расследования.
При петле Ethernet или нестабильности STP обычно наблюдается:
Начните с основ:
Хорошая гигиена STP — это в основном процесс:
Если хотите более широкий чек‑лист для изоляции проблем сети помимо STP, см. /blog/network-troubleshooting-basics.
STP — хороший пример «тихой инфраструктуры», и он обычно ломается по очень человеческим причинам: неясные намерения, недокументированная разводка, несовместимые конфигурации и хаотичное устранение неполадок. Практический способ снизить риск — создать лёгкие внутренние инструменты и руковodства вокруг операций STP.
С помощью Koder.ai команды могут быстро программировать небольшие веб‑дашборды или утилиты через простой чат — например, инструмент, который собирает выводы коммутаторов, подчёркивает текущий root bridge, помечает неожиданные заблокированные порты или отслеживает события изменения топологии во времени. Поскольку Koder.ai поддерживает экспорт исходного кода и развёртывание/хостинг приложений (с возможностью отката и снимками), это удобный способ превратить «племенную» экспертизу в поддерживаемый внутренний сервис вместо одноразового скрипта на ноутбуке у одного инженера.
Работа Радии Перлман по spanning tree напоминает: самые важные элементы инфраструктуры не обязательно яркие — они просто предотвращают хаос. Давая Ethernet практический способ использовать резервные ссылки без создания петель, STP сделал «добавь резервный путь» безопасным по умолчанию, а не рискованным экспериментом. Эта перемена позволила создавать большие, более устойчивые сети уровня 2 в предприятиях, кампусах и ЦОДах.
STP предполагает, что что‑то пойдёт не так: кабель будет воткнут не в тот порт, коммутатор перезагрузится, линк будет флапать. Вместо надежды на то, что операторы никогда не ошибаются, система строится так, чтобы поглощать ошибки и сходиться к безопасному состоянию. Урок шире сетей: рассматривайте режимы отказа как первоочередные требования.
Spanning Tree сознательно блокирует часть ссылок, чтобы сеть оставалась стабильной. Эта «потерянная ёмкость» — осознанная жертва ради предсказуемости. Хорошие системы часто держат запас — дополнительное время, дополнительные проверки, дополнительные ограждения — потому что избегание катастрофы важнее, чем выжимание последнего процента загрузки.
STP работает потому, что каждый коммутатор следует одним распределённым правилам и обменивается небольшими служебными сообщениями, чтобы согласовать безпетлевую топологию. Не нужно, чтобы оператор вручную решал, какие порты отключать при каждом изменении. Вывод: когда много компонентов должны сотрудничать, инвестируйте в протоколы и настройки по умолчанию, которые делают безопасное поведение самым простым.
Если вы запомните только несколько вещей, пусть это будут: делайте резервирование, ожидайте человеческих ошибок и автоматизируйте «безопасный выбор». Такое мышление — больше, чем любая отдельная функция — объясняет, почему Spanning Tree стал такой тихой, но необходимой частью сетевой инженерии.
Если хотите больше простых материалов по основам сетей, просмотрите /blog.
Петля на уровне 2 возникает, когда у коммутаторов есть два или более активных пути между одними и теми же сегментами, создавая цикл. Поскольку Ethernet-кадры на уровне 2 не имеют предела по времени жизни, разлетающийся трафик (broadcast и неизвестные unicast) может бесконечно циркулировать и размножаться, перегружая каналы и процессоры коммутаторов.
Резервные пути добавляют альтернативные маршруты, но без координации коммутаторы могут начать пересылать трафик по всем ним одновременно. Это создаёт петлю, где широковещательные кадры многократно реплицируются, вызывая широковещательные штормы и нестабильное обучение MAC‑адресов — часто в результате один дополнительный патч‑кабель может привести к отказу всей сети.
STP оставляет резервные ссылки физически подключёнными, но логически отключает часть портов так, чтобы активная топология представляла собой ацикличное дерево. Если активный путь падает, STP переводит ранее заблокированный порт в состояние пересылки, восстанавливая связность.
STP проводит выборку root bridge — опорного коммутатора, который служит точкой отсчёта для всей доменной топологии уровня 2. Коммутатор с наименьшим bridge ID (приоритет + уникальный идентификатор) становится корнем; выбор правильного узла в роли корня помогает сохранить предсказуемость путей трафика.
Каждый ненулевой (не‑root) коммутатор выбирает один root port — порт с наименьшей суммарной стоимостью пути до корня. Стоимость пути обычно зависит от скорости канала (быстрые ссылки получают меньшую стоимость). В случаях равных сумм используются дополнительные критерии‑разрывители (IDs) для детерминированного выбора.
На каждом сегменте между коммутаторами STP выбирает одну сторону как designated port — тот порт, который должен пересылать трафик для этого сегмента (тот, кто объявляет лучший путь к корню). Любой порт, который не является ни root port, ни designated port, переводится в состояние blocking/discarding, и именно так STP разрывает петли.
Это означает, что порт не пересылает обычные пользовательские кадры, чтобы он не мог участвовать в петле. Кабель остаётся физически подключённым и может передавать служебные STP‑кадры; при изменении топологии (например, при падении активного пути) этот заблокированный порт может быть повышен до состояния пересылки.
BPDUs (Bridge Protocol Data Units) — это служебные кадры STP, которые коммутаторы обмениваются для передачи информации о топологии: кто, по их мнению, является корнем, какова их стоимость пути до корня и временные параметры. Постоянный обмен BPDU позволяет обнаруживать изменения и перерассчитать безопасную, неразрывную топологию.
Классический STP (IEEE 802.1D) часто восстанавливается медленно — десятки секунд — потому что он использует консервативные таймеры и переходы состояний портов. RSTP (IEEE 802.1w) ускоряет согласование за счёт более быстрого рукопожатия между коммутаторами и быстрых переходов, особенно для edge/PortFast‑портов, уменьшая время простоя после отказов.
Быстрая проверка включает: