Spanning Tree de Radia Perlman: a Espinha Dorsal Silenciosa do Ethernet

Por que o Spanning Tree se tornou um essencial silencioso

O Ethernet começou como uma forma simples de conectar computadores no mesmo prédio. À medida que se espalhou por escritórios, campi e data centers, as expectativas mudaram: redes locais deixaram de ser "agradáveis de ter" e se tornaram a canalização para e‑mail, compartilhamento de arquivos, impressoras, telefones e, eventualmente, fluxos de trabalho inteiros. Quando aquela canalização falhava, tudo a jusante também falhava.

Os projetistas de rede também aprenderam uma lição dura sobre confiabilidade: se você desenhar uma rede com apenas um caminho entre dispositivos, um único cabo ou switch com problema pode derrubar uma área inteira. A solução óbvia é redundância — links e switches extras.

Na Camada 2 do Ethernet, porém, redundância vem com um efeito colateral perigoso: loops.

A visão-chave de Radia Perlman

Radia Perlman projetou o Spanning Tree Protocol (STP), o mecanismo que permite que redes Ethernet tenham redundância sem entrar em colapso por loops. A contribuição dela não foi “tubulações maiores” — foi uma maneira prática e distribuída para switches coordenarem, concordarem sobre uma estrutura de encaminhamento segura e se adaptarem automaticamente quando a topologia muda.

“Infraestrutura silenciosa” que funciona melhor quando é invisível

O STP é o tipo de sistema que você só nota quando falta ou está mal configurado. Quando funciona, nada parece especial: o tráfego flui, os links permanecem ativos e a rede tolera falhas. Ele bloqueia silenciosamente apenas caminhos suficientes para prevenir loops, mantendo alternativas prontas caso um caminho ativo quebre.

O que você vai aprender neste guia

Vamos tornar o problema tangível mostrando como é um loop Ethernet e por que ele causa tempestades e quedas. Depois caminharemos pela ideia central do STP — como ele mantém redundância mas elimina loops — e explicaremos, em termos simples, como switches decidem quais links encaminham e quais ficam em reserva. Ao final, você terá um modelo intuitivo do porquê o STP se tornou fundamental para a comutação de Camada 2 e por que o projeto de Perlman ainda importa, mesmo com o Ethernet escalando muito além de suas origens em escritórios.

O problema que as redes Ethernet encontraram à medida que cresceram

As redes Ethernet iniciais eram frequentemente pequenas e diretas: algumas máquinas conectadas em um segmento compartilhado ou, mais tarde, alguns switches (e "bridges", o termo antigo) conectando segmentos. Se um cabo fosse desconectado, as pessoas notavam — mas a falha era fácil de entender.

À medida que organizações adicionavam salas, andares e prédios, a rede raramente crescia como um plano limpo. Ela crescia como algo vivo: um novo switch aqui, um cabo de "emergência" ali, um contorno temporário que virou permanente.

Crescimento orgânico cria caminhos surpresa

Quando redes se expandem assim, links extras são adicionados por razões práticas:

• Alguém quer melhor desempenho, então adiciona outra conexão entre switches.
• Uma equipe quer um caminho de backup “só por precaução”, então duplica um link.
• Mudanças e reformas deixam conexões legadas que ninguém documenta.

Individualmente, cada mudança pode parecer inofensiva. Coletivamente, elas podem criar múltiplos caminhos entre os mesmos switches.

Por que redundância é útil e arriscada

Redundância é desejável porque melhora o tempo de atividade. Se um link falha, o tráfego pode tomar outra rota e os usuários continuam produtivos.

Mas na Camada 2 (comutação), Ethernet não foi projetado para “escolher” automaticamente um caminho e ignorar os outros. Switches encaminham quadros com base em endereços aprendidos e, sem um controle coordenado, vários caminhos podem formar um loop.

Essa é a tensão principal: mais cabos podem acidentalmente quebrar a rede. As próprias conexões adicionadas para aumentar segurança podem criar condições onde o tráfego circula sem fim, sobrecarregando links e dispositivos. O Spanning Tree foi criado para manter os benefícios da redundância enquanto previne essas quedas auto‑infligidas em toda a rede.

Como é um loop Ethernet (e por que é ruim)

Um loop de comutação Ethernet ocorre quando existem dois (ou mais) caminhos ativos de Camada 2 entre os mesmos switches — muitas vezes porque alguém adicionou um cabo de backup, conectou ambos os uplinks na mesma rede ou formou um anel sem um mecanismo de controle. Quadros não têm limite de saltos na Camada 2, então podem circular indefinidamente.

Tempestades de broadcast (a falha barulhenta)

Alguns tráfegos devem ser inundados: broadcasts (como requisições ARP) e quadros de “destino desconhecido” (quando um switch ainda não sabe em qual porta está um MAC). Em um loop, esse quadro inundado é copiado e enviado em volta do loop, copiado de novo, e de novo.

Um exemplo simples: um PC pergunta “Quem tem 10.0.0.5?” via ARP (broadcast). Com um loop, cada switch repete o broadcast por múltiplas portas, e as cópias repetidas continuam chegando a outros switches. Muito rápido, links e CPUs dos switches gastam a maior parte do tempo lidando com duplicatas, sobrando pouco espaço para tráfego real.

Instabilidade da tabela MAC (a falha confusa)

Switches aprendem onde os dispositivos estão observando em qual porta chega um endereço MAC de origem. Em um loop, os frames do mesmo dispositivo podem chegar por portas diferentes com milissegundos de diferença. O switch fica “mudando de ideia” sobre onde aquele MAC está, reescrevendo sua tabela repetidamente. O resultado é tráfego sendo encaminhado para a porta errada, depois inundado, depois re­aprendido de novo.

O que você realmente sente: quedas, lentidão, flapping estranho

Esses efeitos se combinam em sintomas conhecidos: lentidões repentinas na rede inteira, desconexões intermitentes, telefones perdendo chamadas, Wi‑Fi que “funciona mas é inútil”, e às vezes uma queda completa quando switches saturam e deixam de responder. Um único cabo de remendo acidental pode derrubar muito mais do que os dois dispositivos que conecta.

A ideia central: redundância sem loops

O Ethernet obtém resiliência por ter mais de um caminho possível entre switches. Se um cabo é cortado, o tráfego pode pegar outra rota. O problema é que caminhos extras podem formar acidentalmente um círculo — e quadros Ethernet não têm um campo de "time to live" para detê‑los.

O Spanning Tree Protocol (STP) resolve isso com um acordo simples: mantenha os links redundantes fisicamente conectados, mas desative logicamente alguns deles de modo que a rede ativa forme uma árvore sem ciclos.

Uma analogia de controle de tráfego

Pense em uma cidade que constrói estradas extras para que ambulâncias ainda alcancem cada bairro quando há um bloqueio. Se a cidade abrir todas as estradas sem regras, podem surgir rotas circulares onde motoristas ficam dando voltas nos mesmos quarteirões.

O STP age como controle de tráfego:

• Permite que várias estradas existam.
• Fecha algumas “entradas” (portas) para evitar direção circular.
• Se uma estrada principal é bloqueada, reabre uma entrada anteriormente fechada para restaurar o acesso.

Automático e distribuído — sem cérebro central

Uma parte chave do projeto de Radia Perlman é que ele não depende de um controlador dizendo a cada switch o que fazer. Cada switch participa, trocando pequenas mensagens e chegando independentemente à mesma conclusão sobre quais links devem encaminhar e quais devem ficar em reserva.

Isso torna o STP prático em redes reais: você pode adicionar switches, remover links ou sofrer falhas, e a rede converge para um padrão de encaminhamento seguro.

A promessa

Feito corretamente, o STP entrega dois resultados que normalmente conflitam:

• Sem loops de Camada 2 durante a operação normal.
• Capacidade de failover quando um link ou switch morre, ao ativar um caminho de reserva.

Como o STP decide o que encaminhar e o que bloquear

O Spanning Tree Protocol (STP) tem um trabalho: manter a redundância do Ethernet sem deixar o tráfego girar indefinidamente em um loop. Faz isso fazendo todos os switches concordarem com um único conjunto “melhor” de links a usar a qualquer momento — chamado de spanning tree — e colocando os links extras em estado de espera.

Passo 1: Escolher um líder (a root bridge)

O STP primeiro elege uma root bridge, o switch escolhido como ponto de referência para toda a rede. Pense nele como “o centro do mapa”. O root é determinado por um valor de prioridade (configurado ou padrão) e um identificador único do switch; o menor vence.

Passo 2: Medir distância com custo de caminho

Cada switch então pergunta: “Qual é meu melhor caminho até o root?” O STP atribui um path cost a cada link (links mais rápidos geralmente têm custo menor). Cada switch soma custos ao longo das rotas possíveis e escolhe o menor total como sua rota preferida até o root.

A porta que um switch não‑root usa para alcançar o root nessa melhor rota torna‑se sua root port.

Passo 3: Escolher um encaminhador por segmento de rede (ports designadas)

Em cada conexão compartilhada entre switches (um “segmento”), o STP precisa que exatamente um switch encaminhe o tráfego em direção ao root. Essa porta que encaminha é a designated port do segmento. O switch que anuncia o caminho de menor custo ao root naquele segmento recebe o papel de designated.

O que “bloquear” realmente significa

Portas que não são root port nem designated port são colocadas em bloqueio (STP) ou em um estado similar não‑encaminhador (variantes mais novas). Bloquear não remove o cabo nem elimina a redundância — apenas impede que a porta encaminhe quadros Ethernet regulares, para que um loop não se forme. Se um link ativo falhar, o STP pode desbloquear um caminho de reserva e manter a rede conectada.

Um walkthrough simples de STP com uma rede pequena

Vamos tornar o STP concreto com uma pequena rede de quatro switches:

• S1, S2, S3, S4
• Os links formam um quadrado: S1–S2–S3–S4–S1
• Há um loop óbvio: quadros podem circular pelo quadrado para sempre.

Passo 1: Eleger um switch root

O STP começa escolhendo um ponto de referência único: a root bridge (switch root). Cada switch anuncia um identificador (o “bridge ID”) e o menor ID ganha.

Suponha que S1 tenha o menor bridge ID. Agora todos concordam: S1 é o root.

Passo 2: Escolher o melhor caminho de volta ao root

Cada switch não‑root escolhe exatamente uma porta como sua root port: a porta que fornece o melhor caminho de volta a S1.

• S2 escolhe seu link em direção a S1 como root port.
• S4 escolhe seu link em direção a S1 como root port.
• S3 tem duas escolhas iguais: pode alcançar S1 via S2 ou via S4. O STP desempata de forma previsível (com base em custo de caminho anunciado e IDs). Digamos que S3 escolha o caminho S3 → S2 → S1.

Passo 3: Decidir quais portas encaminham e qual porta bloqueia

Para cada link/segmento, o STP escolhe um lado para ser a designated port (o lado que deve encaminhar para aquele segmento). Qualquer porta que não seja uma root port nem uma designated port fica bloqueada.

Neste exemplo, o link S3–S4 é onde o loop é cortado. Se S3 já alcança o root via S2, o STP pode colocar a porta de S3 em direção a S4 (ou a porta de S4 em direção a S3, dependendo dos critérios de desempate) em bloqueio.

Resultado: todos os cabos continuam conectados, mas existe apenas um caminho ativo entre quaisquer dois pontos — sem loop.

O que acontece quando um link falha?

Se o caminho ativo quebrar (por exemplo, S2–S3 cair), o STP reavalia. O link previamente bloqueado S3–S4 pode transicionar para encaminhamento, restaurando a conectividade via S3 → S4 → S1.

Essa mudança não é instantânea; o STP precisa de tempo para convergir com segurança e atualizar estados de encaminhamento sem reintroduzir loops.

Padrões e as mensagens que switches trocam

O Spanning Tree só funciona se todos os switches na rede concordarem com as mesmas regras. Por isso padrões importam: redes reais são em geral multi‑fornecedor, montadas com o que foi comprado ao longo dos anos. Sem um protocolo comum, o recurso “prevenir loop” de uma marca pode não entender o da outra, e a redundância pode virar uma queda.

A referência clássica: IEEE 802.1D

O STP tradicional é definido no IEEE 802.1D. Você não precisa ler a norma para se beneficiar — o ponto chave é que 802.1D dá aos vários fornecedores uma linguagem comum sobre como eleger o root bridge, calcular custos de caminho e decidir quais portas devem encaminhar ou bloquear.

Mesmo quando você migra para variantes mais novas (como RSTP ou MSTP), a razão pela qual upgrades são possíveis é a mesma: o comportamento é padronizado o suficiente para que os dispositivos coordenem em vez de adivinharem.

BPDUs: as “mensagens de olá” do STP

Switches coordenam usando pequenos quadros de controle chamados BPDUs (Bridge Protocol Data Units). Pense nas BPDUs como as “mensagens de olá” do STP: elas carregam as informações necessárias para que switches construam uma visão compartilhada da topologia — quem eles acreditam ser o root, o quão distante ele está (custo) e informações de temporização.

Como as BPDUs são trocadas continuamente, o STP pode reagir quando algo muda. Se um link falha, a conversa das BPDUs muda também, e switches podem reconvergir e abrir um caminho previamente bloqueado.

Mesmas ideias, rótulos diferentes

Um detalhe prático: fornecedores frequentemente usam nomes diferentes para os mesmos controles. Uma configuração como “port cost”, “edge/PortFast” ou “bpdu guard” pode aparecer em menus distintos ou com termos diferentes. Os conceitos subjacentes do STP são consistentes, mas o vocabulário da interface nem sempre é — então ajuda traduzir recursos para o que o 802.1D busca realizar.

Do STP ao RSTP e MSTP: o que melhorou

O STP clássico (IEEE 802.1D) resolveu loops, mas podia ser dolorosamente lento para “curar” após uma falha de link ou switch. A razão é simples: o STP era cauteloso. Portas não começavam a encaminhar imediatamente — elas caminhavam por estados temporizados (blocking → listening → learning → forwarding). Com temporizadores padrão, a reconvergência podia levar dezenas de segundos (frequentemente ~30–50 segundos), tempo suficiente para chamadas de voz caírem, aplicações expirarem ou usuários assumirem que “a rede está fora”.

RSTP: mesma ideia, recuperação mais rápida

O Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) mantém o mesmo objetivo — encaminhamento sem loops com redundância — mas muda como switches alcançam acordo.

Em vez de esperar longos temporizadores fixos, o RSTP usa um handshake mais rápido entre switches para confirmar quais portas podem encaminhar com segurança.

• Portas de borda (normalmente portas de dispositivos finais) podem transicionar para encaminhamento rapidamente porque não se espera que criem loops.
• Transições rápidas acontecem quando switches podem verificar um caminho seguro sem a abordagem antiga de “esperar para ver”.

Em termos simples: o RSTP ainda bloqueia os links certos para prevenir loops; só que para de tratar toda mudança como um evento do pior caso.

MSTP: escalando spanning tree para redes maiores

À medida que redes cresceram, rodar uma única árvore para tudo tornou‑se limitante — especialmente com muitas VLANs e topologias complexas. O Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) permite criar múltiplas instâncias de spanning tree, mapeando grupos de VLANs para cada instância.

Isso significa que você pode:

• distribuir o tráfego de forma mais inteligente através de links redundantes (sem criar loops)
• reduzir a sobrecarga de gerenciamento comparado a rodar uma árvore por VLAN

A melhoria principal ao longo de STP → RSTP → MSTP é consistente: manter redundância, prevenir loops e restaurar encaminhamento mais rápido e de forma previsível.

Como o Spanning Tree suporta resiliência em larga escala

O benefício mais subestimado do Spanning Tree é como ele transforma “cabos e switches extras” em confiabilidade previsível. Em escala empresarial — muitos armários, muitos switches de acesso, mudanças constantes — a redundância de Camada 2 pode ser um presente ou uma armadilha. O STP aumenta a probabilidade de ser o primeiro.

A confiabilidade que você sente no dia a dia

Grandes redes raramente falham porque um link foi cortado; falham porque a recuperação é confusa. O STP ajuda fornecendo uma maneira controlada para a rede reagir quando algo muda:

• Falhas de link: quando uma fibra é desconectada ou um switch morre, o STP pode desbloquear um caminho alternativo para que usuários continuem trabalhando.
• Janelas de manutenção: equipes podem derrubar uplinks ou substituir equipamentos com menos risco de criar loops acidentalmente durante cabeamento “temporário”.
• Mudança constante: novos switches, cabos remendados e padrões de fornecedor aparecem o tempo todo. O STP fornece um comportamento base que geralmente é mais seguro do que “encaminhar tudo para todo lado”.

Uma “rede de segurança padrão” em muitas empresas

Muitas organizações mantêm o STP habilitado mesmo se acham que sua topologia está livre de loops. A razão é pragmática: pessoas cometem erros, a documentação se perde e caminhos inesperados de Camada 2 aparecem. Com o STP ativo, um cabo de remendo acidental tende a causar uma porta bloqueada em vez de uma queda em todo o prédio.

Por que alguns data centers usam designs diferentes

Data centers modernos frequentemente preferem arquiteturas routed leaf–spine (Camada 3) ou tecnologias de multipath em Camada 2 para obter largura de banda ativa/ativa sem depender da convergência clássica do STP. Ainda assim, o STP (ou variantes como RSTP/MSTP) é amplamente usado em redes de campus, segmentos de borda e como camada de compatibilidade onde puro Layer 3 não é prático.

Em escala, a conquista real do STP é tanto operacional quanto técnica: ele torna a redundância administrável por equipes comuns, não apenas por especialistas.

Mal-entendidos comuns que causam quedas reais

O STP é simples no conceito — prevenir loops de Camada 2 enquanto mantém caminhos de backup — mas alguns mitos persistentes fazem pessoas desativarem, configurarem mal ou “otimizarem” o STP até causar um incidente.

“STP está obsoleto agora”

É verdade que redes modernas muitas vezes dependem de roteamento Layer 3, MLAG e designs overlay que reduzem a necessidade do STP clássico IEEE 802.1D. Mas o STP (ou suas formas mais novas como RSTP/MSTP) ainda adiciona uma rede de segurança em qualquer lugar onde o Ethernet possa formar acidentalmente um loop: switches de acesso, redes de evento temporárias, laboratórios, filiais pequenas e qualquer cenário onde alguém possa ligar duas portas por engano.

Desabilitar o STP pode transformar um erro de cabeamento inofensivo em uma tempestade de broadcast que derruba uma VLAN inteira.

“Portas bloqueadas são largura de banda desperdiçada”

Uma porta bloqueada não está “morta”. É um caminho de reserva pré‑validado. O STP troca um pouco de capacidade ativa por estabilidade: se o link de encaminhamento falha, o link bloqueado pode se tornar o novo caminho sem um humano correndo para reencabear.

Equipes às vezes tentam forçar todos os links a encaminhar desativando o STP, achatando VLANs ou adicionando switches não gerenciados. Isso pode parecer eficiente — até o primeiro loop derreter a rede.

“Mais redundância é sempre melhor”

Redundância só ajuda quando é projetada. Adicionar cross‑links extras entre switches sem planejamento aumenta o número de cenários de loop possíveis e torna o comportamento do STP mais difícil de prever. O resultado pode ser caminhos inesperados, uplinks bloqueados ou reconvergência mais longa após uma falha.

Erros de configuração também causam quedas

Mesmo com STP habilitado, configurações ruins podem causar danos reais:

• Prioridade de bridge incorreta pode mover o root para um armário de acesso, forçando tráfego por um ponto fraco.
• Misturar modos STP (ou mapeamentos MSTP inconsistentes) no mesmo domínio de Camada 2 pode gerar comportamento instável.
• Usar edge/PortFast em links switch‑to‑switch pode permitir que loops se formem antes que o STP reaja.

A lição: STP não é apenas um checkbox — é um plano de controle. Trate‑o como tal, documente intenções e valide mudanças antes de aplicá‑las amplamente.

Dicas práticas: solução de problemas e operações seguras

Problemas com Spanning Tree frequentemente aparecem como “a rede está lenta” antes que alguém perceba que há um problema de Camada 2. Algumas checagens focadas podem poupar horas de investigação.

Sintomas práticos a reconhecer

Quando um loop Ethernet ou instabilidade do STP aparece, você verá comumente:

• MACs flutuando (flapping): o mesmo MAC “muda” entre portas de switch repetidamente na tabela MAC.
• Picos súbitos de broadcast: ARP, DHCP e outros broadcasts disparam, às vezes saturando links.
• Conectividade intermitente: usuários relatam quedas breves, chamadas VoIP falhando ou impressoras sumindo e reaparecendo.
• Alta CPU nos switches: recursos de controle ficam sobrecarregados por mudanças constantes de topologia.

Verificações básicas que geralmente apontam a causa

Comece pelos fundamentos:

1. Confirme a escolha do root bridge: verifique se o switch pretendido é o root (e não um switch de acesso que reiniciou).
2. Cheque papéis e estados de portas: procure bloqueios/discards inesperados em uplinks críticos ou transições frequentes (forwarding ↔ blocking) que indiquem instabilidade.
3. Observe contadores de mudança de topologia: mudanças repetidas frequentemente se correlacionam com um cabo solto, uplink mal conectado ou um switch não gerenciado criando um loop.

Hábitos operacionais seguros

Boa higiene STP é, em grande parte, processo:

• Documente cada mudança (o que foi movido, onde e quando). Loops muitas vezes surgem de patch cords “temporários” que viram permanentes.
• Teste failover deliberadamente durante janelas de manutenção para saber o que bloqueia/encaminha quando um link cai.
• Evite loops acidentais: cautela com switches não gerenciados, portas de parede que podem ser interligadas e mudanças de cabeamento de última hora.

Se quiser uma lista de verificação mais ampla para isolar problemas de rede além do STP, veja /blog/network-troubleshooting-basics.

Onde o Koder.ai pode ajudar (sem substituir sua stack de rede)

O STP é um ótimo exemplo de “infraestrutura silenciosa” e tende a falhar de formas muito humanas: intenção pouco clara, cabeamento não documentado, configurações inconsistentes e tentativas ad‑hoc de solução. Uma maneira prática de reduzir esse risco é construir ferramentas internas leves e runbooks em torno das operações STP.

Com Koder.ai, equipes podem gerar rapidamente pequenos dashboards web ou utilitários a partir de um chat — por exemplo, uma ferramenta que ingere saídas de switches, destaca a root bridge atual, sinaliza portas bloqueadas inesperadas ou monitora eventos de mudança de topologia ao longo do tempo. Como o Koder.ai suporta exportação de código‑fonte e deploy/hosting (com rollback e snapshots), também é um jeito conveniente de transformar “conhecimento tribal” em um serviço interno mantido, em vez de um script perdido no laptop de alguém.

O que podemos aprender com o projeto de Radia Perlman

O trabalho de Radia Perlman com spanning tree lembra que algumas das infraestruturas mais importantes não são chamativas — elas simplesmente previnem o caos. Ao dar ao Ethernet uma forma prática de usar links redundantes sem criar loops, o STP tornou “adicionar um caminho de backup” uma opção segura em vez de um experimento arriscado. Essa mudança permitiu redes de Camada 2 maiores e mais resilientes em empresas, campi e data centers.

1) Projete para falha, não para perfeição

O STP assume que algo vai dar errado: um cabo é ligado no lugar errado, um switch reinicia, um link fica instável. Em vez de esperar que operadores nunca errem, ele constrói um sistema que absorve erros e ainda converge para um estado seguro. A lição vai além da rede: trate modos de falha como requisitos de primeira classe.

2) Automatize segurança — mesmo que custe um pouco de eficiência

O Spanning Tree bloqueia intencionalmente alguns links para que a rede permaneça estável. Essa “capacidade desperdiçada” é uma troca em favor de comportamento previsível. Bons sistemas frequentemente reservam folga — tempo extra, verificações adicionais, guardrails — porque evitar falhas catastróficas vale mais do que extrair o último por cento de utilização.

3) Prefira regras simples e compartilhadas em vez de coordenação manual

O STP funciona porque todo switch segue as mesmas regras distribuídas e troca pequenas mensagens de controle para concordar sobre uma topologia sem ciclos. Você não precisa de um operador decidindo manualmente quais portas fechar a cada mudança. A moral: quando muitos componentes devem cooperar, invista em protocolos e padrões que tornem o comportamento seguro o mais fácil de obter.

Conclusões práticas

Se lembrar de apenas alguns pontos, lembre‑se destes: construa redundância, assuma erro humano e automatize a escolha segura. Essa mentalidade — mais do que qualquer recurso isolado — explica por que o spanning tree virou um essencial silencioso.

Se quiser mais fundamentos acessíveis de redes, navegue por /blog.