Início / Notas técnicas / Solução de problemas de tempestade de loop de Camada 2

Tempestade de loop de Camada 2: encontrando o loop quando toda a rede cai

Tempestade de broadcast, endereços MAC oscilando entre portas, metade da rede inacessível — é assim que um loop de Camada 2 se parece por dentro. Aqui está como confirmar que é realmente um loop, encontrá-lo rápido, quebrá-lo sem piorar as coisas, e impedir que volte, com os comandos de diagnóstico reais e os casos de configuração incorreta do próprio manual de manutenção dos switches Huawei.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

A assinatura de um loop de Camada 2

Links e equipamentos redundantes deveriam tornar uma rede mais confiável — até que uma mudança na rede forma um loop de verdade, e essa mesma redundância vira uma tempestade de broadcast.

As redes de comutação Ethernet implantam equipamentos e links redundantes deliberadamente, por confiabilidade. Mas ajustes de rede, mudanças de configuração e atualizações de versão criam rotineiramente, por acidente, quadros de dados ou de protocolo que circulam em anel — e no momento em que um protocolo de quebra de loop não está rodando, ou uma mudança de configuração silenciosamente abre um buraco em um que está, essa redundância vira uma tempestade de broadcast em vez de uma rede de segurança. Um único quadro de broadcast preso em um loop é reencaminhado para todas as outras portas de cada switch no anel, repetidamente, até saturar cada link perto da velocidade de linha — e o tráfego normal simplesmente para de ter sua vez.

Esta nota cobre como determinar que isso é realmente o que está acontecendo (em vez de outro tipo de interrupção), como localizar o loop rápido, como quebrá-lo sem piorar a interrupção, e os casos específicos de configuração incorreta — VLAN 1 deixada em uma porta, portas edge de STP nunca configuradas, regiões MSTP que não coincidem, nós RRPP rodando modos diferentes — que respondem por uma grande parte dos loops que nunca deveriam ter existido.

Como um loop se parece, e como confirmá-lo

Os sintomas de um loop e o fluxo de confirmação de quatro métodos, lado a lado.

Os quatro métodos de confirmação abaixo não têm ordem fixa — use um ou vários juntos, o que a situação permitir primeiro.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Quatro formas de confirmar que é realmente um loop

Todos os quatro dependem de comandos já disponíveis em cada switch — nenhuma ferramenta especial necessária.

1. Tráfego de interface — a primeira verificação mais rápida

Execute display interface brief e compare duas leituras com um curto intervalo: em uma porta carregando um loop, InUti e OutUti sobem constantemente em direção ao teto de taxa da porta. Se apenas uma porta de um dispositivo mostra tráfego pesado em ambas as direções, suspeite de um autoloop de porta única; se duas portas de um dispositivo estão ambas pesadas, suspeite de um loop de duas portas causando oscilação de protocolo; se apenas uma direção é pesada em uma única porta, o loop está mais provavelmente a jusante dessa porta do que nela.

<HUAWEI> display interface brief | include up
Interface             PHY Protocol InUti OutUti inErrors outErrors
GigabitEthernet0/0/16   up   up      76%   76%     0     0
GigabitEthernet1/0/12   up   up      76%   76%     0     0
// both interfaces climbing toward rate ceiling between two readings -- consistent with a loop

<HUAWEI> display interface XGigabitEthernet2/0/1
  Broadcast:      184920331, Multicast:    20524
// broadcast/multicast counters far above this device's other interfaces point at the same conclusion

2. Oscilação de endereço MAC — a assinatura de confirmação

A oscilação de MAC acontece quando uma interface aprende um endereço MAC que outra interface na mesma VLAN também aprende — o aprendizado posterior sobrescreve a entrada anterior. Um loop sempre produz oscilação de MAC; a oscilação de MAC nem sempre significa um loop (também pode significar um ataque não autorizado), mas ver o mesmo endereço MAC saltando entre duas portas específicas é a confirmação direta mais disponível.

[HUAWEI] vlan 10
[HUAWEI-vlan10] loop-detect eth-loop alarm-only
<HUAWEI> display trapbuffer
L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 Loop exists in vlan 1001, for
flapping mac-address 0025-9e6e-1c55 between port GE2/1/23 and port GE2/1/22.
// the same MAC bouncing between two named ports in the same VLAN -- direct evidence of a loop

3. Implantar detecção de loop — quando você precisa de prova definitiva

Loop Detection (switches em chassi) e Loopback Detection (todos os formatos de switch) enviam periodicamente um quadro de detecção especial para fora de uma interface e verificam se o próprio dispositivo o recebe de volta — seja na mesma interface (autoloop) ou em outra (loop de rede). Essa é a forma mais direta de provar que um loop existe, ao custo de recursos extras do sistema, razão pela qual o manual recomenda explicitamente desativá-la novamente assim que a verificação for concluída, e nunca ativá-la em uma porta de uplink.

[HUAWEI] loopback-detect enable
<HUAWEI> display loopback-detect
Loopback-detect is enabled in the system view
Interface              ProtocolID RecoverTime Action Status
GigabitEthernet0/0/2        602          30          block     NORMAL
// "Status" flips away from NORMAL the moment this device receives its own detection frame back
[HUAWEI] undo loopback-detect enable
// disable again once the check is complete -- this is a diagnostic tool, not a permanent setting

4. Uso de CPU — o sinal corroborante

Uma participação alta e sustentada da tarefa PPI (Product Process Interface) em display cpu-usage — não um pico breve — sugere fortemente que um loop está inundando a CPU com pacotes que ela precisa processar. Se o PPI em si parecer normal, verifique display cpu-defend statistics em busca de pacotes de protocolo descartados por limitação de taxa; um descarte pesado ali aponta na mesma direção.

<HUAWEI> display cpu-usage
CPU Usage           : 91% Max: 96%
TaskName         CPU Runtime            Task Explanation
PPI              70%      0/512f8c      PPI Product Process Interface
// a sustained high PPI share, not a brief spike, is the pattern that suggests a loop

<HUAWEI> display cpu-defend vrrp statistics all
Packet Type   Pass(Bytes) Drop(Bytes)  Pass(Packets) Drop(Packets)
vrrp          79880066214 2581617736  1174644777    37950869
// heavy protocol packet drop under rate-limiting is consistent with a loop saturating the link

Estancar a sangria: quebra de loop de emergência

Uma vez confirmado o loop, a prioridade muda do diagnóstico para restabelecer o negócio — o mais rápido possível, sem introduzir um segundo problema.

Primeiro obtenha ou reconstrua a topologia completa — nomes de dispositivos, MAC do sistema, IP de gerenciamento, e nomes de portas local/remota e plano de VLAN para cada dispositivo no loop. Sem isso, você está adivinhando qual link quebrar.
Confirme quais links ou dispositivos permanecem acessíveis para gerenciamento remoto antes de tocar em qualquer coisa — quebrar o link errado pode te trancar para fora dos próprios dispositivos que você precisa continuar gerenciando.
Escolha o ponto de quebra menos disruptivo: remova a VLAN em loop de uma porta (Access: undo port default vlan; Trunk: undo port trunk allow-pass vlan id; Hybrid: undo port hybrid vlan id) se conseguir identificar uma com precisão — esta é a opção de menor impacto. Note que remover a VLAN padrão de uma porta Access pode afetar dispositivos a jusante naquela porta, então confirme primeiro o que realmente está por trás dela.
Se não conseguir isolar uma única VLAN, faça shutdown na porta física em loop — reversível com undo shutdown, e mais seguro do que desconectar uma fibra manualmente.
Só desconecte a fibra ou cabo físico se o dispositivo não puder mais ser acessado remotamente de forma alguma — este é o último recurso, não o primeiro movimento.
Confirme a recuperação com ping e observando o tráfego voltar a níveis normais — uma topologia de loop devidamente quebrada deve deixar o negócio retomar por conta própria assim que o caminho redundante deixar de formar loop.

[SwitchA-GigabitEthernet1/0/1] undo port trunk allow-pass vlan 1
// narrowest-impact break: remove only the looped VLAN from this one port

[SwitchA-GigabitEthernet1/0/1] shutdown
// broader but reversible -- undo shutdown restores the port once the loop is actually fixed

Cinco configurações incorretas que causam loops que nunca deveriam ter existido

1. Uma porta deixada na VLAN 1 por padrão forma loop contornando seu protocolo de quebra de loop

SINTOMAO negócio cai completamente em um switch de duplo uplink, um reinício o restaura brevemente, e a mesma interrupção exata retorna algum tempo depois.

CAUSAToda porta trunk carrega a VLAN 1 por padrão, a menos que seja explicitamente removida. Se duas portas que nunca deveriam compartilhar um domínio de broadcast ainda carregam a VLAN 1, essa VLAN forma loop mesmo enquanto a instância STP ou RRPP que realmente protege as outras VLANs funciona perfeitamente — porque a VLAN 1 nunca foi incluída no que esses protocolos protegem.

SOLUÇÃOVerifique uma VLAN 1 comum entre as portas que mostram tráfego anormal, e então remova a VLAN 1 das portas que não precisam dela (undo port trunk allow-pass vlan 1), ou incorpore explicitamente a VLAN 1 na instância protegida se ela realmente precisar circular pelo anel.

2. A ausência de bpdu enable significa que o STP nunca roda de verdade naquela porta

SINTOMAO STP está habilitado globalmente em ambos os switches, mas a rede ainda inunda com tráfego de broadcast como se nenhum protocolo de quebra de loop estivesse rodando.

CAUSANas versões de switch afetadas, uma porta precisa ter bpdu enable configurado antes de realmente repassar as BPDUs de STP recebidas para a CPU processar — sem isso, as BPDUs são simplesmente descartadas na porta, então nenhuma porta de bloqueio é calculada, mesmo que o STP pareça habilitado globalmente.

SOLUÇÃOExecute display stp interface em cada porta do anel — se toda porta mostra Designated Port e nenhuma mostra Alternate ou Root, a negociação STP nunca aconteceu de fato. Configure bpdu enable nas portas que precisam receber e processar quadros STP.

3. Uma configuração de porta edge STP ausente parece um problema de DHCP, não de loop

SINTOMACertos laptops falham em obter um endereço IP especificamente ao inicializar a partir de uma placa de rede (inicialização estilo PXE), enquanto outros dispositivos no mesmo switch não têm problema algum.

CAUSAUma NIC fazendo boot de rede oscila brevemente o link durante a inicialização. Se a porta do switch voltada para aquele terminal não estiver configurada como porta edge de STP, essa oscilação dispara um recálculo completo da topologia STP — cerca de 30 segundos durante os quais a porta não encaminha. O terminal envia apenas quatro tentativas de descoberta DHCP nessa janela, não recebe resposta a nenhuma delas, e simplesmente desiste.

SOLUÇÃOConfigure stp edged-port enable em cada porta que se conecta a um terminal final em vez de a outro switch. Versões de plataforma mais recentes podem autodetectar portas voltadas para terminais e configurar isso automaticamente, mas vale a pena confirmar em vez de presumir.

4. Dois switches na «mesma» região MSTP que na verdade não estão

SINTOMAMúltiplas instâncias STP são configuradas deliberadamente para que uma determinada porta possa encaminhar em uma instância de VLAN e bloquear em outra, mas toda instância converge identicamente à instância 0, não importa quais valores de custo por instância sejam definidos.

CAUSADois switches MSTP só compartilham uma região — e portanto podem rodar suas instâncias independentemente — quando o nome da região, o mapeamento instância-VLAN, o seletor de formato e o nível de revisão coincidem exatamente. Se apenas o nome da região diferir, os switches voltam a calcular cada instância da mesma forma que a instância 0, anulando silenciosamente todo o propósito de configurar instâncias separadas.

SOLUÇÃOCompare display stp region-configuration nos dois switches — o nome da região primeiro. Alinhe o nome da região, depois reconfirme que os valores de custo por instância realmente entram em vigor independentemente.

5. Nós RRPP rodando modos de protocolo diferentes nunca se comunicam de fato

SINTOMADepois que um link no anel RRPP falha e se recupera, as tabelas MAC e ARP nos nós de trânsito não atualizam, e o tráfego permanece quebrado mesmo com o anel físico saudável novamente.

CAUSAO RRPP tem dois modos de funcionamento — o modo proprietário Huawei padrão e o modo GB (padrão nacional) — e todo nó no mesmo anel precisa rodar o mesmo modo. Se o nó mestre está configurado no modo GB enquanto os nós de trânsito ficam no padrão, os pacotes de notificação common/complete do mestre simplesmente não são processados pelos nós de trânsito, então suas tabelas MAC e ARP nunca recebem o aviso de que a topologia mudou.

SOLUÇÃOVerifique display rrpp verbose domain no nó mestre para confirmar seu modo de funcionamento, depois verifique o mesmo em cada nó de trânsito — alinhe todos a um único modo, seja qual for, de forma consistente em todo o anel.

Um caso real: VLAN 1, dois uplinks, e um peer OSPF que continuava caindo

A interrupção parecia um problema de roteamento. A causa real foi uma VLAN que ninguém pensou em verificar.

A configuração: um switch com dois uplinks para roteadores, e dispositivos da camada de acesso pendurados a jusante. O sintoma: ambos os uplinks ficaram completamente escuros para o negócio, um reinício restaurou o serviço por um tempo, e então a mesma falha exata retornou.

O rastro de logs apontava primeiro para o OSPF, nem um pouco para a Camada 2 — a relação de vizinhança do uplink continuava caindo, aparentemente sem motivo:

NBR_CHG_DOWN(l): Neighbor event:neighbor state changed to Down. (ProcessId=88,
NeighborAddress=x.x.x.x, NeighborEvent=KillNbr, NeighborPreviousState=Loading,
NeighborCurrentState=Down)

NBR_DOWN_REASON(l): Neighbor state leaves full or changed to Down. (ProcessId=88,
NeighborRouterId=x.x.x.x, NeighborAreaId=0, NeighborInterface=Vlanif4, NeighborDownImmediate
reason=Neighbor Down Due to Kill Neighbor, NeighborDownPrimeReason=Physical Interface State Change)

Os logs de diagnóstico contaram a história real: as portas de uplink GE1/0/0 e GE1/0/1 mostravam ambas tráfego de saída anormal, enquanto as portas a jusante GE1/0/3 e GE1/0/4 mostravam ambas tráfego de entrada anormal ao mesmo tempo — as quatro bem no teto de taxa da porta:

Interface GigabitEthernet1/0/0's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=0Mbps,
CurrentOutSpeed=849Mbps, File=IFPDT_FUNC_C, Line=13072)
Interface GigabitEthernet1/0/3's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=847Mbps,
CurrentOutSpeed=846Mbps, File=IFPDT_FUNC_C, Line=13072)
Interface GigabitEthernet1/0/4's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=849Mbps,
CurrentOutSpeed=849Mbps, File=IFPDT_FUNC_C, Line=13072)

Comparar a configuração de cada porta sinalizada revelou exatamente uma coisa em comum: a VLAN 1. O tráfego entrando em GE1/0/3 e GE1/0/4 dentro da VLAN 1 estava sendo transmitido de volta diretamente para as outras portas sinalizadas, incluindo os dois uplinks — inundando-as até que os próprios pacotes hello do OSPF fossem descartados, o que realmente derrubou a relação de vizinhança. Remover GE1/0/3 e GE1/0/4 da VLAN 1 eliminou a falha imediatamente, sem necessidade de mais mudanças.

O ponto generalizável: um loop de VLAN 1 é comum o suficiente para valer a pena verificar primeiro, especificamente, sempre que o tráfego de várias portas sem relação aparente parece anormal — compare suas configurações em busca de uma VLAN compartilhada antes de presumir que a falha está em algo mais exótico.

Reforçando a rede para que isso não volte

Uma vez apagado o incêndio imediato, essas cinco verificações são o que realmente previne o próximo.

Confirme que um protocolo de quebra de loop está realmente implantado e realmente protegendo cada VLAN em uso — STP/RSTP/MSTP, RRPP, SEP ou ERPS, escolhido para combinar com o design da rede, não deixado ao que o padrão por acaso era.
Melhore a qualidade e confiabilidade do link onde um link marginal está causando descarte de pacotes de protocolo e abertura temporária de portas bloqueadas — substitua fibra, módulos ópticos ou cabeamento suspeitos, e adicione largura de banda ou agregação de links onde o próprio congestionamento está descartando quadros de protocolo.
Implante supressão de broadcast nas portas do anel como rede de segurança — cerca de 5% é um ponto de partida razoável segundo a própria orientação do manual, ajustado ao tráfego de broadcast concorrente real da rede.
Implante QoS para que pacotes de protocolo obtenham encaminhamento prioritário — um link congestionado que descarta quadros STP ou RRPP antes de quadros de dados é exatamente o que transforma um breve soluço em um recálculo completo de topologia.
Revise o próprio design da rede assim que ela crescer em complexidade — estratifique deliberadamente acesso e agregação, e divida um único domínio plano grande em zonas separadas lógica ou geograficamente assim que a contagem de dispositivos nele ficar grande.

Limites honestos desta nota

Esta nota se baseia no Capítulo 6 do próprio manual de manutenção de switches Huawei — as etapas de diagnóstico, os casos de configuração incorreta e as recomendações de reforço são todos originários dessa referência. Não cobre em profundidade o comportamento de sub-anéis ERPS, as especificidades do Smart Link, ou cenários de loop causados por equipamentos de terceiros que refletem quadros que não conseguem processar de outra forma — cada um mereceria um olhar separado.

FAQ

As perguntas que surgem sempre que um loop suspeito está realmente em discussão.

Como diferenciar um loop real de outra causa de tempestade de broadcast, como um dispositivo comprometido inundando tráfego?

A oscilação de endereço MAC é o indício: um loop verdadeiro sempre produz o mesmo endereço MAC saltando entre duas portas específicas na mesma VLAN, porque o switch continua reaprendendo-o de ambas as direções. Um único dispositivo com mau comportamento ou comprometido gerando tráfego pesado de broadcast tipicamente não produz essa assinatura particular de oscilação bilateral entre duas portas — aparece como tráfego alto sem o padrão de deriva de MAC correspondente.

Uma porcentagem alta de CPU PPI sozinha é suficiente para confirmar um loop?

Não sozinha. Uma participação de PPI alta e sustentada é um forte indicador, mas muitas outras condições também podem elevar o uso de CPU. Faça verificação cruzada com o tráfego de interface e a oscilação de MAC, ou implante detecção de loop para uma resposta direta, antes de tratar a CPU alta como prova por si só.

É mais seguro desligar uma porta ou desconectar fisicamente o cabo para quebrar um loop?

O shutdown é quase sempre a melhor escolha — é instantaneamente reversível com undo shutdown e não arrisca danificar um conector ou ponta de fibra. Desconectar fisicamente um cabo é um último recurso reservado para quando o próprio dispositivo não pode mais ser acessado remotamente para emitir o comando shutdown.

Remover a VLAN 1 (ou outra VLAN) de uma porta para quebrar um loop poderia afetar outros usuários?

Sim, potencialmente — remover a VLAN padrão de uma porta Access em particular pode afetar qualquer dispositivo ou usuário a jusante realmente conectado a ela, então confirme o que está por trás de uma porta antes de mexer. Remover um ID de VLAN específico de uma porta Trunk ou Hybrid geralmente tem impacto mais restrito, já que outras VLANs naquela mesma porta continuam encaminhando normalmente.

STP, RRPP e detecção de loop devem todos rodar na rede ao mesmo tempo?

Os protocolos de quebra de loop (STP/RSTP/MSTP, RRPP, SEP, ERPS) são a defesa real e devem ser escolhidos deliberadamente para combinar com o design da rede — rodar RRPP e MSTP juntos nas mesmas portas não é recomendado. Loop Detection e Loopback Detection são ferramentas de diagnóstico suplementares que consomem recursos extras do sistema; o manual recomenda especificamente desativá-las novamente assim que uma verificação de implantação for concluída, em vez de deixá-las rodando permanentemente em todo lugar.

Metade da rede caída e endereços MAC oscilando agora mesmo?

Envie-nos sua saída de display interface brief e um esboço aproximado da topologia — ajudamos você a encontrar o loop e quebrá-lo com segurança.

WhatsApp com um engenheiro →