Resumen

  • RIPE indicó que el último archivo de actualización de RRC07 tenía marca de tiempo de las 19:20 UTC del 6 de octubre. Después declaró resuelto el incidente a las 21:53 UTC y señaló que los archivos bview se habían creado con normalidad.
  • El índice actual enumera 30 archivos de actualización consecutivos, separados por cinco minutos, entre las 19:25 y las 21:50. Sus fechas de modificación se sitúan entre las 21:53 y las 21:55; cuatro muestras se descomprimen por completo, pero no se analizaron sus registros MRT.

Análisis

Dos relojes, dos afirmaciones

Un archivo de datos de enrutamiento contiene más de una referencia temporal. La marca incluida en el nombre del archivo de actualización señala el intervalo al que corresponde. La fecha de modificación del directorio indica cuándo el servidor dice que cambió ese objeto. Una no reemplaza a la otra.

El primer aviso de RIPE situó el último archivo de RRC07 a las 19:20 UTC. En el índice público actual, el archivo anterior, updates.20261006.1920.gz, figura con modificación a las 19:25. Los 30 nombres siguientes avanzan cada cinco minutos, sin saltos, desde las 19:25 hasta las 21:50. Veinticinco muestran modificación a las 21:53, cuatro a las 21:54 y uno a las 21:55. El patrón es compatible con la publicación tardía de una serie en un intervalo breve. No revela el proceso interno ni la primera hora en que cada lector pudo descargar cada archivo.

La página del incidente dice que quedó resuelto a las 21:53 UTC del 6 de octubre y que los bview se crearon normalmente. RIPE define bview como una instantánea del estado del enrutamiento en un momento; los archivos de actualización contienen cambios de un intervalo. Por eso, una instantánea normal no permite determinar si cada archivo intermedio estaba completo. Son productos distintos para análisis distintos.

Los datos de RIS sirven para examinar el estado del enrutamiento, investigar sucesos BGP y seguir tendencias. En un análisis retrospectivo, un hueco en un gráfico admite dos lecturas: quizá no se observó ningún cambio, o quizá el archivo de observación no estaba disponible. Una lista continua publicada más tarde reduce la duda sobre los nombres visibles, pero no sobre el contenido de todos los intervalos.

Se recuperaron cuatro archivos de los extremos de la secuencia —19:20, 19:25, 21:45 y 21:50— y todos superaron una descompresión gzip completa. Es una comprobación del transporte, nada más. No se analizaron sus registros MRT y tampoco se muestrearon los otros 26 archivos. El índice actual no permite saber qué podían consultar los usuarios durante el incidente. El aviso público de RIPE no indica la causa del caso de RRC07, una pérdida de rutas ni un efecto en el tráfico. El retraso de publicación no permite inferir ninguna de esas cosas.

Fuentes