Spanning Tree (STP): como o protocolo evita loops de camada 2 e o que monitorar na rede

Autor: Pedro Tebaldi PM do KeepGreen

Publicado set/2026

A rede inteira trava sem aviso. O core responde ao ping com centenas de milissegundos, a CPU do switch encosta no teto e o service desk lota de chamados. Ninguém mexeu em nada, garante o time.

Quase sempre alguém mexeu. Um cabo voltou para a mesma parede, um switch não gerenciado apareceu embaixo de uma mesa ou o enlace foi parar na porta errada. Basta isso, porém, para o mesmo quadro de broadcast começar a circular sem fim entre dois caminhos.

O Spanning Tree Protocol existe para impedir esse cenário. Ele mantém a redundância física de pé, mas bloqueia logicamente todo caminho que fecha um circuito. Este artigo mostra como o protocolo monta essa árvore, quanto custa cada reconvergência e o que monitorar para ver o problema chegando.

Por que um loop de camada 2 derruba a rede em segundos

O quadro Ethernet não carrega campo de tempo de vida. Toda a mecânica do loop começa nessa ausência. No IP, por exemplo, o pacote que entra em uma rota circular perde um ponto de TTL a cada salto até morrer pelo caminho.

Na camada 2 do modelo OSI, porém, não existe contador equivalente. O switch encaminha, o vizinho devolve e o mesmo quadro roda até alguém desconectar o cabo.

Três efeitos aparecem juntos, sempre na mesma ordem. O broadcast se multiplica a cada volta, porque cada switch replica o quadro em todas as portas menos a de origem. A tabela MAC, ao mesmo tempo, começa a oscilar, já que o mesmo endereço aparece ora em uma porta, ora em outra. Por fim, a CPU satura processando quadro repetido.

Para o usuário, porém, o sintoma é lentidão, não queda limpa: o DNS demora, a sessão do ERP cai e a impressora some da lista. Esse quadro se confunde, inclusive, com perda de pacotes por saturação de link, que tem causa e tratamento diferentes.

No monitoramento a assinatura é outra. A taxa de entrada da interface sobe muito acima da linha de base enquanto o tamanho médio do pacote encolhe. O contador de broadcast, além disso, dispara em portas que costumam ficar quietas. No log do switch aparece MAC flapping entre duas portas.

O que é o Spanning Tree Protocol

O Spanning Tree Protocol (STP) é o protocolo de camada 2 do padrão IEEE 802.1D que impede loops em redes Ethernet com caminhos redundantes. Ele elege um switch como raiz da topologia e calcula o melhor caminho de cada switch até ela. As portas que sobram entram em bloqueio lógico, sem que ninguém desligue o enlace físico.

A distinção entre bloqueio lógico e desconexão física é o que sustenta o protocolo inteiro. A porta bloqueada continua recebendo BPDU, ou seja, continua ouvindo a rede. Quando o caminho ativo cai, é ela que assume o tráfego, sem que ninguém precise plugar nada.

Radia Perlman publicou o algoritmo em 1985 e a lógica central, ainda hoje, continua a mesma. O que envelheceu foi a expectativa de tempo: o padrão original assumia que recuperar a conectividade em cerca de um minuto era aceitável. Hoje, porém, nenhuma operação sustenta essa premissa.

Como o STP decide qual caminho fica de pé

Todo switch da rede envia BPDU pelas portas, em intervalos curtos. Esses quadros carregam a identidade do emissor e o custo dele até a raiz. A partir dessa troca, cada switch chega sozinho à mesma conclusão sobre a topologia, sem controlador central e sem configuração manual.

A eleição da bridge raiz

A raiz é o switch com o menor bridge ID. Esse identificador soma a prioridade configurável, cujo padrão é 32768, ao endereço MAC do equipamento. Quando ninguém mexe na prioridade, o desempate cai no MAC, ou seja, no equipamento mais antigo da rede.

Daí que a raiz costuma ser eleita por acidente. Um switch de acesso comprado há uma década, esquecido no rack de um andar, tende a carregar o MAC mais baixo do domínio. Todo o tráfego entre o core e os demais switches passa a calcular o caminho em direção a ele.

Custo de caminho e papel de porta

Definida a raiz, cada switch calcula o custo de todos os caminhos possíveis até ela. O custo vem da largura de banda do enlace: quanto mais rápido o link, menor o número. A porta de menor custo, chamada root port, é a que fica encaminhando.

Nos demais segmentos, o protocolo elege uma designated port por enlace, que também encaminha. Toda porta que sobra entra em bloqueio. É justamente ela que segura a redundância: não passa tráfego de dados, contudo continua escutando BPDU para reagir a qualquer mudança.

O desenho pesa muito nessa conta. Uma topologia em anel ou em malha gera bem mais portas bloqueadas do que uma árvore hierárquica. Cada uma delas, portanto, é capacidade paga esperando falha.

Estados de porta e o custo real da convergência

No STP clássico, a porta atravessa quatro estados antes de encaminhar tráfego: blocking, listening, learning e forwarding. Cada transição espera um timer. Os valores padrão são conservadores por projeto: hello de 2 segundos, forward delay de 15 e max age de 20.

A conta fecha mal para quem opera. A documentação técnica da Cisco sobre o padrão 802.1w registra o dobro do forward delay como espera obrigatória, isto é, 30 segundos de interrupção.

Trinta segundos de silêncio derrubam sessão TCP, estouram timeout de aplicação e cortam chamada de voz. O RSTP resolveu isso trocando o modelo de temporizador por um acordo direto entre vizinhos. Na mesma documentação, a Cisco descreve convergência na ordem de centenas de milissegundos.

Foi assim que o RSTP virou o padrão de fato. Ele reduziu os cinco estados a três: discarding, learning e forwarding. Também nomeou os papéis de reserva que o STP tratava como porta bloqueada genérica. O original passou a ser questão de compatibilidade, nunca escolha de projeto.

STP, RSTP e MSTP: qual usar e o que muda

A pergunta prática não é qual protocolo é melhor. É quantas instâncias de árvore a rede precisa manter e quanto de CPU o switch pode gastar com elas.

Redes com muitas VLANs segmentadas por área mudam a resposta, porque cada instância adicional consome processamento em todos os switches do domínio.

Na prática, quase toda rede corporativa em operação roda RSTP ou uma variante proprietária compatível. O MSTP entra quando VLANs diferentes precisam de caminhos físicos diferentes, o que aproveita enlaces parados sob uma árvore única.

No data center moderno o desenho mudou de vez. Arquiteturas de fabric levam o roteamento de camada 3 até o switch de acesso. Todos os enlaces passam a carregar tráfego simultaneamente, sem porta bloqueada. O protocolo continua na borda, protegendo contra o cabo ligado no lugar errado.

Cinco erros de projeto que transformam o STP em causa de incidente

O protocolo raramente falha sozinho. Ele age exatamente como foi configurado, então o problema costuma aparecer quando ninguém configurou nada. Os cinco erros abaixo se repetem em rede corporativa que cresceu por adição, sem revisão de desenho.

1. Deixar a eleição da raiz por conta do acaso

Sem prioridade definida, a raiz vai para o menor MAC, quase sempre o equipamento mais velho do rack. O resultado, portanto, é tráfego atravessando um switch de acesso para chegar ao core. Fixe a prioridade do core e do equipamento de contingência antes de qualquer outro ajuste.

O comando abaixo diz quem está no controle da árvore hoje.

Switch# show spanning-tree vlan 10
VLAN0010
  Spanning tree enabled protocol rstp
  Root ID    Priority    32778
             Address     001a.2b3c.4d5e
             Cost        19
             Port        24 (GigabitEthernet0/24)
  Bridge ID  Priority    32778  (priority 32768 sys-id-ext 10)
             Address     002c.3d4e.5f6a
# Root ID diferente do Bridge ID: este switch não é a raiz

Quando o Root ID e o Bridge ID mostram endereços diferentes, o switch consultado não é a raiz. Compare em seguida o endereço da raiz com o inventário: se ele não bate com o core, a árvore está apoiada no lugar errado.

2. Porta de acesso sem PortFast e sem BPDU Guard

Toda porta de usuário que percorre o ciclo completo leva dezenas de segundos para liberar tráfego. O PortFast existe justamente para pular essa espera. Sem o BPDU Guard junto, porém, a mesma porta aceita BPDU de um switch doméstico. A topologia inteira recalcula por causa de um equipamento de mesa.

3. Tratar a mudança de topologia como ruído

Cada evento de topology change reduz o tempo de vida da tabela MAC e obriga os switches a reaprender endereços. Uma porta de acesso instável, que sobe e desce, gera essa rajada dezenas de vezes por hora.

O sintoma chega como lentidão intermitente sem causa aparente, quase nunca como alarme. Como o contador raramente entra no painel, o defeito sobrevive semanas. Um monitoramento de switches que colete esse valor por VLAN entrega a porta culpada em minutos.

4. Misturar variantes entre fabricantes no mesmo domínio

PVST+, RSTP e MSTP interoperam, contudo o resultado depende de região, revisão de configuração e VLAN nativa. Dois switches de fabricantes diferentes com região MSTP divergente formam duas árvores que não se enxergam. Padronize a variante antes de encostar equipamento novo na distribuição.

5. Esperar que o STP resolva enlace unidirecional

Quando uma fibra transmite e não recebe, o switch do outro lado para de ouvir BPDU e libera a porta bloqueada. O loop nasce justamente porque o protocolo acredita que o caminho sumiu. Esse caso exige proteção específica, como loop guard no lado bloqueado.

O que monitorar para ver o loop antes do usuário ligar

Nenhum sintoma de loop aparece como alarme de disponibilidade. O host responde, a interface segue up e o SLA de ping continua verde enquanto a rede afunda. Por isso a instrumentação precisa olhar para contadores, não para estado.

O tamanho do problema justifica o esforço. Segundo o levantamento anual do Uptime Institute, falhas de TI e de rede responderam por 23% das indisponibilidades relevantes registradas em 2024.

Quatro coletas resolvem a maior parte dos casos, todas por consulta SNMP nos próprios switches. São a taxa de broadcast e multicast por interface, o contador de topology change por VLAN e o papel de cada porta. O quarto sinal é o alerta de MAC flapping vindo do syslog.

O limiar que funciona é relativo, nunca absoluto. Compare a taxa de broadcast de cada porta com a linha de base dos últimos sete dias. Um ponto de partida defensável é alertar quando o valor romper cinco vezes essa base e permanecer assim por mais de um minuto.

A análise de tráfego por fluxo completa o quadro, porque mostra qual host originou a rajada. O contador de interface sozinho não entrega esse recorte. Em rede multi-site, é ele que separa incidente local de problema de backbone.

Vale destacar um cuidado no roteamento do alerta. O aviso de broadcast precisa chegar ao time de rede, nunca ao plantão genérico, porque o diagnóstico exige olhar topologia. Em fila indistinta, ele vira mais um chamado de lentidão sem dono.

Na operação do Marista Brasil, o problema de rede chegava pelo usuário ou pela operadora antes de chegar à TI. São 97 escolas monitoradas, do Rio Grande do Sul à Amazônia. Montamos um dashboard por unidade escolar, com cerca de 6.000 hosts e 12.000 serviços sob coleta.

Cada TI local ganhou autonomia sem que a visão central se perdesse. O NOC ativo 7×24 passou a tratar o incidente antes do expediente da equipe do cliente. O case completo do Marista Brasil detalha o desenho por unidade.

No OpCast #08, Gilsinei Santos e Marcos Pain, da TI do Marista Brasil, contam como unificaram a operação de três províncias.

Para o loop que já está acontecendo, a metodologia de troubleshooting publicada pela Cisco parte das taxas de entrada das interfaces. É assim que ela separa a origem das vítimas.

Esse é o caminho manual, em hora de crise. A instrumentação acima existe justamente para você não precisar dele.

Onde a decisão realmente acontece

O STP não é uma caixa que se liga e se esquece. Ele é uma decisão de desenho que a rede executa todo dia. Boa parte dos incidentes de camada 2 nasce de uma escolha que ninguém fez de propósito.

Três coisas cabem na próxima janela de manutenção. A primeira é fixar a prioridade da raiz no core e no equipamento de contingência, tirando a eleição do acaso. A segunda é padronizar a variante do protocolo em todo o domínio, com PortFast e BPDU Guard nas portas de acesso. A terceira é levar o contador de topology change e a taxa de broadcast para o painel.

Nenhuma das três depende de comprar equipamento. Todas dependem de comparar o desenho documentado com o que a rede faz quando um enlace cai. Se a sua operação nunca mediu esse tempo de reconvergência, esse é o número que falta.

Fale com um especialista da OpServices para mapear a camada 2 do seu ambiente e definir o que precisa entrar no monitoramento.