El 9 de noviembre de 2026, RIPE Labs publicó un artículo del colaborador de la comunidad Ritesh Mukherjee en el que sostiene que, en cuanto tus routers descartan rutas Invalid mediante la validación de origen de rutas, el validador que los alimenta pasa a ser una fuente de política de reenvío. Si ese validador se cae o se pierde una sesión RTR, los routers pueden acabar dejando de aplicar RPKI; el artículo apunta a la investigación CURE, en la que los routers terminaron vaciando su caché RPKI. Eso convierte la monitorización de validadores RPKI en una tarea de operaciones y no en un dashboard prescindible.

La mayor parte del historial de fallos que cita el artículo es antiguo, y se trata de una contribución de la comunidad, no de una posición oficial del RIPE NCC. Lo útil es el planteamiento: la cadena va de la cuenta de la CA al repositorio, del repositorio a la relying party, de ahí a la sesión RTR y de esta a la política del router. El artículo sitúa los dos primeros eslabones en el lado de los registros y los tres últimos en el del operador.

Operamos BGP y peering nosotros mismos: estamos presentes directamente en los principales puntos de intercambio de internet europeos, hacemos peering con AWS, Azure, GCP, Oracle y Cloudflare, y en Colocation normalmente aportamos nosotros mismos el tránsito. Esta lista de comprobación está escrita desde el lado del operador de BGP y peering, donde los tres últimos eslabones son tuyos y nadie aguas arriba los aplica por ti. Aquí no describimos nuestra propia configuración de validadores; las comprobaciones que siguen son las que respaldan la investigación y los RFC.

La versión corta: perder ROA o VRP puede mover rutas de Valid a NotFound sin ninguna alerta, salvo que la construyas tú, y un informe de FRR sin confirmar sugiere que el estado de sesión del router puede inducir a error.

Qué significa el RPKI fail open para la validación de origen BGP

El RFC 6811 define tres estados. Una ruta es NotFound cuando ningún VRP cubre su prefijo, Valid cuando al menos un VRP coincide e Invalid cuando un VRP cubre el prefijo pero ninguno coincide. Los routers que descartan las rutas Invalid siguen aceptando las NotFound.

Ese es el diseño del RPKI fail open. Cuando desaparece un ROA o un router vacía su tabla de VRP, las rutas pasan de Valid a NotFound, no se descarta nada y, por defecto, nada avisa. El RFC advierte además de que eliminar registros de la base de datos de validación puede convertir en Invalid una ruta que antes era válida. Como ilustración propia: si se elimina el ROA de tu origen legítimo mientras otro ROA de un origen distinto sigue cubriendo el prefijo, tu ruta deja de coincidir y se descarta.

Un validador que no monitorizas es una política de reenvío que no auditas.

Los temporizadores que fijan tu ventana ciega

El RFC 8210 recomienda Refresh de 3600 segundos, Retry de 600 segundos y Expire de 7200 segundos. El temporizador Expire arranca cuando el router recibe End Of Data, y las cachés deben fijarlo en un valor mayor que Refresh y Retry. Con los valores por defecto, un router puede conservar datos obsoletos durante unas dos horas desde que la caché deja de responder, y después los descarta.

Routinator se actualiza cada 600 segundos por defecto y su valor de expire es de 7200 segundos por defecto. Lo que hace un router cuando se pierde una sesión (vaciar o conservar) y qué temporizador usa varía según el fabricante, y aquí no lo afirmamos plataforma por plataforma. Mídelo tú.

En un router de laboratorio o en una ventana de mantenimiento, corta la sesión RTR (bloqueando el puerto) o detén el validador. Anota tres datos por cada plataforma y versión de software: cuándo se vacía la tabla de VRP, qué temporizador lo gobernó y qué muestra en ese momento el comando de estado de sesión. Guarda los resultados en una tabla como esta:

Platform / version | VRP table empty after | Governing timer      | Session-state command shows
-------------------|-----------------------|----------------------|----------------------------
router A           |                       | cache Expire / local |
router B           |                       | cache Expire / local |
router C           |                       | cache Expire / local |

Esa tabla es tu ventana ciega real, y es el número a partir del cual deberían construirse los umbrales de tus alertas.

Monitorización de sesiones RTR: los estados sobre los que alertar

Cada uno de ellos corresponde a un fallo distinto y necesita su propia alerta. Los efectos sobre el reenvío que se describen a continuación indican lo que puede ocurrir, no lo que hace cada plataforma.

  • Proceso del validador caído o fallo en la recogida de métricas (scrape). Los routers pueden seguir sirviendo los últimos VRP hasta que se agote su temporizador de expire. Si entonces tu plataforma vacía la tabla, las rutas Valid pasan a NotFound y las rutas Invalid dejan de descartarse.
  • Antigüedad de la validación. En Routinator, routinator_last_update_done son los segundos transcurridos desde que terminó la última actualización. Alerta cuando supere unos pocos múltiplos de tu intervalo de refresh y comprueba en tu versión de Routinator si una ejecución fallida lo reinicia; si no lo hace, esta métrica también detecta un validador que está vivo pero no llega a los repositorios. Mientras tanto, los routers actúan con una imagen antigua: no ven los ROA nuevos y los revocados siguen contando.
  • Serial que deja de moverse. routinator_serial es el serial que se sirve a los clientes RTR. Un serial plano, por sí solo, es normal en un día tranquilo, así que alerta ante un serial plano combinado con una antigüedad de actualización elevada. El artículo señala que su herramienta todavía no puede detectar un validador bloqueado, es decir, una caché que responde pero deja de publicar seriales nuevos, así que esta comprobación tendrás que construirla tú.
  • Número de conexiones. routinator_rtr_current_connections cuenta las conexiones RTR abiertas. Alerta cuando baje del número de routers que esperas; las métricas por cliente requieren la opción --rtr-client-metrics. Un router sin sesión no recibe actualizaciones y puede arrancar su reloj de expire.
  • Desajuste de serial. El serial del router debería coincidir con el del validador al que está conectado, como señala un dashboard de Grafana de la comunidad para Routinator. Un router atascado en un serial anterior aplica una política anterior, de modo que los cambios recientes de ROA no surten efecto en él.
  • Número de VRP en el router. Una caída brusca respecto a la línea base es la señal de una tabla vaciada o de una eliminación masiva de ROA. El efecto puede ser que rutas Valid pasen a NotFound o, si solo desaparecen algunos registros, que rutas Valid pasen a Invalid.

Un cliente RTR independiente

El artículo amplía RAVEN, la herramienta de código abierto de su autor, con raven rtr monitor, un cliente RTR independiente sobre TCP y TLS que sigue los cambios de payload y los tiempos de sincronización, y marca anomalías frente a una línea base de desviación absoluta mediana. El autor trabaja para Nokia y RAVEN es un proyecto alojado por Nokia, así que valóralo como cualquier herramienta cercana a un fabricante. El artículo enumera lo que todavía no hace: detectar un validador bloqueado, alertar de cambios de ruta provocados por RPKI, comparar cachés entre sí o inspeccionar la política del router.

No te fíes solo del estado de sesión del router

La incidencia #24001 de FRR, abierta el 27 de octubre de 2026, es un aviso útil. Es una incidencia de un único autor, basada en laboratorio y que los mantenedores no han confirmado, así que trátala como un patrón y no como un veredicto. Quien abrió la incidencia afirma que los VRP nuevos llegaron a bgpd en cuestión de segundos, pero la política de entrada match rpki no se volvió a ejecutar, y las rutas Invalid siguieron instaladas en 12 de 13 ejecuciones con dos routers y en las 192 ejecuciones de topología.

En una prueba de agujero negro de RTR, quien abrió la incidencia vio la tabla de VRP vaciarse después de End of Data más los 600 segundos de Expire configurados, mientras que show rpki cache-connection seguía indicando que la caché estaba conectada. La solución provisional comunicada fue clear bgp ipv4 unicast <peer> soft in. Sea cual sea la causa raíz, la tercera columna de tu tabla de laboratorio importa: alerta ante el payload y el estado resultante de la ruta, no solo ante la sesión.

Añade un canario

Un canario ejercita el eslabón de la política del router, que ninguna métrica del validador puede ver. Necesitas una ruta que se sepa Invalid y que no pueda llegar a internet.

  1. Elige un prefijo de reserva que tengas y no anuncies. Publica un ROA para él que autorice un número de AS que controles pero que nunca uses para anunciarlo.
  2. Monta un router de laboratorio, en su propio AS, y dale una sesión eBGP dedicada a un router de borde de producción. Anuncia el prefijo desde el router de laboratorio. Como el origen difiere del ROA, es Invalid.
  3. En el borde de producción, aplica la misma política de importación que en tus peers reales. Alerta si el canario llega a ser aceptado, instalado o con aspecto de Valid en ese borde.
  4. Evita que se filtre: en ese borde, deniega el prefijo del canario en salida en todas las demás sesiones y márcalo con la comunidad no-export.

Si el canario empieza a ser aceptado, puede que RPKI haya dejado de aplicarse, aunque un ROA modificado o revocado para el prefijo del canario produciría el mismo resultado, así que comprueba eso primero. Un segundo canario con un ROA coincidente que pase a NotFound muestra la otra mitad: VRP perdidos y nada descartado.

Cuando RPKI deja de aplicarse sin avisar

Decide la respuesta antes de la noche en que ocurra.

  1. Confirma con el canario y el número de VRP del router, no solo con el dashboard del validador.
  2. Restablece el validador y comprueba que el serial del router alcanza al serial del validador.
  3. Vuelve a ejecutar la política de entrada si tu plataforma lo necesita, como sugiere el informe de FRR, y revisa de nuevo el canario.
  4. Mira aguas arriba en último lugar. Una eliminación masiva, como los 2.669 ROA que el RIPE NCC retiró y restableció en abril de 2020, se ve como una caída del número de VRP. Una cuenta de RIR comprometida, como el caso de Orange España del 3 de enero de 2024, en el que se volvieron a firmar ROA a favor de otro ASN, no tiene por qué cambiar ese número; busca un pico de rutas Invalid o cambios de origen en esos prefijos.

Nuestra recomendación, que ni el artículo ni los RFC prescriben: ejecuta al menos dos validadores por caminos separados y conecta cada router a ambos, de modo que un proceso caído no arranque el reloj de Expire en todos los routers. No respondas desactivando la validación de origen; ese es justo el estado que querías evitar.

Trata cada centro como un dominio de fallo propio

Si un router de un centro recibe su sesión RTR de un validador situado en otro, ese camino pasa a formar parte de tu cadena de validación. Nuestros cuatro routers de core están conectados por nuestra propia red de capa 2, un camino entre los centros, no un failover automático. Sea cual sea tu camino entre centros, añade su pérdida a las alertas de caída de sesión y ejecuta la tabla de laboratorio y el canario una vez por centro en lugar de una vez por red.

Fuentes