O alarme hwNvo3VxlanTnlDown dispara, e um túnel que estava bem um minuto atrás desapareceu. Esta é a ordem que o restabelece com segurança — o que confirmar primeiro, o que reunir antes de mudar qualquer coisa, as duas causas raiz que respondem pela maioria desses alarmes, e como provar que a correção realmente funcionou antes de fechar o chamado.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O instinto quando um alarme dispara é corrigir a primeira coisa que parece errada. Em um alarme de túnel VXLAN, esse instinto causa mais interrupções do que evita.
hwNvo3VxlanTnlDown significa exatamente uma coisa: um túnel VXLAN que estava up caiu. Isso não diz o porquê, e reagir apenas ao texto do alarme — reiniciar um processo, dar bounce em uma interface, aplicar uma mudança de configuração — é como um alarme de um único túnel se transforma em uma interrupção mais ampla. Este manual segue uma ordem fixa: confirmar o que realmente aconteceu e até onde isso se estende, reunir as evidências que separam a causa raiz do ruído, trabalhar as duas causas que respondem pela maioria desses chamados, e verificar que aquele túnel específico se recuperou antes de dar como concluído.
A seguir está essa ordem com os comandos exatos, o comando que mais frequentemente encerra o incidente — um shutdown de interface direcionado — e por que precisa ser a interface certa, não qualquer uma que pareça instável.
Quatro etapas, um ponto de bifurcação — vale a pena ter esse esquema à vista antes de mexer em qualquer coisa.
O ponto de bifurcação é simples: a rota até o VTEP remoto desapareceu completamente, ou está presente mas instável? As duas respostas levam a duas correções completamente diferentes, e aplicar a errada desperdiça os minutos que mais importam durante uma interrupção ativa.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Tudo antes do ponto de bifurcação é confirmação e coleta de evidências, não remediação — resista à tentação de corrigir qualquer coisa até saber de que lado da bifurcação você está.
Quatro etapas: confirmar e delimitar o alcance, reunir evidências, aplicar a correção correspondente, verificar o túnel específico — não a rede em geral.
Antes de mexer em qualquer configuração, saiba o que realmente está quebrado e até onde isso se estende.
%%01NVO3/4/hwNvo3VxlanTnlDown_active: The VXLAN tunnel changed from Up to Down.
(SourceAddress=4.4.4.100, DestinationAddress=3.3.3.100, TunnelId=4026531844)
// the alarm names the affected device and the tunnel's Source/Destination -> log in to that device, not a neighbor
<HUAWEI> display device
// rule out main control board / interface board faults before assuming this is a routing problemDois comandos indicam com qual das duas causas raiz você está lidando — execute os dois antes de decidir uma correção.
<HUAWEI> display ip routing-table 3.3.3.100
<HUAWEI>
// no route to the peer VTEP -> the underlay route is genuinely gone, go to Stage 3a
<HUAWEI> display ospf peer brief
Peer Address Interface State
10.0.12.2 GE1/0/1 Full
// run this again a few seconds later, and again --
// a neighbor that comes and goes between runs is flapping, not just slow to reconvergeEsta é uma perda real de caminho até o peer, não um sintoma de instabilidade — trate isso como uma falha de roteamento/EVPN, não uma falha de túnel.
Esta é a correção que realmente resolve a maioria desses alarmes — um corte pequeno, deliberado e temporário, não um bounce de interface aleatório.
[~HUAWEI] interface 10ge 1/0/1 // example only -- use the interface you identified as flapping
[~HUAWEI-10GE1/0/1] shutdown
[*HUAWEI-10GE1/0/1] commitUm ping funcionando em outro lugar do fabric não confirma que este túnel se recuperou — verifique o túnel em si, pelo seu par Source/Destination.
<HUAWEI> display vxlan tunnel
Tunnel ID Source Destination State Type Uptime
4026531844 4.4.4.100 3.3.3.100 up dynamic 00:00:42
// confirm State is up for this exact Source/Destination pair before closing the incidentDepois que as quatro etapas acima indicarem onde está o incidente, esses cinco pontos explicam a maior parte do que ainda pega as pessoas de surpresa.
SINTOMAhwNvo3VxlanTnlDown parece um problema de VXLAN, então o instinto é ir primeiro olhar a configuração VXLAN ou NVE.
CAUSAO túnel é um passageiro, não a causa — ele cai porque o Underlay parou de conseguir alcançar o VTEP remoto. Toda correção real neste manual acontece no roteamento (uma rota ausente ou um vizinho instável), nunca na própria configuração VXLAN/NVE.
SOLUÇÃOComece a coleta de evidências pela tabela de roteamento, não pela configuração VXLAN — display ip routing-table em direção ao VTEP remoto é o primeiro comando que realmente importa.
SINTOMAO túnel volta brevemente após um shutdown de interface, e depois o incidente piora — mais tráfego afetado, não menos.
CAUSAO shutdown de interface é uma ação direcionada e deliberada contra uma adjacência instável específica identificada a partir de saídas repetidas de display ospf peer brief — não um movimento geral de “desligar tudo que pareça instável”. Fazer shutdown na interface errada pode remover um caminho que funciona em vez do que está instável.
SOLUÇÃOConfirme o vizinho instável por meio de várias execuções repetidas do comando antes de fazer shutdown em qualquer coisa, e faça shutdown apenas naquela interface.
SINTOMAA rota até o VTEP remoto parece boa, o OSPF não está instável, e mesmo assim o túnel permanece down ou continua reflapeando.
CAUSAUma placa de controle principal ou placa de interface com falha pode produzir exatamente essa assinatura — falhas de encaminhamento intermitentes que parecem um problema de roteamento pela CLI, quando a falha real é de hardware. É por isso que a etapa 1 verifica o status das placas e os alarmes de gerenciamento de rede antes mesmo de a etapa 2 começar.
SOLUÇÃOSe a evidência da etapa 2 não apontar claramente para uma rota ausente ou instável, volte e descarte uma falha de placa via gerenciamento de rede antes de gastar mais tempo com roteamento.
SINTOMAdisplay vxlan tunnel mostra State up minutos após a correção, e depois o túnel cai de novo.
CAUSAUm túnel que recupera State up confirma apenas que o sintoma imediato desapareceu — não confirma que o vizinho instável identificado na etapa 3b era realmente o certo, nem que sua causa subjacente (uma óptica com defeito, um link com falha, um dispositivo a montante instável) foi resolvida. Um shutdown de interface é explicitamente uma medida paliativa neste manual, não uma correção de encerramento.
SOLUÇÃOTrate a verificação da etapa 4 como confirmação de que o incidente está estável, não resolvido — agende a investigação de acompanhamento sobre por que aquela interface estava instável antes de fechar totalmente o chamado.
SINTOMAUm túnel nunca subiu — display vxlan tunnel mostra Down desde o início, sem transição de Up para Down para alarmar.
CAUSAhwNvo3VxlanTnlDown significa especificamente que um túnel anteriormente up caiu — é uma resposta de emergência para um túnel ativo e funcional que quebrou. Um túnel que nunca se estabeleceu é um tipo diferente de falha, causado pela configuração inicial em vez de algo que quebra um estado funcional.
SOLUÇÃOPara um túnel que nunca subiu, use o caminho de estabelecimento de túnel da nossa nota dedicada de solução de problemas do túnel VXLAN em vez deste manual de emergência — as causas e as correções são diferentes.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Sim — por isso a etapa 3b só recorre a isso depois que a etapa 2 já confirmou, por meio de várias verificações repetidas, exatamente qual vizinho está instável. É uma ação direcionada e baseada em evidências sobre uma interface identificada, não um passo de solução de problemas às cegas, e é explicitamente a segunda coisa que este manual tenta, não a primeira.
A presença da rota confirma que o caminho Underlay existe, não que o próprio VXLAN esteja saudável — nesse ponto isso deixa de ser um incidente de roteamento e se torna uma questão de estabelecimento VXLAN/EVPN. Nossa nota de solução de problemas do túnel VXLAN retoma exatamente a partir desse ponto.
Coexiste, para um momento diferente. Este manual é para a emergência específica de um alarme disparando em um túnel que estava funcionando um instante atrás — triagem rápida, evidência, uma correção paliativa, verificação. A nota completa de solução de problemas é para o trabalho mais profundo de causa raiz — problemas de rotas EVPN, incompatibilidades de VPN-Target, falhas de estabelecimento de túnel — para o qual os passos de coleta de evidências deste manual apontam.
Execute display ospf peer brief várias vezes seguidas, com alguns segundos de intervalo. Um vizinho que está se recuperando de um evento real se estabiliza e permanece assim; um vizinho instável continua aparecendo e desaparecendo ao longo das suas execuções repetidas. Se você executar o comando apenas uma vez, não consegue notar a diferença — é exatamente por isso que a etapa 2 exige verificações repetidas, não uma única olhada.
A interface que você desligou na etapa 3b ainda está down, e ela carregava exatamente a condição de instabilidade — uma óptica com defeito, um link marginal, um vizinho a montante instável. Isso é trabalho de acompanhamento, não trabalho de incidente: agende a investigação física/óptica e não volte a subir a interface até saber por que ela estava instável em primeiro lugar.
Este manual é construído em torno do alarme hwNvo3VxlanTnlDown e das duas causas raiz — perda de rota e instabilidade de rota — que respondem pela maioria desses chamados de emergência. Ele pressupõe que o túnel estava anteriormente up e estável; um túnel que nunca se estabeleceu é uma falha diferente, coberta em nossa nota de solução de problemas do túnel VXLAN, não aqui. Também não substitui uma investigação de hardware em nível de placa, que a etapa 1 diz para descartar primeiro mas não detalha, e não cobre a recuperação orquestrada por controlador em fabrics SDN, onde a mesma lógica Underlay se aplica mas os comandos diferem.
Diga-nos o que display ip routing-table e display ospf peer brief mostram para o túnel afetado, e ajudaremos você a encontrar o ponto de bifurcação rapidamente.