O controlador mostra um link entre sites em cinza, sem throughput ou dados de desempenho entre dois sites, e o próprio dispositivo não mostra nenhuma conexão EVPN. Este é o checklist em camadas que encontra a falha mais rápido — TNP, depois DTLS, depois a rota SD-WAN — com os comandos display exatos para cada camada, além do que verificar depois que uma conexão realmente se formou mas seu estado ainda não chega a UP.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Um link cinza no controlador só significa que dois sites ainda não estão trocando dados — não indica qual de vários problemas de underlay completamente diferentes está realmente causando isso.
Uma conexão EVPN entre dois sites SD-WAN depende de duas coisas existirem antes mesmo de poder se formar: os dois sites precisam ter aprendido o TNP (Tunnel Network Point) um do outro, o que por sua vez depende do DTLS estar estabelecido entre o CPE e o RR, e os dois sites precisam ter aprendido uma rota um para o outro — especificamente uma rota SD-WAN, não qualquer caminho alcançável. Verificar isso em ordem — TNP, depois DTLS, depois a rota — encontra a camada realmente quebrada muito mais rápido do que partir direto para uma captura de pacotes.
A seguir está a ordem de diagnóstico na qual isto se baseia, tirada do próprio modelo de classificação de falhas de SD-WAN/EVPN do roteador Huawei AR, as verificações e comandos para cada camada, o que verificar depois que uma conexão realmente se formou mas seu estado ainda não está UP, e um conjunto de respostas de perguntas frequentes tiradas do mesmo material de manutenção. Para a lógica de túnel IPSec/GRE sob uma VPN de filial mais convencional em vez de SD-WAN, veja «O túnel VPN IPSec não sobe?» e «O túnel VPN está ativo, mas o Ping falha».
As falhas de link SD-WAN se dividem em duas formas no controlador: não existe nenhuma conexão EVPN entre dois sites, ou existe uma conexão mas seu estado não chega a UP.
Colocar primeiro o sintoma nesta árvore indica se você está solucionando TNP/DTLS/roteamento, ou um problema mais específico de perfuração de NAT ou Keepalive em uma conexão que já existe.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
O ramo esquerdo é o que percorrer quando a conexão não existe de forma alguma — camada por camada, TNP primeiro. O ramo direito é uma questão mais específica sobre uma conexão que já se formou mas não consegue terminar de subir, e geralmente aponta para o caminho do NAT ou o Keepalive, não para o TNP ou a rota.
Cinco camadas, cada uma com seu próprio comando display — a árvore de falhas acima indica por qual começar.
Se o TNP não estiver UP, o DTLS nem sequer é disparado nesse link — comece por aqui antes de qualquer coisa.
<Huawei> display site-tnp 29 verbose
// V300 -- confirms whether the TNP's underlying interface protocol is Up;
// with NAT traversal off, TNP state depends only on interface protocol state
<Huawei> display evpn site-tnp 29 verbose
// V600 equivalent
<Huawei> tracert -p 3478
// checks whether the path blocks the NAT probe portO TNP de CPE para RR é aprendido via DTLS, então se o TNP não sobe e o NAT traversal não é o problema, o DTLS é a próxima camada a verificar.
<Huawei> display dtls peer-connection status
// V300 -- CLOSE = established; INIT / REGISTERING = not established
<Huawei> display dtls client connection
// V600 equivalent
<Huawei> tracert -p 55100
// DTLS uses port 55100 -- check whether a firewall in the path is blocking itO EVPN precisa de duas coisas para se formar: o TNP do site de destino, e uma rota para esse site que seja especificamente uma rota SD-WAN — não qualquer caminho alcançável.
<Huawei> display smart-policy-route spr-index-table all
// V300 only -- confirms whether an SD-WAN route to the destination site exists
<Huawei> display saved-configuration
// Tunnel / BGP entries present here after a reboot = save was executed on an
// SD-WAN device that should never have allowed it (R19C00) -- factory-reset and re-onboardO TNP, o DTLS e a rota estão todos corretos, mas a conexão ainda não se forma — isto é o que resta.
<Huawei> display evpn connection verbose
// current connection count vs. spec -- Full-Mesh + a low-end model can exceed it
<Huawei> display site-tnp 29 verbose
// Current Conn Ref Count = 0 -> this end has no business route from the peer site
<Huawei> display bgp evpn all routing-table peer 10.0.0.2 received-routes
<Huawei> display bgp evpn all routing-table peer 10.0.0.2 advertised-routes
// received-routes on the branch/RR, advertised-routes on the RR -- confirms
// whether the business route was actually reflected onwardUma pergunta mais específica: display evpn connection agora mostra algo, mas seu estado não chega a UP.
<Huawei> display connection 12345
// V300 -- ConnStatus: Invalid / Init / NatParse / CheckConn / Pending / Active
// stuck at NatParse specifically = NAT hole punching failed
<Huawei> display evpn connection 12345 verbose
// V600 equivalent; SourcePublicPort / DestPublicPort -- compare both ends
// for an asymmetric NAT translating the two directions inconsistently
<Huawei> display fe slot 0 fe-id 0 table connect-encap 12345
// SEND_KA_CNT / RECV_KA_COUNT -- send-without-receive on one side points at
// the network in between, not the CPEDepois que as camadas acima indicarem onde está o problema, essas seis causas explicam a maior parte do que realmente está errado.
SINTOMAO estado do TNP não chega a UP em um link específico, mesmo que a própria interface esteja Up.
CAUSACom o NAT traversal desligado, o estado do TNP só acompanha o estado de protocolo da própria interface — então ligar o NAT traversal em um link que na verdade não tem NAT dispara uma sondagem sem motivo para ter sucesso de forma limpa, e deixá-lo desligado em um link que tem NAT pula uma sondagem que o link realmente precisa. Qualquer uma das incompatibilidades impede que o TNP confirme UP.
SOLUÇÃOAjuste a configuração de NAT traversal ao que realmente existe no caminho WAN, por link, na visão de link WAN do controlador — não uma configuração única aplicada a todos os sites.
SINTOMADois sites RR, nenhum atrás de NAT, ainda assim não conseguem fazer sua conexão EVPN chegar a UP.
CAUSAEste é um caso real documentado — ambos os sites RR tinham endereços Public configurados manualmente, e os valores estavam trocados: o endereço Public do RR1 foi definido como o endereço de interface do RR2, e o do RR2 como o do RR1. O endereço parecia plausível em cada dispositivo individualmente, que é exatamente por que uma revisão de configuração não detectou isso.
SOLUÇÃOConfirme que nenhum dos sites RR realmente precisa de um endereço Public configurado manualmente (a ausência de NAT no caminho geralmente significa que não deveria ser definido); se um for necessário, verifique-o contra o endereço de interface real do peer em vez de assumir que foi copiado corretamente.
SINTOMAEm uma rede SD-WAN Full-Mesh, um site — geralmente o modelo de baixo custo — consegue alcançar alguns sites mas não outros, sem uma falha óbvia por link.
CAUSAFull-Mesh significa que cada site tenta construir uma conexão EVPN com todos os outros sites da rede; um modelo de dispositivo carrega uma especificação rígida de quantidade de conexões, e um CPE de baixo custo em uma implantação Full-Mesh grande pode simplesmente ficar sem espaço antes que todos os sites sejam conectados.
SOLUÇÃOVerifique display evpn connection verbose em relação à quantidade nominal de conexões do modelo; se a quantidade de sites cresceu além do que o hardware implantado suporta, redimensione o modelo do site ou roteie esse site por um RR/Hub em vez de esperar malha completa.
SINTOMAA máquina de estados de conexão de dois sites de filial fica indefinidamente em NatParse; o underlay é alcançável e a porta 4500 está aberta.
CAUSADuas combinações específicas de NAT não conseguem perfurar com sucesso, não importa como o resto da rede esteja configurado: um lado atrás de NAT Port Restricted Cone com o outro atrás de NAT Symmetric, ou ambos os lados atrás de NAT Symmetric.
SOLUÇÃOIsso não é uma correção de configuração, é uma restrição de desenho de rede. Confirme o tipo de NAT no dispositivo de borda de cada site, e onde a combinação não for suportada, roteie o tráfego desse par através de um RR/Hub em vez de esperar uma conexão direta site a site.
SINTOMAO estado da conexão EVPN oscila Up/Down repetidamente sem nada visivelmente errado no underlay, na largura de banda, na CPU ou no duplex do link.
CAUSAUm caso real documentado: o TNP de um lado ainda referencia um TNP peer que o outro lado já substituiu — o lado distante mostra dois de seus próprios TNPs conectados ao único TNP do lado próximo, enquanto o lado próximo mostra apenas esse único TNP conectado de volta. A referência obsoleta continua disparando renegociação.
SOLUÇÃOreset connection site-tnp no V300, ou reset evpn site-tnp no V600, limpa o resíduo e permite que os dois lados reaprendam uma relação TNP consistente.
SINTOMAEm uma implantação de gateway duplo, os dois CPEs discordam sobre o estado do link — um mostra seu link local Up enquanto o peer mostra o link estendido correspondente Down, ou o contrário.
CAUSAO Interlink entre os dois CPEs de gateway duplo serve para sincronizar o estado do link entre eles; se display ms-channel mostrar Connected em um CPE e Disconnected no outro para o mesmo Interlink, o link está funcionando em uma via só — as mensagens de sincronização só passam em uma direção.
SOLUÇÃOConfirme a incompatibilidade com display ms-channel nos dois CPEs, depois verifique os contadores de heartbeat com duas chamadas de display ms-channel-static com cinco segundos de intervalo — TX aumentando mas não RX (ou o contrário) reduz o problema a uma conexão física ou cabeamento no próprio Interlink, não na configuração SD-WAN.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Verifique primeiro o estado do TNP (display site-tnp / display evpn site-tnp verbose) — se não estiver UP, nada além desse ponto importa ainda. Se o TNP estiver UP, verifique em seguida o DTLS (CLOSE significa estabelecido). Se o DTLS estiver bem, verifique uma rota para o site de destino especificamente como rota SD-WAN (display smart-policy-route spr-index-table all no V300). Só depois que os três estiverem bem é que faz sentido olhar para a quantidade de conexões, configuração incorreta de NAT/endereço, ou um link unilateral.
Sim — a existência de uma conexão significa que o TNP e a rota SD-WAN já estão bem dos dois lados. O que resta é a alcançabilidade do underlay, se os dois lados realmente construíram a conexão (compare display evpn connection site-id em cada lado), a perfuração de NAT (ConnStatus travado em NatParse), ou um Keepalive que não está passando em uma direção.
NatParse é a etapa de perfuração da máquina de estados da conexão (Invalid → Init → NatParse → CheckConn → Pending → Active); ficar travado ali aponta para a alcançabilidade do underlay, a porta 4500 bloqueada em algum ponto do caminho, um dispositivo NAT traduzindo as duas direções de forma inconsistente (compare SourcePublicPort em um lado com DestPublicPort no outro), ou uma combinação de tipos de NAT fundamentalmente não suportada entre os dois lados.
Perda de pacotes no underlay, uma porta Interlink de gateway duplo Down, uma interface WAN travada em half-duplex, tráfego excedendo a largura de banda do link, sobrecarga de CPU no dispositivo (verifique display cpu-usage por um núcleo a 100%), jitter de latência do link disparando um temporizador de detecção de falhas ajustado de forma muito agressiva, ou resíduo de TNP onde um lado referencia um TNP peer que o outro lado não tem mais.
Compare primeiro Current Conn Ref Count em display site-tnp {site-id} verbose nos dois lados; 0 significa que este lado não tem nenhuma rota de negócio do peer. Depois verifique display bgp evpn all routing-table peer ip received-routes na filial e no RR, e advertised-routes no RR, para descobrir se a rota de negócio foi recebida e realmente refletida adiante — uma whitelist de política de rotas do lado receptor que não cobre a sub-rede real do peer é a causa silenciosa mais comum.
Não necessariamente. Um TNP que está Down em um CPE nunca é sincronizado com seu peer de gateway duplo, então uma diferença de quantidade causada especificamente por um TNP Down não sendo refletido é normal e esperada. Só se torna uma falha real se todos os TNPs envolvidos mostrarem Up nos dois CPEs e as quantidades ainda discordarem — nesse ponto, ciclar a interface física (shutdown / undo shutdown) é o próximo passo, e se isso não resolver, escale com os logs de display ms-channel-static dos dois CPEs e uma captura de debugging connection all.
Esta nota se baseia no modelo de classificação de falhas de SD-WAN EVPN do roteador Huawei série AR/NetEngine AR — o escalonamento TNP/DTLS/rota e os comandos display site-tnp / display evpn connection / display dtls / display ms-channel, além dos casos de campo por trás deles, tirados da mesma documentação de manutenção que cobre especificamente cenários SD-WAN. Os nomes dos comandos diferem ligeiramente entre os conjuntos de comandos V300 e V600; ambos são apresentados lado a lado acima onde quer que divirjam. Não cobre integralmente as telas de configuração do lado do controlador, falhas de reconhecimento de aplicativos ou seleção de caminho, nem os diagnósticos específicos de perda de pacotes que estão em um capítulo separado do mesmo material fonte.
Conte-nos em qual camada está travado — TNP, DTLS, ou a rota SD-WAN — junto com a saída de display site-tnp / display evpn connection, e ajudamos você a interpretá-la.