13 de dez. de 2025·8 min
Spanning Tree de Radia Perlman: a Espinha Dorsal Silenciosa do Ethernet
Conheça Radia Perlman e entenda como o Spanning Tree Protocol evita loops Ethernet, permite redundância e tornou redes grandes estáveis e confiáveis.
Conheça Radia Perlman e entenda como o Spanning Tree Protocol evita loops Ethernet, permite redundância e tornou redes grandes estáveis e confiáveis.
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.
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.
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.
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.
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.
Quando redes se expandem assim, links extras são adicionados por razões práticas:
Individualmente, cada mudança pode parecer inofensiva. Coletivamente, elas podem criar múltiplos caminhos entre os mesmos switches.
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.
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.
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.
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 reaprendido de novo.
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.
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.
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:
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.
Feito corretamente, o STP entrega dois resultados que normalmente conflitam:
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.
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.
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.
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.
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.
Vamos tornar o STP concreto com uma pequena rede de quatro switches:
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.
Cada switch não‑root escolhe exatamente uma porta como sua root port: a porta que fornece o melhor caminho de volta a S1.
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.
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.
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.
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.
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.
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.
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”.
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.
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.
À 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:
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.
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.
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:
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.
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.
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.
É 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.
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.
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.
Mesmo com STP habilitado, configurações ruins podem causar danos reais:
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.
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.
Quando um loop Ethernet ou instabilidade do STP aparece, você verá comumente:
Comece pelos fundamentos:
Boa higiene STP é, em grande parte, processo:
Se quiser uma lista de verificação mais ampla para isolar problemas de rede além do STP, veja /blog/network-troubleshooting-basics.
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 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.
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.
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.
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.
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.
Um loop de Camada 2 ocorre quando switches têm dois ou mais caminhos ativos entre os mesmos segmentos, formando um ciclo. Como quadros Ethernet não têm limite de saltos na Camada 2, tráfego inundado (broadcasts e unicasts desconhecidos) pode circular indefinidamente e se multiplicar, sobrecarregando links e CPUs dos switches.
A redundância adiciona caminhos alternativos, mas sem coordenação os switches podem encaminhar por todos eles. Isso cria um loop onde quadros inundados são replicados repetidamente, levando a tempestades de broadcast e aprendizado MAC instável — frequentemente resultando em uma queda de rede generalizada causada por um único cabo extra.
O STP mantém os links redundantes fisicamente presentes, mas desabilita logicamente algumas portas para que a topologia ativa seja uma árvore sem ciclos. Se um caminho ativo falha, o STP pode transicionar uma porta previamente bloqueada para encaminhamento e restaurar a conectividade.
O STP elege uma root bridge como ponto de referência para todo o domínio de Camada 2. O switch com o menor bridge ID (prioridade + identificador único) torna‑se o root; escolher o switch de core/distribution desejado como root ajuda a manter os caminhos de tráfego previsíveis.
Cada switch não‑root seleciona uma root port: a porta com o menor path cost total até o root. O custo de caminho baseia‑se na velocidade do link (links mais rápidos normalmente têm custo menor). Critérios de empate usam IDs para decidir de forma determinística.
Em cada segmento entre switches, o STP escolhe uma designated port para encaminhar naquele segmento (o lado que anuncia o melhor caminho ao root). Qualquer porta que não seja root port nem designated port fica bloqueada/descartando, e é assim que o STP corta loops.
Significa que a porta não encaminha tráfego de usuário normal, impedindo que participe de um loop. O link continua ativo e pode transportar tráfego de controle STP; se a topologia mudar (por exemplo, uma falha), essa porta bloqueada pode ser promovida para encaminhar.
BPDUs (Bridge Protocol Data Units) são quadros de controle do STP que os switches trocam para compartilhar informações de topologia: quem eles acham que é o root, o custo até ele e detalhes de temporização. Ao trocar BPDUs continuamente, os switches detectam falhas/alterações e reconvergem para uma topologia segura sem ciclos.
O STP clássico (IEEE 802.1D) pode levar dezenas de segundos para reconvergir porque usa temporizadores conservadores e estados de porta. O RSTP (802.1w) acelera isso com handshakes mais rápidos e transições imediatas para portas de borda/PortFast, reduzindo o tempo de inatividade após falhas.
Uma lista prática:
Para diagnósticos mais amplos além do STP, veja /blog/network-troubleshooting-basics.