Si usas FRRouting (FRR), es posible que te hayas topado con un comportamiento frustrante: tras un reinicio, las rutas del kernel (como una ruta por defecto estática) no aparecen en tus anuncios de RIP o OSPF, pero si reinicias el servicio manualmente, todo funciona de maravilla.
Aquí te explicamos por qué sucede y cómo arreglarlo permanentemente.
El Problema
Al arrancar el sistema, FRR inicia sus procesos (Zebra, RIPd, etc.), pero las rutas definidas a nivel de sistema operativo no se redistribuyen a los vecinos de red. Esto interrumpe la conectividad tras un reboot y obliga a una intervención manual (systemctl restart frr), lo cual es inaceptable en entornos de alta disponibilidad.
El Motivo: La "Carrera" del Arranque
El culpable suele ser una condición de carrera (race condition) entre el gestor de red (como Netplan o systemd-networkd) y FRR.
Renombrado de Interfaces: Herramientas como Netplan a menudo renombran interfaces durante el arranque. Si FRR arranca mientras una interfaz aún se llama eth0 pero está pasando a ser wan0, Zebra puede ignorar las rutas asociadas a esa interfaz.
Estado "Down": Si Zebra escanea la tabla de rutas del kernel antes de que la interfaz de salida esté marcada como "UP" y operativa, RIP considera que la ruta no es válida para ser redistribuida.
Orden de Dependencias: Por defecto, el servicio de FRR puede intentar cargar antes de que la red esté "totalmente en línea", causando que el anuncio inicial de rutas falle.
Paso a paso: La Solución
La solución definitiva consiste en ajustar la unidad de systemd para que FRR espere a que la pila de red esté completamente lista y los nombres de interfaces sean definitivos.
1. Editar la configuración del servicio
No edites directamente el archivo en /lib/systemd/system/. Es mejor usar un override:
bash
sudo systemctl edit frr.service
Usa el código con precaución.
2. Forzar la dependencia de red
En el editor que se abre, añade las siguientes líneas:
ini
[Unit]
After=network-online.target
Wants=network-online.target
Usa el código con precaución.
Esto asegura que FRR no se ejecute hasta que el sistema reporte que la red está operativa (network-online.target).
3. Recargar y verificar
Guarda los cambios y aplica la nueva configuración:
bash
sudo systemctl daemon-reload
Usa el código con precaución.
(ya aquí el problema solucionado)
4. Verificar en FRR
Asegúrate de que tu configuración de FRR tenga los comandos de depuración para confirmar que Zebra recibe las rutas tras el próximo reinicio:
vtysh
debug zebra kernel
debug rip events
show ip route
Conclusión
En sistemas modernos donde el direccionamiento y el nombrado de interfaces son dinámicos (como en la mayoría de las distros Linux actuales), el orden de arranque lo es todo. Forzar a FRR a esperar a la red garantiza que, cuando el daemon pregunte por las rutas del kernel, el sistema ya tenga la respuesta correcta lista.
