FRR siempre te muestra "No connection to RPKI cache server."

 Situación

  FRR siempre te muestra "No connection to RPKI cache server."

Solución

  Especifica la direción fuente en el la declaración del cache RPKI. Ejemplo:

  

  rpki cache tcp 108.162.192.12 8282 source X.Y.Z.N preference 1

Voila

FRR: Cómo solucionar la falta de redistribución de rutas kernel al arrancar

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.

BGP Dynamic Capabilities / Capacidades Dinámicas en BGP

 

El video muestra el funcionamiento del concepto "BGP Dynamic Capabilities" donde dos peers BGP pueden comunicarse sus capacidades "on the fly" sin interrupción de la sesión. El demo fue contruido con FRR hablando BGP sobre IPv6 y utilizamos como demostración la capacidad extended-nexthop la cual no es anunciada en el mensaje Open inicial. Un video enriquecedor que demuestra una vez más la enorme flexibilidad del protocolo BGP

BGP: Ejemplo IPv6 Only entre FRR y OpenBGPD

FRR:

show run

frr# sh run 

Building configuration...

Current configuration:

!

frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config

!

interface l0

 ipv6 address 2001:db8::1/128

exit

!

router bgp 65001

 bgp router-id 1.1.1.1

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002

 !

 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound

 exit-address-family

exit

!

OpenBGPD

Archivo: /etc/bgpd.conf

# macros

ASN="65002"

fib-update yes

log updates

# global configuration

AS $ASN

router-id 2.2.2.2

network 2001:db8::2/128

network inet6 connected

neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast

}

deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1

#

(por favor notar el espacio en blanco entre la última línea y la antepenúltima línea)

Video: Retirada Implícita y Explícita de prefijos en BGP / BGP Explicit/Implicit Withdraw

En el video se explica con detalle los conceptos de Retirada Implícita y Retirada Explicita de prefijos en BGP. Se realiza un Demo con 5 enrutadores utilizando un prefijo IPv6. Finaliza con capturas de wireshark de los mensajes UPDATE.

RFC 7911- BGP Add-path en acción

En el video se realiza un demo de la capacidad de BGP llamada Add-Path definida en el RFC 7911 utilizando FRR sobre Ubuntu. Para la realización del video se utilizó únicamente prefijos IPv6 a pesar de que la capacidad es agnóstica al prefijo transportado

Roles en BGP - Reduciendo fugas de redes/prefijos en BGP con mensajes OPEN y UPDATE

El video muestra una característica muy novedosa aún discutida dentro de IETF de como prevenir routing leaks utilizando un nuevo concepto llamado: "Roles BGP"

BGP Vecinos Dinámicos en FRR utilizando IPv6 - BGP Dynamic Neighbors

 En el video se realiza una demostración de configuración de BGP Vecinos Dinámicos 

utilizando FRR e IPv6

.