Resumen

  • RIPE NCC atribuyó la caída del 8 de noviembre de 2026 a un límite configurado de 32k descriptores de archivo en la base de datos de RIS Looking Glass. Una API interna ocupó después todas las ranuras de procesamiento disponibles y quedaron inaccesibles Looking Glass, RIS Peers y otras API de RIPEstat.
  • La base de datos y la API se recuperaron esa tarde, pero faltaba reproducir mensajes BGP acumulados. A las 20:06 UTC, alrededor de una décima parte de los pares de RRC25 seguía retrasada. La recuperación prevista para las 05:00 UTC del día siguiente era una estimación; el incidente continuaba en Monitoring al cierre de esta crónica.

El observatorio tropezó con su propio límite

Para dejar de ver rutas no hizo falta que las rutas desaparecieran. Bastó con agotar los descriptores de archivo de la base que alimenta RIS Looking Glass. Así lo explica el registro de incidentes de RIPE NCC: el límite de configuración era 32k. Al alcanzarlo, una API interna que atendía consultas de Looking Glass consumió todas las ranuras de procesamiento disponibles. La avería dejó sin respuesta a Looking Glass, RIS Peers y muchas otras API de RIPEstat. Un techo local cerró varias ventanillas públicas.

Ese 32k no cuantifica rutas, usuarios ni pares afectados. Es el límite del proceso. El parte no publica cuántos descriptores se abrían por minuto, qué elevó la demanda ni por qué se eligió ese umbral. Sí deja documentado el mecanismo de propagación: primero se agota la base, luego se saturan las ranuras compartidas, finalmente fallan consultas de distintos servicios. Es una historia de arquitectura operativa, no de caída de BGP.

RIPE NCC recibió el primer aviso de un cliente a las 00:58 UTC del 8 de noviembre. Su primera nota pública salió a las 12:51 UTC: 11 horas y 53 minutos después. La hora del ticket no demuestra que todas las API llevaran caídas desde entonces. A las 13:20 UTC, el centro identificó el límite y las ranuras ocupadas. A las 13:39 UTC informó que la base estaba recuperada, que la API mejoraba y que el caudal se acercaba al habitual.

Una respuesta rápida puede contar una ruta vieja

La recuperación tenía cola. En el mismo mensaje de las 13:39 UTC, RIPE NCC dijo que Looking Glass reproducía mensajes BGP de las horas anteriores y que sus datos quedarían atrasados durante el proceso. Según la documentación oficial de Looking Glass, la vista se alimenta de colectores RIS, organiza la información por colector y par, y ofrece latest_time. La fecha de observación forma parte del resultado. Que el servidor responda deprisa no adelanta el reloj de los datos.

A las 20:06 UTC, alrededor del diez por ciento de los pares de RRC25 aún presentaba retraso por un volumen elevado de mensajes. RIPE NCC calculó que podrían ponerse al día hacia las 05:00 UTC del 9 de noviembre; no declaró que ya hubiera ocurrido. La guía de RIS Peers también agrupa datos por colector y alinea las consultas históricas con las tomas de 00:00, 08:00 y 16:00 UTC. Esos detalles permiten pedir una prueba mejor que un semáforo verde: cuál par, cuál colector y qué hora representa cada respuesta.

El parte describe un fallo en el servicio de RIPE NCC que muestra observaciones de enrutamiento. Primero volvió el mostrador; detrás, los registros aún avanzaban hacia el presente. La diferencia entre disponibilidad y frescura fue el verdadero tramo final del incidente.