Una interfaz de túnel GRE atascada en estado Down es una lista de verificación corta y mecánica, no un misterio — modo de encapsulación, direccionamiento origen/destino, clave GRE, la ruta hacia el extremo remoto, y la configuración de keepalive, revisados en ese orden. Esta es la secuencia de diagnóstico, los comandos exactos para cada verificación, y la prueba práctica de tamaño de ping que encuentra un techo silencioso de MTU/fragmentación antes de que derribe un túnel bajo carga.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Siete elementos de configuración deciden si una interfaz de túnel GRE sube — y la falla casi siempre se reduce exactamente a uno de ellos.
Una interfaz de túnel GRE que reporta Down es uno de los trabajos de resolución de problemas más mecánicos en enrutamiento — el modelo de clasificación de fallas detrás de esto enumera siete elementos específicos a revisar, en orden: modo de encapsulación, direccionamiento IP, asignación de origen/destino, clave GRE, la ruta subyacente hacia el destino, configuración de keepalive, y dimensionamiento de MTU/MSS. Casi todo ticket de "el túnel simplemente no sube" se resuelve en uno de esos elementos.
Esto es deliberadamente distinto de un túnel que ya está Up pero no deja pasar el tráfico correctamente — eso es un problema de enrutamiento o de detalle de encapsulación en un túnel que ya existe, y lo cubrimos por separado en nuestra nota sobre un túnel VPN activo pero con fallo de ping. Lo que sigue aquí es qué revisar antes de que la interfaz del túnel siquiera reporte Up, más el método práctico de campo — probar con distintos tamaños de ping — para encontrar un techo de MTU/fragmentación que una simple lectura de configuración nunca revelará.
Los problemas de GRE se dividen igual que la mayoría de problemas de túnel: la interfaz nunca sube, o sube y algo aguas abajo sigue sin funcionar.
Ubicar primero el síntoma en este árbol indica si se trata de un problema de establecimiento — esta nota — o de un problema de enrutamiento/encapsulación en un túnel que ya existe, lo cual pertenece a un camino de diagnóstico completamente distinto.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Todo lo que está en la rama izquierda se lee directamente de la propia configuración y contadores de la interfaz del túnel — display this, display ip routing-table, display keepalive packets count. Una vez que la interfaz reporta Up, se aplica un diagnóstico distinto, y eso pertenece al territorio de la nota complementaria, no de esta.
Cuatro comprobaciones en el orden del que depende la propia interfaz del túnel, más la prueba de campo para el único modo de falla que una lectura de configuración no puede detectar.
display this en la interfaz del túnel detecta la mayoría de lo que realmente impide que un túnel GRE llegue a subir.
[HUAWEI-Tunnel0] display this
#
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source 10GE0/0/0
destination 1.1.1.2
#
return
// confirm the peer's source/destination are the exact mirror of these two linesLa dirección de destino del túnel tiene que ser alcanzable a través de una ruta que no sea el propio túnel — esta es la trampa de enrutamiento recursivo más común.
<Huawei> display ip routing-table
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.2/32 Static 60 0 20.1.1.2 GigabitEthernet0/0/1
// outbound interface is the physical uplink, not Tunnel0 -- this is correct
<Huawei> display ip interface brief
Interface IP Address/Mask Physical Protocol
Tunnel0 172.16.1.1/30 up upEl Keepalive de GRE solo informa sobre la dirección en la que se habilitó — un túnel puede parecer caído desde un extremo y estar bien desde el otro.
# This platform's Tunnel interface
interface Tunnel1
tunnel-protocol gre
keepalive period 10 // Cisco's minimum configurable period is 10s
source 2.2.2.2
destination 1.1.1.1
# Cisco's Tunnel interface (defaults to GRE already)
interface Tunnel1
keepalive 10 3
tunnel source Loopback0
tunnel destination 2.2.2.2
<Huawei> display keepalive packets count
Keepalive sent: 120 Reply received: 118
// sent greater than reply received -> packets lost toward the peer or on the way backEsta es una prueba práctica, no una verificación de configuración — ejecútela siempre que el túnel suba bien pero caiga bajo tráfico real, o no se mantenga estable bajo carga.
<Huawei> ping -s 1400 -a 172.16.1.1 172.16.1.2
Request time out
<Huawei> ping -s 1350 -a 172.16.1.1 172.16.1.2
Reply from 172.16.1.2: bytes=1350 time=2 ms
// breakpoint found between 1350 and 1400 -- set the tunnel MTU at or below it
[HUAWEI-Tunnel0] mtu 1350
[HUAWEI-GigabitEthernet0/0/1] tcp adjust-mss 1300
// leave headroom under the tunnel MTU for GRE + IP + TCP header overheadUna vez que las comprobaciones anteriores han indicado dónde está el problema, estas cinco causas cubren la mayoría de lo que realmente falla.
SÍNTOMAdisplay this en la interfaz Tunnel muestra lo que parece una configuración completa en ambos extremos, pero el estado de la interfaz sigue en Down.
CAUSAEl destino de este lado tiene que ser el origen del par, y viceversa, y el tunnel-protocol de ambos extremos tiene que coincidir exactamente — basta con que un solo campo esté configurado con la dirección equivocada, o un protocolo dejado en un modo distinto, y no produce ningún error específico en ninguna parte.
SOLUCIÓNLea display this lado a lado en ambas interfaces de túnel y confirme que origen/destino son espejos exactos y que tunnel-protocol gre coincide en ambos extremos.
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source 10GE0/0/0
destination 1.1.1.2
// peer's tunnel interface must show source 1.1.1.2 / destination (this end's source)SÍNTOMATodo en la configuración del túnel parece correcto, pero la interfaz nunca llega a Up y no hay nada en los registros que indique por qué.
CAUSAgre key es un simple valor compartido que ambos extremos deben configurar de forma idéntica; una discrepancia hace que el extremo receptor descarte silenciosamente los paquetes encapsulados en GRE del extremo remoto, como si nunca hubieran llegado.
SOLUCIÓNConfirme que exactamente el mismo valor de gre key esté configurado en ambas interfaces de túnel — no existe tolerancia de coincidencia parcial.
SÍNTOMALa interfaz del túnel sube, luego cae, luego vuelve a subir — repetidamente — sin ningún problema evidente de enlace o hardware.
CAUSAO no existe ninguna ruta hacia la dirección de destino del túnel, o la ruta existente vuelve a apuntar hacia la propia interfaz del túnel (un bucle de enrutamiento), o un protocolo de enrutamiento dinámico que corre sobre el túnel está reanunciando inadvertidamente la propia ruta del destino de vuelta a través de él.
SOLUCIÓNConfirme con display ip routing-table que la interfaz de salida de la ruta de destino es la interfaz física o lógica correcta, no el túnel; cuando sea necesario, fíjela con una ruta estática /32 de mayor prioridad.
SÍNTOMAUn extremo declara el túnel down; el otro extremo no muestra ningún problema en absoluto.
CAUSAEl Keepalive de GRE solo monitorea la dirección para la que está configurado — el Keepalive de este lado no requiere ni refleja nada sobre el propio estado de Keepalive del par, así que una configuración unilateral produce un síntoma unilateral y confuso.
SOLUCIÓNHabilite Keepalive con el mismo periodo/número de reintentos en ambos extremos si desea monitorear ambas direcciones, y lea display keepalive packets count en cada extremo por separado en lugar de asumir que la vista de un extremo describe todo el panorama.
SÍNTOMALa propia interfaz del túnel reporta Up y el Keepalive está sano, pero el tráfico real — especialmente TCP — se degrada o se cuelga de forma intermitente a medida que crecen los tamaños de paquete.
CAUSALa propia sobrecarga de encapsulación del GRE reduce el tamaño de carga útil efectivo por debajo del MTU de la interfaz física; cuando el MTU de túnel configurado (y tcp adjust-mss) no tienen en cuenta esa sobrecarga, los paquetes más grandes se fragmentan, descartan o pierden silenciosamente según la ruta, y nada de esto aparece como un evento de túnel caído.
SOLUCIÓNEjecute la prueba de barrido de tamaño ping -s / -a para encontrar el punto de quiebre real, luego configure el mtu del túnel y el tcp adjust-mss de la interfaz en valores que dejen margen para la sobrecarga del GRE.
Sacadas directamente del campo — las que vale la pena tener respuesta lista.
Sí — se aplica al tráfico reenviado a través del túnel. Cualquier paquete mayor que el MTU de túnel configurado se fragmenta antes de ser encapsulado, así que esta es exactamente la variable a ajustar una vez que la prueba de tamaño de ping haya encontrado su punto de quiebre real.
La interfaz Tunnel de Cisco ya usa GRE por defecto, así que tunnel-protocol normalmente no es la discrepancia. Lo que suele confundir: el periodo mínimo configurable de Keepalive en Cisco suele ser de 10 segundos, más alto que el predeterminado de 5 segundos de esta plataforma — configure ambos extremos con el mismo valor explícito en lugar de dejar los predeterminados, y recuerde que el soporte de Keepalive en el par no afecta si el Keepalive de su propio lado funciona.
En hardware Cisco más antiguo, el tráfico de la interfaz Tunnel puede reenviarse por CPU en lugar de por hardware; bajo carga pesada, el proceso de CPU que lo maneja (visible en show processes cpu como un proceso que consume una parte desproporcionada) puede privar de recursos a los propios paquetes de Keepalive, y los fallos de Keepalive derriban el túnel. Quitar el Keepalive en ambos extremos como paso de diagnóstico — no como solución permanente — confirmará esto: si el túnel se mantiene estable con Keepalive apagado, el volumen de tráfico, no una falla de enlace real, fue la causa.
Esta nota trata enteramente sobre el fallo de la propia interfaz del túnel para llegar a Up — protocolo, direccionamiento, clave, ruta y keepalive. Un túnel que reporta Up pero no deja pasar correctamente el ping es un problema aguas abajo — normalmente una discrepancia de enrutamiento o de detalle de encapsulación en un túnel que técnicamente ya existe — y ese es un camino de diagnóstico completamente distinto, cubierto en nuestra nota complementaria sobre un túnel VPN activo pero con fallo de ping.
Esto casi siempre es el caso de MTU/fragmentación, no un problema de ruta o Keepalive — los pequeños paquetes de control y el tráfico de prueba de bajo volumen pueden cruzar el túnel bien mientras que el tráfico real más grande choca con la sobrecarga de encapsulación del GRE y empieza a fragmentarse o perderse. Ejecute la prueba de barrido de tamaño de ping en condiciones que se aproximen al tamaño del tráfico real, no solo un ping de tamaño predeterminado.
En la práctica, cualquiera de ellos — GRE es agnóstico del protocolo a nivel de túnel, así que OSPF, IS-IS, BGP y RIP funcionan todos sobre una interfaz de túnel GRE exactamente igual que sobre una física, junto con los protocolos multicast comunes. El propio túnel no entiende ni filtra lo que lleva dentro.
Esta nota se basa en el modelo de clasificación de fallas de GRE del router Huawei serie AR y sus comandos display this / display ip routing-table / display keepalive packets count, además de los casos de campo y notas multifabricante que los respaldan. Si su equipo es de otro fabricante, los comandos exactos cambian, pero la lista de verificación subyacente — modo de protocolo, direccionamiento, clave, ruta, dirección de keepalive, MTU — se traslada directamente. No cubre en profundidad el GRE que corre dentro de un túnel IPSec, ni los límites de rendimiento del reenvío multicast sobre GRE.
Cuéntenos cuál de las siete comprobaciones — protocolo, dirección, clave, ruta, keepalive, o MTU — ya ha descartado, junto con su salida de display this, y le ayudamos a interpretar el resto.