Resumen

  • Para decidir si investiga una variación de ruta, un operador no puede confundir la hora de respuesta con la de los datos: RIPE NCC dice que el retraso varía por endpoint y que Looking Glass muestra el peor desfase presente.
  • Una consulta de las 18:04:43 UTC devolvió como hora más reciente de los datos las 12:13:37 UTC. Es una muestra de una sola consulta, no una medida de todos los pares, recursos o API.

Si una ruta parece desaparecer, el operador debe decidir si abre una incidencia, modifica una comprobación o espera más evidencia. Un resultado vacío de RIPEstat no decide entre esas opciones por sí solo: Looking Glass aplica look_back_limit y excluye las observaciones que quedan fuera de la ventana. Una respuesta oficial consultada el 20 de octubre a las 18:04:43 UTC situó los datos más recientes a las 12:13:37 UTC, una diferencia de 5 horas, 51 minutos y 6 segundos. Es una sola consulta, no una medida de todas las rutas o puntos de acceso; sí muestra por qué conviene comprobar la hora de los datos antes de tratar una ausencia como un cambio de ruta.

Una petición puede ser nueva y, aun así, traer observaciones anteriores. Los paneles de seguimiento tienden a borrar esa diferencia cuando muestran una respuesta correcta, la hora de la consulta o un único estado del servicio. El 20 de octubre, RIPE NCC separó ambas cosas: algunos datos de RIPEstat iban con retraso por un problema en el Routing Information Service (RIS), y el efecto no era igual en todos los puntos de acceso de la API.

La nota no presentó un reloj universal para RIPEstat. Dijo que Looking Glass debería estar actualizado para la mayoría —más del 90 %— de los pares, y que sus metadatos muestran el peor retraso entre los datos disponibles. La lectura conjunta importa. Una mayoría puede estar al día aunque una fracción menor conserve datos más antiguos. El peor retraso sirve para revelar esa cola; no asigna la misma antigüedad a cada fila. RIPE NCC no publicó una garantía general de frescura ni definió un umbral único para considerar actualizado a cada par.

La distinción es relevante porque RIPEstat cumple dos funciones conectadas: es una interfaz pública de datos y también alimenta sus widgets y su interfaz de usuario. La API no es una tabla única con un calendario común. Cada punto de acceso responde a una pregunta distinta. La documentación de RIPE NCC enumera factores que cambian la frescura: frecuencia de recogida, momento de actualización del almacén, demora del procesamiento, fallos durante la recogida o el procesamiento y caché. Que una llamada termine bien acredita que la petición obtuvo respuesta; no certifica cuándo se recogió cada observación.

La documentación de Looking Glass describe su alimentación desde los colectores RIS como normalmente cercana al tiempo real, aunque con una pequeña demora. También distingue los tiempos de cada ruta: cuándo cambió por última vez y cuándo volvió a confirmarse. No significan lo mismo. El punto de acceso permite limitar la antigüedad de los resultados y, por defecto, no devuelve entradas de más de 24 horas. Por eso una fila ausente no debe convertirse automáticamente en prueba de que la ruta no existía: primero hay que conocer el filtro y la ventana de observación.

El incidente previo del RIS sitúa el retraso en el recorrido de los datos, no en una caída de las rutas. En otra nota, RIPE NCC informó de un problema al copiar archivos BVIEW desde su almacenamiento y de retrasos al procesar mensajes recogidos en RRC25. En la actualización correspondiente, dijo que publicaba los archivos BVIEW más recientes salvo los de RRC25; también señaló demoras en los archivos de actualización del RIS. El aviso de RIPEstat enlazó con ese incidente y anticipó efectos distintos entre puntos de acceso.

Ninguna de las dos comunicaciones afirma que rutas hayan desaparecido de Internet o que clientes hayan perdido conectividad.

La práctica útil es conservar el reloj de los datos junto al de la consulta. Para una decisión apoyada en RIPEstat, hay que guardar el punto de acceso, el recurso consultado, la hora de la petición, la hora de los datos más recientes, el estado de caché y la cobertura que representa la respuesta. Después se compara la edad con la tolerancia de esa decisión. Una observación de cinco horas puede servir para una tendencia histórica y ser demasiado antigua para una acción automatizada; el umbral correcto depende del uso, no del color de un indicador genérico.

La comunicación de RIPE NCC resulta útil porque no comprime el incidente en una cifra. El dato de «más del 90 %» orienta sobre el servicio y los metadatos señalan el peor retraso. El usuario no tiene que decidir si el aviso es cierto o falso; tiene que comprobar si el punto de acceso y la ventana concreta bastan para la decisión. Separar ambas comprobaciones permite aprovechar la fuente sin pedirle que demuestre más de lo que puede. Fuentes primarias: incidente de RIPEstat de RIPE NCC, incidente del RIS de RIPE NCC, documentación de la API RIPEstat, documentación del punto de acceso Looking Glass, Qué es RIPEstat, respuesta fechada de Looking Glass y documentación de los colectores RIS.