Kassinipedia

GRE - Troubleshooting

Se lee en 3 min

GRE - Troubleshooting

Método general (de lo mínimo a lo complejo)

  1. ¿El destino del túnel es alcanzable por la tabla de rutas subyacente? (ping a la IP WAN remota).
  2. ¿El túnel está up/up? show interfaces tunnel 1.
  3. ¿Source y destination son espejo entre extremos?
  4. ¿Hay ruta hacia las LAN remotas por el túnel?
  5. ¿Hay fragmentación (transferencias grandes fallan)? Revisa ip mtu / ip tcp adjust-mss.

Comando base:

Router# show interfaces tunnel 1
Router# show ip route

Caso 1 — El túnel está up/down (line protocol down)

Síntoma: Tunnel1 is up, line protocol is down.

Causa: el tunnel destination no es alcanzable en la tabla de rutas (falta ruta al ISP, o la IP WAN remota está caída).

Diagnóstico:

Router# show interfaces tunnel 1 | include source|destination|protocol
Router# ping 10.10.20.1
Router# show ip route 10.10.20.1

Solución: asegurar alcance a la IP de destino (ruta por defecto o estática hacia el ISP).

Router(config)# ip route 0.0.0.0 0.0.0.0 10.10.10.2

Caso 2 — Error de enrutamiento recursivo (%TUN-5-RECURDOWN)

Síntoma: el log muestra %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing y el túnel baja.

Causa: el router aprendió la ruta hacia el destino del túnel a través del propio túnel (típico al anunciar la red de las WAN por el IGP que corre sobre el túnel).

Diagnóstico:

Router# show ip route 10.10.20.1     ! ¿el next-hop es la interface Tunnel?

Solución: no anunciar por el túnel las redes que se usan como source/destination; usar una ruta estática hacia el destino del túnel por la interfaz física, o filtrar esa red del IGP.

Router(config)# ip route 10.10.20.1 255.255.255.255 10.10.10.2

Caso 3 — El túnel sube pero las LAN no se comunican

Síntoma: ping a la IP del túnel del otro extremo funciona, pero las LAN no.

Causa: falta la ruta hacia la LAN remota por el túnel.

Diagnóstico:

Router# ping 192.168.20.2            ! túnel OK
Router# show ip route 172.16.30.0    ! ¿existe la ruta?

Solución: agregar la ruta (o el IGP) hacia la LAN remota apuntando a la IP del túnel.

Router(config)# ip route 172.16.30.0 255.255.255.0 192.168.20.2

Caso 4 — Transferencias grandes o túneles anidados fallan (fragmentación)

Síntoma: el ping normal funciona, pero HTTP/SSH/archivos grandes se cuelgan.

Causa: el overhead de GRE (24 bytes) hace que paquetes de 1500 bytes se fragmenten o se descarten (si viajan con DF-bit).

Diagnóstico:

Router# ping 192.168.20.2 size 1500 df-bit

Solución: ajustar la MTU de IP y el MSS de TCP en la interface tunnel.

Router(config)# interface tunnel 1
Router(config-if)# ip mtu 1400
Router(config-if)# ip tcp adjust-mss 1360

Caso 5 — Ambos extremos con la misma IP de origen/destino cruzada mal

Síntoma: el túnel no sube o sube solo en un lado.

Causa: tunnel source/tunnel destination no son espejo (el destino de un lado debe ser el origen del otro).

Diagnóstico:

Router# show running-config interface tunnel 1

Solución: corregir para que en R1 destination = IP WAN de R3, y en R3 destination = IP WAN de R1.

! R1
Router(config-if)# tunnel destination 10.10.20.1
! R3
Router(config-if)# tunnel destination 10.10.10.1

Caso 6 — El túnel “aletea” (sube y baja)

Síntoma: cambios de estado frecuentes del túnel.

Causa: inestabilidad del camino subyacente hacia el destino, o un keepalive demasiado agresivo.

Diagnóstico:

Router# show interfaces tunnel 1 | include line protocol|reset
Router# ping 10.10.20.1 repeat 100

Solución: estabilizar el camino físico, o relajar el keepalive.

Router(config-if)# keepalive 10 3

Recuerda el orden: destino alcanzable por la tabla subyacente, túnel up/up, source/destination espejo, ruta a las LAN remotas por el túnel, y ajuste de MTU/MSS. Ante %TUN-5-RECURDOWN, evita que el destino del túnel se aprenda por el propio túnel.

Vista Gráfica

Retroenlaces