Cómo distinguir un bucle de enrutamiento de una ruta que fluctúa en sitios VPN
Un bucle de enrutamiento y una ruta inestable causan la misma pérdida intermitente. Tres comprobaciones en las puertas de enlace los distinguen antes de que cambie nada.
Dos sitios, un túnel y un prefijo remoto que responde un rato y luego calla. El reflejo es llamarlo bucle de enrutamiento, y a veces es exactamente eso. Pero un bucle y una ruta inestable producen la misma queja y necesitan reparaciones opuestas: uno es una decisión de reenvío que nunca termina, la otra es un prefijo que no deja de salir de la tabla. Tres observaciones los separan, y puede reunir las tres desde la línea de comandos de la puerta de enlace antes de tocar un filtro o reiniciar un túnel.
Un bucle se decide salto a salto. El sitio A elige B como siguiente salto para el destino, B elige A para el mismo destino, y el paquete caduca en el TTL tras dos idas y vueltas. Una fluctuación la decide en cambio el protocolo de enrutamiento: el prefijo se retira, se reinstala o se sustituye por un siguiente salto alternativo, así que algunos paquetes no tienen ruta alguna mientras otros siguen una perfectamente buena.
Las tres comprobaciones que resuelven la cuestión
No necesita una captura de paquetes para tomar la primera decisión. Necesita el estado del prefijo en ambos extremos, el siguiente salto que elige cada lado y un número de saltos que se repite o no. Si el prefijo sigue instalado con el mismo siguiente salto mientras falla el tráfico, el bucle vive en la ruta de reenvío. Si el prefijo desaparece y vuelve, el fallo está por encima del reenvío y la reparación corresponde al protocolo de enrutamiento, no a una ruta estática.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Una advertencia antes de empezar. Si lee esto a través del túnel que está en bucle, su sesión muere en el momento en que cambie la ruta. Abra una consola o una vía de gestión que no dependa del prefijo que está a punto de reparar.
Comprobación uno: el prefijo es estable o se agita
Pregunte al núcleo qué instaló, no qué promete el archivo de configuración. En una puerta de enlace Linux, ip route get 10.20.30.40 ejecuta la misma consulta que ejecuta la ruta de reenvío, incluidas las tablas de políticas, mientras que ip route show 10.20.30.0/24 muestra la entrada misma. ip monitor route transmite cada cambio en el momento en que ocurre, que es la forma más rápida de ver un prefijo llegar e irse.
En un enrutador con FRR o BIRD, la tabla de reenvío no es la interesante. show ip bgp 10.20.30.0/24 devuelve la ruta seleccionada y su tiempo de actividad; un tiempo de actividad que se reinicia cada pocos minutos es una fluctuación que puede nombrar, no un bucle. show ip bgp summary muestra el estado de los vecinos y los recuentos de prefijos, así que un par que cae sin cesar quita la culpa a la ruta de reenvío.
Anote la respuesta antes de cambiar nada. Estable durante diez minutos mientras fallaban los pings, y desaparecido cuatro veces en diez minutos, llevan a pasos siguientes distintos. El segundo caso hace irrelevante cualquier teoría de ruta estática.
Comprobación dos: el siguiente salto apunta de vuelta al túnel de llegada
Un bucle necesita que dos puertas de enlace se pongan de acuerdo. En el sitio que recibe el paquete, mire la ruta que usará el paquete para salir: ip route get 10.20.30.40 from 10.10.5.20 con la dirección de origen real, porque una regla de política puede responder distinto de la tabla principal. Luego repita la consulta en el sitio que lo envió. Si cada lado elige al otro como siguiente salto para el mismo prefijo, el bucle queda probado y ninguna captura añadirá nada.
La causa es casi siempre un anuncio que no debería haber cruzado el túnel. Una ruta por defecto redistribuida dentro del túnel, un agregado que cubre la propia subred del sitio remoto o una ruta estática hacia el par por si acaso crean todos el mismo siguiente salto mutuo. El túnel puede estar plenamente establecido y aun así llevar tráfico en círculo; las notas de reenvío de strongSwan describen el lado de enrutamiento de ese requisito.
WireGuard merece su propia nota, porque no hay anuncio al que culpar. wg show lista las AllowedIPs de cada par, y el núcleo acepta un destino para un par solo si cae dentro de ese rango. Un bucle ahí es un rango de AllowedIPs superpuesto o una ruta estática que apunta hacia atrás a través de la interfaz, así que la reparación vive en esos dos lugares y en ningún otro.
Comprobación tres: lea el número de saltos, no las estrellas
traceroute -n -I 10.20.30.40 y mtr -n -r -c 20 10.20.30.40 muestran ambos la ruta, y el modo ICMP a menudo sobrevive a un filtrado que se come las sondas UDP. Un bucle parece una secuencia corta y repetida de las mismas dos direcciones de puerta de enlace con el TTL subiendo cada vez. Una caída parece estrellas tras la última puerta de enlace que respondió, y un solo salto silencioso no es prueba de nada.
Cuando la ruta es ambigua, lea el TTL en el cable. tcpdump -ni any -vv icmp en ambas puertas de enlace muestra el TTL de cada paquete y la dirección de origen de cada respuesta de tiempo excedido. Si un paquete llega al sitio remoto con un TTL inferior al número de saltos que la ruta puede contener, algo añade saltos que traceroute no le muestra, lo que ocurre cuando el cortafuegos de un sitio responde a las sondas en nombre de otro.
Repare el propietario del prefijo y luego verifique ambas direcciones
Decida qué sitio origina el destino y qué rutas de tránsito están permitidas, y luego cambie el anuncio o la ruta estática en ese propietario. Corregir el sitio receptor es tentador y casi siempre erróneo: esconde el bucle para un prefijo y deja el anuncio malo en su sitio para el siguiente. Las etiquetas de ruta, las listas de distribución y las reglas de horizonte dividido existen para detener esto en el origen, y son más baratas que un filtro que coincide con un solo prefijo.
Después del cambio, verifique la ida y la vuelta por separado, porque un bucle puede ser sustituido por un agujero negro sin ninguna mejora visible del síntoma. Ejecute ip route get desde ambos extremos, envíe tráfico desde un equipo que no sea la puerta de enlace y deje ip monitor route en marcha al menos un temporizador de retención para que una fluctuación no se confunda con una reparación.
Antes de cambiar nada, confirme estos cinco puntos: el prefijo es estable o se agita, el siguiente salto en ambos extremos apunta a un túnel, el número de saltos se repite o no, un solo sitio posee el prefijo y usted tiene una vía de gestión que sobrevive al cambio. Si uno de los cinco es desconocido, los otros cuatro son conjeturas.