La alarma hwNvo3VxlanTnlDown se dispara, y un túnel que estaba bien hace un minuto ha desaparecido. Este es el orden que lo restablece de forma segura — qué confirmar primero, qué reunir antes de cambiar cualquier cosa, las dos causas raíz que explican la mayoría de estas alarmas, y cómo demostrar que la corrección realmente funcionó antes de cerrar el ticket.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
El instinto cuando se dispara una alarma es corregir lo primero que parece mal. En una alarma de túnel VXLAN, ese instinto causa más interrupciones de las que evita.
hwNvo3VxlanTnlDown significa exactamente una cosa: un túnel VXLAN que estaba up se cayó. No dice por qué, y reaccionar solo al texto de la alarma — reiniciar un proceso, hacer bounce de una interfaz, aplicar un cambio de configuración — es como una alarma de un solo túnel se convierte en una interrupción más amplia. Este manual sigue un orden fijo: confirmar qué pasó realmente y hasta dónde llega, reunir la evidencia que distingue la causa raíz del ruido, trabajar las dos causas que explican la mayoría de estos casos, y verificar que ese túnel específico se recuperó antes de darlo por resuelto.
A continuación, ese orden con los comandos exactos, el comando que con más frecuencia termina el incidente — un shutdown de interfaz específico — y por qué tiene que ser la interfaz correcta, no cualquiera que parezca inestable.
Cuatro pasos, un punto de bifurcación — vale la pena tener este esquema a la vista antes de tocar nada.
El punto de bifurcación es simple: ¿la ruta hacia el VTEP remoto desapareció por completo, o está presente pero inestable? Las dos respuestas llevan a dos correcciones completamente distintas, y aplicar la equivocada desperdicia los minutos que más importan durante una interrupción activa.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Todo lo que está antes del punto de bifurcación es confirmación y recolección de evidencia, no remediación — resista la tentación de corregir algo hasta saber en qué lado de la bifurcación está.
Cuatro etapas: confirmar y delimitar el alcance, reunir evidencia, aplicar la corrección correspondiente, verificar el túnel específico — no la red en general.
Antes de tocar cualquier configuración, sepa qué está realmente roto y hasta dónde llega.
%%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 problemDos comandos le indican con cuál de las dos causas raíz está lidiando — ejecute ambos antes de decidir una corrección.
<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 es una pérdida real de ruta hacia el peer, no un síntoma de inestabilidad — trátelo como una falla de enrutamiento/EVPN, no una falla de túnel.
Esta es la corrección que realmente resuelve la mayoría de estas alarmas — un corte pequeño, deliberado y temporal, no un bounce de interfaz al azar.
[~HUAWEI] interface 10ge 1/0/1 // example only -- use the interface you identified as flapping
[~HUAWEI-10GE1/0/1] shutdown
[*HUAWEI-10GE1/0/1] commitUn ping funcional en otra parte del fabric no confirma que este túnel se recuperó — verifique el túnel en sí, por su 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 incidentUna vez que las cuatro etapas anteriores han indicado dónde está el incidente, estos cinco puntos explican la mayor parte de lo que aún sorprende a la gente.
SÍNTOMAhwNvo3VxlanTnlDown parece un problema de VXLAN, así que el instinto es ir primero a revisar la configuración VXLAN o NVE.
CAUSAEl túnel es un pasajero, no la causa — cae porque el Underlay dejó de poder alcanzar el VTEP remoto. Toda corrección real en este manual ocurre en el enrutamiento (una ruta faltante o un vecino inestable), nunca en la propia configuración VXLAN/NVE.
SOLUCIÓNComience la recolección de evidencia por la tabla de enrutamiento, no por la configuración VXLAN — display ip routing-table hacia el VTEP remoto es el primer comando que realmente importa.
SÍNTOMAEl túnel vuelve brevemente después de un shutdown de interfaz, y luego el incidente empeora — más tráfico afectado, no menos.
CAUSAEl shutdown de interfaz es una acción dirigida y deliberada contra una adyacencia inestable específica identificada a partir de salidas repetidas de display ospf peer brief — no un movimiento general de “apagar todo lo que parezca inestable”. Hacer shutdown de la interfaz equivocada puede eliminar una ruta que funciona en lugar de la inestable.
SOLUCIÓNConfirme el vecino inestable mediante varias ejecuciones repetidas del comando antes de hacer shutdown de cualquier cosa, y haga shutdown solo de esa interfaz.
SÍNTOMALa ruta hacia el VTEP remoto se ve bien, OSPF no está inestable, y sin embargo el túnel permanece caído o sigue reflapeando.
CAUSAUna tarjeta de control principal o una tarjeta de interfaz con fallas puede producir exactamente esta firma — fallas de reenvío intermitentes que parecen un problema de enrutamiento desde la CLI, cuando la falla real es de hardware. Por eso la etapa 1 verifica el estado de las tarjetas y las alarmas de gestión de red antes incluso de que comience la etapa 2.
SOLUCIÓNSi la evidencia de la etapa 2 no apunta claramente a una ruta faltante o inestable, vuelva atrás y descarte una falla de tarjeta mediante la gestión de red antes de dedicar más tiempo al enrutamiento.
SÍNTOMAdisplay vxlan tunnel muestra State up minutos después de la corrección, y luego el túnel vuelve a caer.
CAUSAUn túnel que recupera State up solo confirma que el síntoma inmediato desapareció — no confirma que el vecino inestable identificado en la etapa 3b fuera realmente el correcto, ni que su causa subyacente (una óptica defectuosa, un enlace con fallas, un dispositivo aguas arriba inestable) se haya resuelto. Un shutdown de interfaz es explícitamente una medida provisional en este manual, no una corrección de cierre.
SOLUCIÓNConsidere la verificación de la etapa 4 como confirmación de que el incidente está estable, no resuelto — programe la investigación de seguimiento sobre por qué esa interfaz estaba inestable antes de cerrar completamente el ticket.
SÍNTOMAUn túnel nunca se estableció en primer lugar — display vxlan tunnel muestra Down desde el inicio, sin transición de Up a Down que alarmar.
CAUSAhwNvo3VxlanTnlDown significa específicamente que un túnel previamente up se cayó — es una respuesta de emergencia para un túnel activo y funcional que se rompió. Un túnel que nunca se estableció en absoluto es un tipo de falla diferente, impulsada por la configuración inicial en lugar de algo que rompe un estado funcional.
SOLUCIÓNPara un túnel que nunca se estableció, use la ruta de establecimiento de túnel de nuestra nota dedicada de resolución de problemas del túnel VXLAN en lugar de este manual de emergencia — las causas y las correcciones son distintas.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
Sí — por eso la etapa 3b solo recurre a ello después de que la etapa 2 ya haya confirmado, mediante varias comprobaciones repetidas, exactamente qué vecino está inestable. Es una acción dirigida y basada en evidencia sobre una interfaz identificada, no un paso de resolución de problemas a ciegas, y es explícitamente lo segundo que este manual intenta, no lo primero.
La presencia de la ruta confirma que el camino Underlay existe, no que VXLAN en sí esté sano — en ese punto esto deja de ser un incidente de enrutamiento y se convierte en una cuestión de establecimiento VXLAN/EVPN. Nuestra nota de resolución de problemas del túnel VXLAN retoma exactamente desde este punto.
Coexiste, para un momento distinto. Este manual es para la emergencia específica de una alarma que se dispara en un túnel que funcionaba hace un momento — triaje rápido, evidencia, una corrección provisional, verificación. La nota completa de resolución de problemas es para el trabajo más profundo de causa raíz — problemas de rutas EVPN, discrepancias de VPN-Target, fallas de establecimiento de túnel — hacia el que apuntan los pasos de recolección de evidencia de este manual.
Ejecute display ospf peer brief varias veces seguidas, con unos segundos de diferencia. Un vecino que se recupera de un evento real se estabiliza y permanece así; un vecino inestable sigue apareciendo y desapareciendo a lo largo de sus ejecuciones repetidas. Si solo ejecuta el comando una vez, no puede notar la diferencia — por eso exactamente la etapa 2 exige comprobaciones repetidas, no una sola mirada.
La interfaz que apagó en la etapa 3b sigue caída, y era la que llevaba la condición de inestabilidad real — una óptica defectuosa, un enlace marginal, un vecino aguas arriba inestable. Eso es trabajo de seguimiento, no trabajo de incidente: programe la investigación física/óptica y no vuelva a levantar la interfaz hasta saber por qué estaba inestable en primer lugar.
Este manual se basa en la alarma hwNvo3VxlanTnlDown y en las dos causas raíz — pérdida de ruta e inestabilidad de ruta — que explican la mayoría de estos tickets de emergencia. Asume que el túnel estaba previamente up y estable; un túnel que nunca se estableció en absoluto es una falla distinta, cubierta en nuestra nota de resolución de problemas del túnel VXLAN, no aquí. Tampoco reemplaza una investigación de hardware a nivel de tarjeta, que la etapa 1 le indica descartar primero pero no detalla, y no cubre la recuperación orquestada por controlador en fabrics SDN, donde se aplica la misma lógica Underlay pero los comandos difieren.
Cuéntenos qué muestran display ip routing-table y display ospf peer brief para el túnel afectado, y le ayudaremos a encontrar rápidamente el punto de bifurcación.