Resumen

  • RIPE NCC dijo que un par de DE-CIX empezó a enviar un número inusualmente alto de mensajes BGP a RRC12 a la 01:30 UTC del 2 de octubre; después, el proceso que consume las actualizaciones desde Kafka se agotaba repetidamente.
  • A las 19:10 UTC de ese día, el archivo público de RRC12 seguía sin archivos de actualización posteriores a la 01:00 UTC. Es un retraso de publicación en un servicio de medición, no una prueba de que faltaran rutas de Internet o se interrumpiera el tráfico.

Análisis

RIPE NCC abrió a las 09:42 CEST del 2 de octubre un incidente titulado «RRC12 MRT update files are not produced». Su primer aviso indicó que el último archivo de actualizaciones de RRC12 llevaba la marca de las 01:00 UTC y que su último BVIEW, una instantánea de estado, era de las 00:00 UTC. A las 13:26 CEST, la organización explicó que un par de DE-CIX había comenzado a enviar una cantidad inusualmente alta de mensajes BGP a RRC12 a la 01:30 UTC. Según RIPE, el proceso que consumía las actualizaciones desde Kafka no podía seguir ese volumen; cada reinicio volvía a terminar por tiempo de espera antes de avanzar lo suficiente.

RIPE también informó de retrasos en la producción de archivos de actualización de otros RRC.

RRC12 es un colector de rutas situado en Fráncfort y conectado a DE-CIX. Los colectores reciben datos BGP de sus pares; no deciden qué rutas usan esas redes. La documentación de RIPE explica que los datos se guardan por colector: los archivos «update» registran cambios durante un intervalo y los BVIEW almacenan una instantánea del estado. RIPE indica que los archivos de actualización suelen generarse cada cinco minutos. Esa es la cadencia normal de un flujo de observación, no una garantía de que todos los colectores siempre la cumplan.

Una consulta de solo lectura al archivo público de RIPE a las 19:10 UTC no encontró archivos de actualización de RRC12 posteriores a updates.20261002.0100.gz: 18 horas y 10 minutos antes de esa comprobación. El archivo de RRC18 había llegado a las 19:05 UTC. La comparación muestra la diferencia de actualidad visible entre esos dos directorios en ese momento; no demuestra que todos los demás colectores estuvieran libres de problemas, no identifica cuáles sufrieron antes los retrasos ni explica por qué RRC18 tenía archivos más recientes.

En el corte de revisión, el incidente seguía identificado y en investigación. El estado no nombró al par ni publicó su tasa de mensajes, las rutas implicadas, la duración de los retrasos de otros colectores, el estado de reproducción de la cola o el plan de recuperación. Tampoco dijo que se hubieran perdido rutas o interrumpido el tráfico. Un archivo retrasado obliga a comprobar la marca temporal antes de interpretar un intervalo vacío; no prueba que no ocurrieran cambios BGP.

La próxima actualización útil sería un breve comprobante de recuperación: las últimas marcas de tiempo de actualizaciones y BVIEW de los colectores afectados, si se reprodujeron los intervalos atrasados y cuándo volvió la publicación normal. Así, quienes usan RIS podrían distinguir el estado de la captura, el procesamiento y la publicación sin confundir el retraso del archivo con un cambio en el sistema de enrutamiento.

Fuentes