El controlador muestra un enlace entre sitios en gris, sin throughput ni datos de rendimiento entre dos sitios, y el propio dispositivo no muestra ninguna conexión EVPN. Esta es la lista de verificación por capas que encuentra la falla más rápido — TNP, luego DTLS, luego la ruta SD-WAN — con los comandos display exactos para cada capa, más qué revisar una vez que una conexión realmente se formó pero su estado sigue sin llegar a UP.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Un enlace gris en el controlador solo significa que dos sitios aún no están intercambiando datos — no indica cuál de varios problemas de underlay completamente distintos lo está causando realmente.
Una conexión EVPN entre dos sitios SD-WAN depende de que existan dos cosas antes de poder formarse siquiera: los dos sitios deben haber aprendido el TNP (Tunnel Network Point) uno del otro, lo cual depende a su vez de que el DTLS esté establecido entre el CPE y el RR, y los dos sitios deben haber aprendido una ruta entre sí — específicamente una ruta SD-WAN, no cualquier camino alcanzable. Revisar esto en orden — TNP, luego DTLS, luego la ruta — encuentra la capa realmente rota mucho más rápido que saltar directamente a una captura de paquetes.
A continuación, el orden de diagnóstico en el que se basa este texto, tomado del propio modelo de clasificación de fallas SD-WAN/EVPN del router Huawei AR, las comprobaciones y comandos para cada capa, qué revisar una vez que una conexión realmente se formó pero su estado aún no está UP, y una serie de respuestas de preguntas frecuentes extraídas del mismo material de mantenimiento. Para la lógica de túnel IPSec/GRE bajo una VPN de sucursal más convencional en lugar de SD-WAN, vea «¿El túnel VPN IPSec no se establece?» y «El túnel VPN está activo pero el Ping falla».
Los fallos de enlace SD-WAN se dividen en dos formas en el controlador: no existe ninguna conexión EVPN entre dos sitios, o existe una conexión pero su estado no llega a UP.
Ubicar primero el síntoma en este árbol indica si se está solucionando TNP/DTLS/enrutamiento, o un problema más específico de perforación NAT o Keepalive en una conexión que ya existe.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
La rama izquierda es lo que hay que recorrer cuando la conexión no existe en absoluto — capa por capa, TNP primero. La rama derecha es una pregunta más específica sobre una conexión que ya se formó pero no termina de activarse, y generalmente apunta a la ruta NAT o al Keepalive, no a TNP ni a la ruta.
Cinco capas, cada una con su propio comando display — el árbol de fallas anterior indica por cuál empezar.
Si el TNP no está UP, el DTLS ni siquiera se dispara en ese enlace — empiece aquí antes que nada.
<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 portEl TNP de CPE a RR se aprende mediante DTLS, así que si el TNP no se activa y la traversía NAT no es el problema, el DTLS es la siguiente capa a revisar.
<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 itEl EVPN necesita dos cosas para formarse: el TNP del sitio de destino, y una ruta hacia ese sitio que sea específicamente una ruta SD-WAN — no cualquier camino alcanzable.
<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-onboardEl TNP, el DTLS y la ruta están todos bien, pero la conexión sigue sin formarse — esto es lo que queda.
<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 onwardUna pregunta más específica: display evpn connection ahora muestra algo, pero su estado no llega 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 CPEUna vez que las capas anteriores le han indicado dónde está el problema, estas seis causas explican la mayor parte de lo que realmente falla.
SÍNTOMAEl estado del TNP no llega a UP en un enlace específico, aunque la interfaz misma esté activa.
CAUSACon la traversía NAT desactivada, el estado del TNP solo sigue el estado de protocolo propio de la interfaz — así que activar la traversía NAT en un enlace que en realidad no tiene NAT dispara una sonda sin motivo para tener éxito limpiamente, y dejarla desactivada en un enlace que sí tiene NAT omite una sonda que el enlace realmente necesita. Cualquiera de las dos discrepancias impide que el TNP confirme UP.
SOLUCIÓNAjuste la configuración de traversía NAT a lo que realmente hay en la ruta WAN, por enlace, en la vista de enlace WAN del controlador — no una configuración única aplicada a todos los sitios.
SÍNTOMADos sitios RR, ninguno detrás de NAT, aun así no logran que su conexión EVPN llegue a UP.
CAUSAEste es un caso real documentado — ambos sitios RR tenían direcciones Public configuradas manualmente, y los valores estaban invertidos: la dirección Public de RR1 se configuró como la dirección de interfaz de RR2, y la de RR2 como la de RR1. La dirección parecía plausible en cada dispositivo individualmente, que es exactamente por qué una revisión de configuración no lo detectó.
SOLUCIÓNConfirme que ninguno de los sitios RR realmente necesita una dirección Public configurada manualmente (que no haya NAT en la ruta generalmente significa que no debería configurarse); si se requiere una, verifíquela contra la dirección de interfaz real del par en lugar de asumir que se copió correctamente.
SÍNTOMAEn una red SD-WAN Full-Mesh, un sitio — generalmente el modelo de gama baja — puede alcanzar algunos sitios pero no otros, sin una falla obvia por enlace.
CAUSAFull-Mesh significa que cada sitio intenta construir una conexión EVPN hacia todos los demás sitios de la red; un modelo de dispositivo lleva una especificación estricta de cantidad de conexiones, y un CPE de gama baja en un gran despliegue Full-Mesh puede simplemente quedarse sin espacio antes de que todos los sitios estén conectados.
SOLUCIÓNVerifique display evpn connection verbose frente a la cantidad de conexiones nominal del modelo; si la cantidad de sitios ha crecido más allá de lo que el hardware desplegado admite, cambie el modelo del sitio o enrute ese sitio a través de un RR/Hub en lugar de esperar malla completa.
SÍNTOMALa máquina de estados de conexión de dos sitios sucursal permanece indefinidamente en NatParse; el underlay es alcanzable y el puerto 4500 está abierto.
CAUSADos combinaciones específicas de NAT no logran perforar con éxito sin importar cómo esté configurado el resto de la red: un extremo detrás de NAT Port Restricted Cone con el otro detrás de NAT Symmetric, o ambos extremos detrás de NAT Symmetric.
SOLUCIÓNEsto no es una solución de configuración, es una restricción de diseño de red. Confirme el tipo de NAT en el dispositivo de borde de cada sitio, y donde la combinación no sea compatible, enrute el tráfico de ese par a través de un RR/Hub en lugar de esperar una conexión directa de sitio a sitio.
SÍNTOMAEl estado de la conexión EVPN fluctúa Up/Down repetidamente sin nada visiblemente mal en el underlay, el ancho de banda, la CPU o el dúplex del enlace.
CAUSAUn caso real documentado: el TNP de un lado sigue haciendo referencia a un TNP par que el otro lado ya reemplazó — el extremo lejano muestra dos de sus propios TNP conectados al único TNP del extremo cercano, mientras que el extremo cercano solo muestra ese único TNP conectado de vuelta. La referencia obsoleta sigue disparando la renegociación.
SOLUCIÓNreset connection site-tnp en V300, o reset evpn site-tnp en V600, limpia el residuo y permite que ambos extremos vuelvan a aprender una relación TNP consistente.
SÍNTOMAEn un despliegue de doble gateway, los dos CPE no coinciden en el estado del enlace — uno muestra su enlace local Up mientras el par muestra el enlace extendido correspondiente Down, o al revés.
CAUSAEl Interlink entre los dos CPE de doble gateway está pensado para sincronizar el estado del enlace entre ellos; si display ms-channel muestra Connected en un CPE y Disconnected en el otro para el mismo Interlink, el enlace está funcionando en un solo sentido — los mensajes de sincronización solo pasan en una dirección.
SOLUCIÓNConfirme la discrepancia con display ms-channel en ambos CPE, luego verifique los contadores de latido con dos llamadas a display ms-channel-static separadas por cinco segundos — TX aumentando pero no RX (o al revés) lo reduce a un problema de conexión física o cableado en el propio Interlink, no en la configuración SD-WAN.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
Verifique primero el estado del TNP (display site-tnp / display evpn site-tnp verbose) — si no está UP, nada más allá de este punto importa todavía. Si el TNP está UP, verifique a continuación el DTLS (CLOSE significa establecido). Si el DTLS está bien, verifique una ruta hacia el sitio de destino específicamente como ruta SD-WAN (display smart-policy-route spr-index-table all en V300). Solo una vez que los tres estén bien tiene sentido revisar la cantidad de conexiones, una mala configuración de NAT/dirección, o un enlace unilateral.
Sí — que exista una conexión significa que el TNP y la ruta SD-WAN ya están bien en ambos lados. Lo que queda es la alcanzabilidad del underlay, si ambos lados realmente construyeron la conexión (compare display evpn connection site-id en cada extremo), la perforación NAT (ConnStatus atascado en NatParse), o un Keepalive que no pasa en una dirección.
NatParse es la etapa de perforación de la máquina de estados de la conexión (Invalid → Init → NatParse → CheckConn → Pending → Active); quedarse atascado ahí apunta a la alcanzabilidad del underlay, el puerto 4500 bloqueado en algún punto de la ruta, un dispositivo NAT que traduce las dos direcciones de forma inconsistente (compare SourcePublicPort en un extremo con DestPublicPort en el otro), o una combinación de tipos de NAT fundamentalmente no compatible entre los dos extremos.
Pérdida de paquetes en el underlay, un puerto Interlink de doble gateway Down, una interfaz WAN atascada en semidúplex, tráfico que supera el ancho de banda del enlace, sobrecarga de CPU en el dispositivo (verifique display cpu-usage por un núcleo al 100 %), fluctuación de latencia del enlace que dispara un temporizador de detección de fallas configurado de forma demasiado agresiva, o residuo de TNP donde un lado hace referencia a un TNP par que el otro lado ya no tiene.
Compare primero Current Conn Ref Count en display site-tnp {site-id} verbose en ambos extremos; 0 significa que este extremo no tiene ninguna ruta de negocio del par. Luego verifique display bgp evpn all routing-table peer ip received-routes en la sucursal y el RR, y advertised-routes en el RR, para saber si la ruta de negocio se recibió y se reflejó realmente — una lista blanca de política de rutas del lado receptor que no cubre la subred real del par es la causa silenciosa más común.
No necesariamente. Un TNP que está Down en un CPE nunca se sincroniza con su par de doble gateway, así que una diferencia de cantidad causada específicamente por un TNP Down que no se refleja es normal y esperada. Solo se convierte en una falla real si todos los TNP involucrados muestran Up en ambos CPE y las cantidades siguen sin coincidir — en ese punto, ciclar la interfaz física (shutdown / undo shutdown) es el siguiente paso, y si eso no lo resuelve, escale con los registros de display ms-channel-static de ambos CPE y una captura de debugging connection all.
Esta nota se basa en el modelo de clasificación de fallas SD-WAN EVPN del router Huawei serie AR/NetEngine AR — la estratificación TNP/DTLS/ruta y los comandos display site-tnp / display evpn connection / display dtls / display ms-channel, además de los casos de campo que los respaldan, tomados de la misma documentación de mantenimiento que cubre específicamente escenarios SD-WAN. Los nombres de los comandos difieren ligeramente entre los conjuntos de comandos V300 y V600; ambos se dan lado a lado arriba dondequiera que difieran. No cubre en su totalidad las pantallas de configuración del lado del controlador, las fallas de reconocimiento de aplicaciones o selección de ruta, ni los diagnósticos específicos de pérdida de paquetes que están en un capítulo separado del mismo material fuente.
Cuéntenos en qué capa está atascado — TNP, DTLS, o la ruta SD-WAN — junto con la salida de display site-tnp / display evpn connection, y le ayudamos a interpretarla.